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 request_confirmation bound to …