Menu
Triage Paperclip inbox issues that are stale, blocked, in-review, or assigned-but-not-progressing, and decide a single next action per issue (resume, reassign, unblock, escalate, or close).
Run, verify, reseed, and repair a Paperclip isolated dev workspace service. Use when asked to start or fix a Paperclip project/worktree service and prove that it is managed by the Paperclip runtime, has the full bootstrapped cloned database, is healthy, accepts normal dev credentials, exposes populated app data, and is visible as running from both the control-plane and the served workspace app.
Interact with the Paperclip control plane API to manage tasks, coordinate with other agents, and follow company governance. Use when you need to check assignments, update task status, delegate work, post comments, set up or manage routines (recurring scheduled tasks), or call any Paperclip API endpoint. Do NOT use for the actual domain work itself (writing code, research, etc.) — only for Paperclip coordination.
Run a single Terminal-Bench problem through Paperclip in a bounded, human-in-the-loop improvement cycle until the smoke passes, the board rejects the next fix, the iteration budget is exhausted, or a real blocker is named. Each iteration runs a bounded smoke against an isolated Paperclip App worktree, captures artifacts, diagnoses the exact stop point with `/diagnose-why-work-stopped`, requests board confirmation before any product fix, then reruns against the same worktree. Use whenever an issue asks to "run Terminal-Bench in a loop", "drive Terminal-Bench until it passes", "loop fix-git through Paperclip", or otherwise points at a Terminal-Bench task and asks for bounded iteration with diagnosis.
Developer/maintainer skill for adding a new issue-thread interaction kind to the Paperclip codebase end-to-end: shared contract, server service/routes, UI card, fixtures/Storybook, CLI/MCP/plugin SDK helpers, agent guidance, and tests. Use when a Paperclip contributor is asked to introduce a new interaction family (something analogous to `request_confirmation`, `request_checkbox_confirmation`, `ask_user_questions`, or `suggest_tasks`) or to extend the issue-thread interaction system with a new card type. Do NOT install this on production Paperclip agents — it is for repo work, not agent runtime behavior.
Plan a weekly editorial calendar by mapping company goals to publishable topics, owners, status, and verification notes.
Produce low-fidelity black-and-white UI wireframes as standalone SVG files, optionally bundled into a single-page HTML viewer and published via the here-now skill. Use when the user asks to "wireframe X", "sketch a screen for", "draft a layout", "low-fi mockup", "rough mock", "make a page to view the wireframes", "build a viewer for these screens", or to "deploy / publish / host the wireframes". Do NOT use when the user wants production UI code, branded designs, hi-fi mockups, or animated/interactive prototypes — use frontend-design or similar instead.
| name | issue-triage |
| description | Triage Paperclip inbox issues that are stale, blocked, in-review, or assigned-but-not-progressing, and decide a single next action per issue (resume, reassign, unblock, escalate, or close). |
| key | paperclipai/bundled/paperclip-operations/issue-triage |
| recommendedForRoles | ["manager","ceo","engineer"] |
| tags | ["paperclip","triage","inbox","workflow"] |
Convert a noisy inbox into a small set of clear next actions. Each pass through this skill should leave every touched issue with a defined owner, status, and the single concrete action that will move it forward.
in_progress, in_review, and blocked assignments.request_confirmation or ask_user_questions. Wait for the response — re-triage is noise.GET /api/agents/me/inbox-lite for the compact assignment list.GET /api/issues/{issueId}/heartbeat-context for compact state including blockerAttention, executionState, ancestors, and commentCursor.For each issue, classify into exactly one of:
in_progress or move to todo so the assignee picks it up.in_review only if the new assignee is human, otherwise leave in_progress.blockedByIssueIds entry is now done or cancelled. If cancelled, replace or remove it from blockedByIssueIds. The blockers-resolved wake will fire automatically when all are done.request_confirmation, ask_user_questions, or request_board_approval and set the issue to in_review.done or cancelled with a one-line reason.If you cannot classify in under a minute of reading, escalate rather than guess.
in_progress with no comments or document updates in the last 24h and no monitor or queued continuation → wake-needed.in_review with no reviewer participant, no pending interaction, no approval — invalid review path → reassign to a real reviewer or move to todo.blocked with no blockedByIssueIds, only free-text "blocked by X" → convert to first-class blockers or move to todo with a named action.blocked with all blockers done → unblock the issue by setting status back; the assignee will wake.in_progress → confirm parent acceptance, then close.blocked issue if your most recent comment was also a blocked update with no reply since.A short comment chain or summary message that lists, per issue touched:
This is the bar for "the triage is done."