| name | plan |
| description | Turns an approved design or decided brief into ordered tasks for separate agent runs. Use for implementation tasks, tracker tickets, or useful milestones. Do not use for one coding task or its short execution outline. |
| user-invocable | true |
| argument-hint | <design, brief, issue, or request> |
Plan
Create tasks that a new agent can finish without making product or technical decisions. Split work by working result, not by file, layer, or team boundary.
Process
- Read the source, repository instructions, and relevant code.
- Stop and return to design if an unresolved choice would change behavior, interfaces, data, security, scale, performance, compatibility, operations, cost, or proof.
- Split the work into tasks that each deliver working behavior, fit one agent run, and produce one focused pull request.
- Keep shared contracts in one task. Do not make two tasks answer the same question independently.
- Separate refactoring when it would hide a behavior change.
- Order tasks by dependency. Add a milestone only when it creates a useful delivery or review boundary.
- Return the plan in chat. Create tracker tickets only when the user asks. Never write a plan document.
- Stop after planning. Do not implement.
Write for two readers
Each task is read by a human and executed by an agent.
The first sections must let a human understand the task in under a minute. State the concrete problem, the result, and why it matters in everyday words. Do not use requirement IDs, implementation details, undefined project terms, or acronyms unfamiliar to the intended readers there.
