task-planning

# 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 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,...