Plan

---
name: plan
description: Use when you have a goal or spec for a multi-step task and want to break it into an ordered PLAN.md task list before any coding. Sets up PLAN.md; does not implement.
argument-hint: [goal or task description]
---

You are setting up PLAN.md for a task. Do NOT write implementation code yet.

The user's goal: $ARGUMENTS

1. Restate the goal in 1-2 sentences. If something critical is ambiguous, ask
   up to 3 sharp questions first — otherwise proceed.
2. Briefly explore the relevant code so the plan is grounded in reality.
3. Decompose the goal into small, ordered, independently-completable tasks.
   A good task is something ONE fresh session can finish without approaching
   the context limit (a module, function, fix, or thin slice), needs only a
   few files in context, and has a concrete "Done when…" condition. If a task
   needs more than ~1 hour or touches many files at once, split it further.
4. Write ./PLAN.md as:
   # Plan — <title>
   ## Goal
   <1-2 sentences>
   ## Notes / Constraints
   <key facts and decisions to respect>
   ## Tasks
   - [ ] **T1 — <short title>**
     - Files: <paths>
     - Do: <what to implement>
     - Done when: <concrete checkable condition>
   - [ ] **T2 — ...**
   ( ordered by dependency )
5. Self-check the plan before showing it. Every task must have Files, Do, and a
   Done-when; each "Done when…" must be concretely checkable — a command to run,
   a file that appears, an observable output — never vague like "improve X" or
   "make it better". Tasks must be small (one fresh session each) and ordered by
   dependency. Rewrite any task that fails this bar.
6. Show the plan and ask the user to confirm or adjust before any coding.