/new-adr

name: new-adr
description: Author a new ADR — record a DECISION (what the system must do, or how it is built) in a documentation-led repo. Picks the next contiguous number, chooses the shape (capability vs technology), fills the template, sets status Proposed, regenerates INDEX, updates domain READMEs, handles supersede/deprecate linkage, commits. Use when the user says "add an ADR", "new ADR", "record a decision", "create an architecture decision record", or invokes /new-adr. NOT for queueing a unit of work against an existing decision (use /new-plan) and NOT for recording a reusable rule, practice, or naming/process standard (use /add-convention).

new-adr

Author one new ADR, consistent with this repo's conventions.

Step 0 — Preconditions and context

1. Confirm the repo is bootstrapped: `AGENTS.md`, `CONVENTIONS.md`, and an `adr/` directory with at least `adr/0000-template.md` must exist. If not, stop and offer to run the **bootstrap** skill first. 2. Read `CONVENTIONS.md` to learn this repo's choices: the **ADR shape scheme** — a single shape, or two shapes (capability and technology) declared by a `shape:` field in each ADR's metadata block; there is no number boundary to read — status lifecycle, language mandate (if any), whether `domains/` groupings exist (and, if so, which domain this ADR belongs to — ask if it isn't obvious), the multi-agent mode, and the **artefact root** (default: repository root) — resolve `adr/` and `INDEX.md` against it (`AGENTS.md`/`CLAUDE.md` stay at the repo root). **Legacy range encoding.** A repo scaffolded before the shape became a declared field encodes it in the number instead — §ADR Shapes records a cutoff, or `adr/` holds a template numbered other than `0000` (e.g. `adr/0100-template.md`); either signal alone identifies it. Say so, and offer the migration onto the declared field (the **audit** skill carries the procedure) before authoring. If the operator declines, author under the repo's own rules: read the cutoff and place this ADR on its side of it — capability below, technology at or above, next contiguous **within that block** — using the boundary-numbered template for a technology ADR, and write **no** `shape:` field, which that repo does not use. If the block this ADR belongs to has reached the cutoff, stop and say so: the range is full, and the remedy is the migration, never crossing the boundary. 3. Read `INDEX.md` and `ls adr/` to learn existing numbers and titles. Ignore every `adr/0000-*.md` file — the templates are not decisions and hold no number in the sequence. Under the legacy range encoding, ignore the boundary-numbered template the same way: it is a template, not the first technology ADR. 4. If a `federation.md` exists, this repo is part of a multi-repo product. Note the **identity scheme** and the **home** it records — they govern numbering and cross-repo references below.

Step 0.5 — Assessment (run first)

Run the shared assessment protocol before authoring:

• **Reuse supplied answers first.** Treat applicable choices already supplied

in the request or this session, including depth, as answered. Summarise them without asking again; defaults never replace explicit choices. If every material choice is supplied, proceed. Ask only about a material missing or conflicting choice. A repository preference alone is not a current answer or execution grant.

• **Depth selector for unresolved choices.** If depth is not supplied and

choices remain, ask how deep this assessment should go: **express** — every choice takes its recommended default; only questions with no derivable default (the free-text essentials) are still asked; **guided** — only the questions marked high-impact below, plus the free-text essentials; **full** — every question below. If the repo's `CONVENTIONS.md` records an `Assessment depth:`, pre-select it as the recommended option when asking; a recorded depth is never applied silently. Otherwise recommend **full** when the request arrived with little or no context and **express** when it is already fully specified. At any question the operator may answer "defaults from here" or "go deeper"; honour the switch immediately.

• Ask the questions below **one at a time**, each with a **recommended

option** and a one-line reason; wait for each answer.

• Use **structured selection** (single- or multiple-choice). If the host

exposes a structured single-/multi-select question tool, use it and mark the recommended option; otherwise list options A/B/C in plain text and name the recommended one. Use **free text only** where an enumerable set is impossible (e.g. the title).

• **The operator decides.** Never proceed past a question without an

answer, and never guess scope when invoked with no context.

Questions (skip any the request already answers): 1. **Shape** — capability or technology (only if the repo declares two shapes; single-shape repos skip this). The answer picks the template and is written into the ADR's `shape:` field. *Recommended: per the request's intent.* 2. **Supersede?** — none, or select the ADR(s) this replaces. *Recommended: none.* *(High-impact — asked in guided: supersession linkage is hard to reverse.)* 3. **Initial status** — Proposed or Accepted. *Recommended: Proposed.* **Reconstructing already-shipped work** (a development built ahead of the process) is the exception: author at `Implemented`, Revision History citing the implementing commits and noting it was recorded after the fact, and write a matching `plan/done` entry. 4. **Create a plan item now?** — yes / no. *Recommended: yes when Accepted.* 5. **Title** — free text (the one unavoidable open answer; asked at every depth).

Step 1 — Determine shape and number

• **Shape.** If the repo uses a single ADR shape, use

`adr/0000-template.md` and write no `shape:` field. If it