Agent skill · product strategy · paperclipai
task-planning
Turn a Paperclip issue or request into a structured implementation plan with child task graph, blockers, owners, and acceptance criteria, then save it as the issue `plan` document.
Why this skill is useful
Adds a structured implementation planning process with specific API commands for creating and updating issue documents that the AI wouldn't reliably generate on its own.
What it needs
Requires paperclip account access. About 3k tokens when loaded. Last updated 2026-08-07. 75,771 stars on the source repository.
What this skill does
Task Planning Produce implementation plans that the Paperclip executor can actually run: explicit child issues, real blockers, named owners, and a defined acceptance bar. Avoid plans that read well but cannot be split into work. When to use An issue asks you to "plan", "scope", "break down", "design the rollout", "propose the work", or similar. A user wants a written plan before approving implementation. A manager needs to delegate non-trivial work and the shape of the work is not obvious yet. You inherited an issue too large to deliver in one heartbeat and need to split it. When not to use The issue is a single small change you can ship in the same heartbeat. Just ship it. The issue is forensic ("why did this break"). Use a diagnosis skill first; plan only after the root cause is named. A current plan document already exists and the change is minor. Update that document; do not start fresh. Outputs 1. An updated issue document with key plan (markdown). 2. A short comment on the issue that links to the plan document and names the next action. 3. Where the plan requires approval, an issue-thread interaction of kind requestconfirmation bound to the latest plan revision. Do not create implementation subtasks until the plan is accepted. Plan structure Required sections, in order: 1. Goal — one paragraph. What changes for the user, the operator, or the system once this work lands. 2. Context reviewed — bullet list of documents, files, and prior issues you read. Lets reviewers spot missing inputs. 3. Constraints and non-goals — what must hold (compatibility, security, performance) and what this plan deliberately will not do. 4. Approach — the chosen path, with a short rationale. If you considered alternatives, name them and why you rejected them. 5. Work breakdown — ordered list of child issues. Each child has: Title in imperative form. Owner specialty (Engineer, QA, Designer, Security, DevRel, Manager, etc.). Scope and deliverables. Acceptance criteria. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills paperclipai/task-planning