Menu
Keep project docs aligned with recent code and feature changes — detect drift, update affected pages, and add release-relevant notes without rewriting unchanged sections.
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 | doc-maintenance |
| description | Keep project docs aligned with recent code and feature changes — detect drift, update affected pages, and add release-relevant notes without rewriting unchanged sections. |
| key | paperclipai/bundled/docs/doc-maintenance |
| recommendedForRoles | ["engineer","product","devrel"] |
| tags | ["docs","documentation","release-notes"] |
Keep the documentation honest with minimum churn. The goal is alignment between docs and behavior, not stylistic rewrites or cosmetic re-organization. Reviewers should be able to read a diff and see "this updates docs to match recent behavior changes".
--json to ..."). Avoid "we" except in narrative pages.experimental or omit it.A doc page is drifting if any of these are true:
When you find drift, fix it in the same pass and note it in the release note's Fixed group.
Faster cold start (avoid full bundle download on first run) beats Refactor bootstrap loader.**Breaking:** prefix. Include migration steps inline or via link.