to-speclisted

# to-spec — Phase 2 Turn an accepted ADR into a precise, sliced spec that `implement` can derive from. **Do not write any implementation code in this phase.** It ends at a human gate. Delegate the actual writing to the **`spec` agent** (Opus, high effort). Planning is where the reasoning tier earns its price — a vague spec burns every downstream attempt budget. --- ## Step 1 — locate the ADR **If the user named one** (`to-spec 002`, or "spec out the notifications ADR"), use it. **If not, list what's available and ask:** ```bash grep -l 'Status:.*accepted' docs/adr/*.md ``` Show the user the accepted ADRs with no spec folder yet, and ask which to build. Don't guess — picking the wrong one wastes the whole phase. **Refuse to proceed if:** - The ADR's status is `proposed` → it hasn't been accepted. Send them back to finish it. - The ADR is `superseded` → build the superseding one instead. - No ADR exists → stop and tell the user to run `to-adr` first. Do not invent a decision to fill the gap; that's the exact thing ADRs exist to prevent. --- ## Step 2 — resume or create? Check whether `specs/{NNN}-*/` already exists. **It exists** → this is a re-plan, not a scaffold. Read `implementation.md` first. If work is in progress, preserve completed task state; you are refining the plan, not resetting it. If anything is `blocked`, resolve that with the user before re-planning around it. **It doesn't** → scaffold: ```bash git checkout -b feat/{feature-name} cp -r specs/