adr-writelisted

# ADR Write ## Purpose Scaffold a new Architecture Decision Record (ADR) using Michael Nygard's canonical format (Context / Decision / Consequences), allocate the next sequence number, and update the ADR index. Primary consumer: `architect`. Secondary: any agent making a decision the team will want to revisit in 6+ months. ## Scope - Allocates the next ADR number based on existing files in the ADR directory (default `docs/adr/`). - Writes a scaffolded ADR file with frontmatter (status, date, deciders, supersedes) and the four canonical sections (Title, Status, Context, Decision, Consequences). - Updates the ADR index (`docs/adr/README.md`) with a new row. - If `--supersedes <NNNN>` is given, marks the old ADR `Superseded by ADR-<new>` and links bidirectionally. - Does NOT fill in the Context / Decision / Consequences bodies — that's the human's (or architect agent's) job. The skill is a scaffolder, not a decision-maker. ## When to use - A non-trivial architectural choice was just made: a new framework adopted, a database swap, a service-boundary moved, an auth model changed, a build-system migration committed. - A decision is being revisited and the new decision supersedes an old ADR. - Pre-implementation: the architect agent wants the decision written-down before the team starts coding against it. ## When NOT to use - For routine code changes — ADRs are for decisions with multi-month / multi-team consequences, not for "we picked lodash over ra