adrlisted

# ADR Record a concrete architectural decision in a format optimized for future readers — typically the team member six months from now wondering "why did we do it this way?" ADRs are not exploratory. If the user is still weighing options, redirect to `/rfc`. ADRs assume the decision is made (or being made in this moment) and the job is to capture context + reasoning before they decay. ## Steps 1. **Confirm the decision is actually settled.** If the user describes multiple options without picking one, say so and suggest using the `rfc` skill instead. 2. **Find the repo's ADR location.** Check `docs/adr/`, `docs/decisions/`, `adr/`, `.adr/`. Mirror existing numbering and naming (`0042-use-postgres-jsonb-for-events.md` style). If none exists, propose `docs/adr/0001-<slug>.md` and let the user confirm. 3. **Look for an ADR template** in the repo (`docs/adr/template.md`, `adr-template.md`). If present, follow it exactly. Otherwise use the structure below. 4. **Date the ADR.** Use today's date in `YYYY-MM-DD`. 5. **Status starts as "Accepted"** unless the user is recording a historical decision now superseded (then `Superseded by ADR-NNNN`) or one still in review (`Proposed`). ## Default structure (when no repo template exists) ```markdown # ADR-NNNN: <Short decision title> - **Status:** Accepted - **Date:** YYYY-MM-DD - **Deciders:** <names or roles> ## Context What forces are at play? What's the problem and constraints? Keep it to what's needed to understand the decisio