adr-create

# adr-create ## When to use Use this skill when: - A non-trivial architectural choice needs a written record (kernel membership, cap raises, contract changes, library swap, deprecation). - A decision overrides a previous one and needs `supersedes:` linkage. - A roadmap phase closes and the chosen variant must be cited. - The user says "write an ADR for X", "decision log this", "we need a record of why we picked Y". Do NOT use when: - The change is reversible without governance impact (typo, lint fix, refactor that stays inside one module). - The decision is already covered by an existing ADR — extend or supersede it instead of duplicating. - A skill, rule, or guideline is the better home (use those skills). ## Admission gate — classify before you create Run this **before** picking a surface or a number. An ADR is warranted only when the decision is architecturally significant on at least one axis: 1. **Hard or costly to reverse** — a one-way door: public API shape, DB schema, wire format, published identifier, migration. 2. **Broadly constraining** — it binds work outside the module that made it. 3. **Crosses a governed surface** — consumer contract, API, security or privacy floor, package structure. None of the three holds → it is **not** an ADR. Route it to its real home: a decision note in `agents/decisions/`, a config value, a measurement record in `docs/CLAIMS.md`, an experiment, or a roadmap item. Explicitly **not** ADRs: a temporary numeric thre...