to-adrlisted

# to-adr — Phase 1 Produce `docs/adr/{NNN}-{feature-name}.md`. This is the **input** to everything downstream: `to-spec` reads it, and `implement` builds from the spec it produces. Read `.claude/rules/documentation.md` (ADR section) and `CONTEXT.md` before writing. --- ## Step 0 — do you have enough to decide? An ADR records a decision *and the reasoning behind it*. You cannot synthesize reasoning that never happened. **If the conversation already contains a substantive design discussion** — alternatives weighed, tradeoffs named, constraints surfaced — go straight to Step 1. Do **not** interview the user again. Synthesize what you already know. **If the user pointed you at a bare issue, ticket, or one-line description**, you have a problem statement, not a decision. Fetch it, read it, then run the **`grilling`** skill to work through the design tree before writing anything. > `grill-me` is user-invoked only (`disable-model-invocation: true`), so you cannot call > it yourself. Use the `grilling` skill, which is the same interview. If the user would > rather drive, tell them to run `/grill-me` and stop. **If you are unsure which case you're in, ask.** Writing an ADR from thin material produces a document that looks authoritative and encodes nothing — worse than no ADR, because `to-spec` will treat it as settled. --- ## Step 1 — ground it in the codebase Delegate to the `explore` agent rather than bulk-reading: - Existing patterns in the area this touches - Prior AD