planlisted

Scope: $ARGUMENTS Read `docs/PRD.md` first. If it does not exist, stop and say to run `/spec` — planning without acceptance criteria produces tickets that nobody can verify. **Write no implementation code in this command.** You are producing a plan; `dev` writes the code. If you find yourself drafting a function body, you have gone too far. ## Step 1 — Architecture Read enough of the existing code to know what is already there. Then sketch, in `docs/ARCHITECTURE.md` (template at `docs/ARCHITECTURE-template.md` if present): - The shape of the change: which modules, which boundaries, what talks to what - Decisions that are hard to reverse later, each with the alternative you rejected and why. These belong in `docs/decisions/` as ADRs — one file per decision - What you are deliberately *not* building yet Where you are guessing about the existing system, say so rather than presenting a guess as a reading. ## Step 2 — Tickets Split the work so each ticket is: - **Independent.** Two tickets touching the same file cannot run in parallel — that is the overwrite scenario the whole worktree setup exists to prevent. If two pieces are coupled, make them one ticket with an ordered plan inside, not two. - **One agent's worth.** If a ticket needs three checkpoints and a day, split it. - **Verifiable.** Carries its own acceptance criteria, traced back to the PRD. ## Step 3 — Show the tickets, then write them to docs/tickets/ First print the full set for review, in this shape