Adr From Meeting

ADR from a meeting — capture the decision while it is fresh

Mission: a structuring decision discussed in a meeting becomes a durable Architecture Decision Record at docs/decisions/NNN-title.md, using the project's decision template, with the rejected alternatives and their reasons preserved — so the "why we did / did not do X" survives the people who were in the room.

When to use

Reach for this when a discussion settled (or is settling) a decision that is structuring and costly to reverse: architecture, a shared or public contract, a data-ownership or module boundary, a build-vs-buy, a cross-cutting convention. Skip it for reversible, local choices — those live in the code and the module's DESIGN.md.

For a new project's upfront architecture, use architecture-advisor and the architecture-decision workflow instead; this skill is for the ongoing decisions that accrue as a project runs.

Steps

1. Locate the log. Find docs/decisions/. If it is missing, create it and copy 000-template.md in as the shape to follow. The next number is the highest NNN + 1 (zero-padded); the title is kebab-cased, e.g. 007-event-bus-choice.md.
2. Extract, do not invent. From the transcript pull: the problem and forces, the options weighed, the pros and cons voiced for each, the option chosen, the stated reasons, and the consequences and follow-ups people raised. Attribute nothing the transcript does not support.
3. Preserve the rejected paths. Every option discussed and dropped gets its block with why it lost. This is the highest-value part — it stops the team re-litigating the same choice in six months.
4. Fill the template. Map to context and problem → decision drivers → considered options (with pros and cons) → decision → consequences → links. Leave Status: proposed unless the meeting explicitly ratified it (accepted); set Date to the meeting date.
5. Flag the gaps. Anything the meeting left open becomes an explicit open question or a follow-up under Consequences — never a confident invention.
6. Interconnect — wire the ADR to the rest of the docs (see below).
7. Confirm. Report the drafted ADR path and a one-line summary; do not bury it in prose.

Interconnection

An ADR is independent from a module's DESIGN.md / README.md, but link both ways when it helps:

• From the affected module's DESIGN.md / README.md, cite the ADR as the why behind a structural choice ("a bus over direct calls — see decision 007") instead of re-explaining it inline.
• From the ADR's Links, point back at the module docs, the spec or issue, and the PR that implements it.
• If the decision reveals a reusable pattern or gotcha, promote it to a knowledge instinct; if a durable running note fits better, log a projectmem decision (pjm decision). The ADR stays the canonical record; the instinct and log are fast-recall echoes.
• Supersede, do not rewrite. A reversed decision gets a new ADR, and the old one flips to superseded by NNN.

Validate

• Every template section is filled or explicitly marked N/A — no empty headings.
• At least one rejected option with its reason (or a note that none were raised).
• The number is unique and sequential; the filename matches the title.
• No invented facts, names, or numbers beyond what the transcript supports.