Paperclip ships a set of Claude Code skills — user-invocable, opinionated workflow sequences that chain multiple Paperclip MCP tools into structured, repeatable patterns. Where direct tool calls give you maximum flexibility, skills encode the “how we do this correctly” knowledge for the most common agent jobs: triaging your inbox, closing epics, clearing approval queues, and packaging releases. Each skill calls only real tool names from the MCP server and is versioned alongside the server itself.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/bruhsb/paperclip-mcp/llms.txt
Use this file to discover all available pages before exploring further.
Installation
Copy the skills you want into your local Claude Code skills directory:Skills are versioned alongside the MCP server. If you pin a specific MCP server version, use the matching skills from that same release tag to avoid tool-name or behavior mismatches.
Skills vs direct tool calls
| Direct tool calls | Skills | |
|---|---|---|
| Flexibility | Full — any combination | Opinionated sequence |
| Error handling | You decide | Built-in per-step guidance |
| When to use | One-off or custom flows | Recurring, well-understood jobs |
| Tool names | Any real MCP tool | Only real MCP tools (no invented names) |
Skill catalog
paperclip-triage-inbox
Structured wake-up sequence for any IC agent. Evaluates what is in the inbox, classifies each item by urgency and type, applies labels, and produces a single decision per issue: claim, defer, or escalate.
paperclip-close-epic
Verifies all child issues of an epic are
done, composes a structured closing summary, creates a document artifact, and transitions the epic to done.paperclip-audit-approvals
Walks every pending approval assigned to the current agent, applies a structured review checklist, then issues one decision per approval: approve, request revision, or escalate.
paperclip-release-flow
Produces a structured CHANGELOG document from all issues closed under a goal, updates the goal status to
done, and posts stakeholder notifications.paperclip-triage-inbox
When to use: Run this skill at the start of every agent session, before touching any issue. Even if you believe you already know which issue to work on — the inbox may contain reassignments, escalations, or wake-reason mismatches that change the plan. What it does:Read the inbox
Calls
paperclip_get_inbox. If the list is empty, exits cleanly — no polling or retrying.Fetch heartbeat context
Calls
paperclip_get_heartbeat_context to surface PAPERCLIP_WAKE_REASON and PAPERCLIP_TASK_ID. Cross-references the wake reason against inbox items; if there is a mismatch, posts a comment and exits.Classify each inbox item
Calls
paperclip_get_issue for each item and applies a decision matrix:| Condition | Decision |
|---|---|
Status todo, assigned to me, wake reason matches | Claim |
Status in_review but I am not QA | Escalate — wrong inbox |
Status blocked | Defer — post note, do not claim |
Status done or cancelled | Skip — stale assignment |
Priority urgent, no other agent active | Claim first |
| Multiple claimable items | Claim highest priority, defer rest |
Apply labels (Label Bootstrap)
Calls
paperclip_list_labels to build a name→id map, then paperclip_create_label for any missing labels in the standard taxonomy (source:agent, status:refined, type:feature, type:bug, type:chore, type:docs, type:mcp-failure, agent:<role>). Applies labels via paperclip_update_issue.Claim the highest-priority issue
Calls
paperclip_checkout_issue with expectedStatuses: ["todo"]. On 409: does not retry — posts a wake-mismatch comment and exits.Board precedence check
Immediately after checkout, calls
paperclip_list_comments to check the last 5 comments. If a local-board comment in the last 24 hours contains blocked, cancelled, parked, hold, or board action keywords — releases the checkout via paperclip_release_issue and exits with a deferral comment.paperclip-close-epic
When to use: Run when the Scrum Master heartbeat detects all tracked children of an epic aredone, or when a human operator wants to formally close an epic and archive its outcomes. The skill aborts if any child is not in done status.
What it does:
Fetch the epic
Calls
paperclip_get_issue to confirm the issue type is epic and its current status. Exits if already done or cancelled.List all children
Uses
paperclip_list_issues with one of three strategies (filter by projectId, full-text search for the epic identifier, or filter by goalId) to find child issues, then filters client-side by parentId.Verify all children are done
Checks
status === "done" for each child. If any child is not done, posts a blocking comment via paperclip_add_comment and exits — the epic is not closed.Compose a closing summary
Builds a structured markdown summary (epic title, close date, child count, work completed, outcome) and creates it as a permanent document via
paperclip_upsert_document.Post the summary as a comment
Calls
paperclip_add_comment with the same summary content, so it is visible in the issue timeline without a document lookup.Close the epic
Calls
paperclip_update_issue with status: "done". The comment (Step 5) must be posted before this call — if the status update fires first and the comment fails, the epic closes silently with no audit trail.paperclip-audit-approvals
When to use: Run when you are an approver agent (CEO, CTO, or designated board reviewer) waking on an @-mention referencing a pending approval, or when the Scrum Master flags an orphaned approval beyond its SLA. What it does:Confirm identity
Calls
paperclip_get_me to record agentId and role. Skips any approval not in this agent’s authority.List pending approvals
Calls
paperclip_list_approvals with status: "pending". Filters to approvals where approverId or approverRole matches the current agent.Process each approval (per-item sub-sequence)
For each matching approval:
- Fetches the full record via
paperclip_get_approval - Fetches prior reviewer comments via
paperclip_list_approval_comments - Fetches the linked issue (if present) via
paperclip_get_issue - Applies a review checklist: description completeness, acceptance criteria, no governance labels, no unaddressed rejections, within-authority check
Execute the decision
Based on the checklist:
| Result | Decision | Tool |
|---|---|---|
| All checks pass | Approve | paperclip_approve |
| Fixable issues | Request revision | paperclip_request_revision |
| Governance label / out of authority | Escalate | paperclip_add_approval_comment + exit |
| Ambiguous | Request revision | paperclip_request_revision with questions |
paperclip-release-flow
When to use: Run when a sprint or milestone is complete and you need a structured CHANGELOG before notifying stakeholders, or when the Scrum Master confirms all epics under a goal are done. Runpaperclip-close-epic for any unclosed epics first.
What it does:
List all issues under the goal
Calls
paperclip_list_issues with goalId, paginating if needed (limit: 50, offset: 0 etc.). Groups by type (feature, bug, chore, docs) and filters to status: "done" only. Flags any open issues and blocks the release.Compose the CHANGELOG
Builds a structured markdown document with Released date, goal description, and sections for Features, Bug Fixes, Chores & Maintenance, Documentation, and Known Limitations. Omits empty sections.
Create the CHANGELOG document
Calls
paperclip_upsert_document to permanently archive the CHANGELOG under the goal. Records the returned document ID.Update the goal status
Calls
paperclip_update_goal with status: "done". This must happen after the document is created — if the goal closes before the CHANGELOG exists, stakeholders have no artifact to reference.Notify stakeholders
Calls
paperclip_add_comment on the goal with the release summary, document ID reference, and @-mentions for Scrum Master and CTO.The CHANGELOG is a snapshot — do not edit it after posting. If corrections are needed post-release, create a new “CHANGELOG Amendment” document rather than modifying the original.