plan-ticket

Essential Principles

• The plan is a contract, not a scratchpad. It is persisted to disk so the user can review it before implementation starts, it survives across sessions, and it becomes the sole input to the implementation run - which is why every step needs exact paths and commands an agent with no conversation context could follow.
• Critics get exclusive scopes. Same-model reviewers converge on the same obvious findings; giving each critic a scope and telling it what is out of scope forces coverage instead of triplicate feedback.

When to Use

In a ticket flow, this skill sits after the ticket is validated and a branch or worktree exists, and before any implementation work is created. Its output (plan.md) is what the user reviews at their stop-and-clarify checkpoint, and what each implementation run is derived from.

Skip it when the user asks for a direct change with no ticket-shaped scope - planning ceremony on a one-line edit is waste.

Steps

Step 1: Intake and Classify

Require the ticket details (key, description, acceptance criteria). If they are not in the conversation, fetch them with the tracker's skill or ask the user - do not plan from a bare ticket key.