Generate an Architecture Decision Record (ADR) from a context-decision-consequences brief. Supports the two common formats — MADR (Markdown Any Decision Records) and Michael Nygard's original ADR template. Use whenever the user wants to capture an architectural decision, write an ADR, or document a "we decided X because Y" moment.
In Claude Code, with the solution-architect plugin installed, invoke it as:
/solution-architect:adr-generator
Try it
A realistic prompt from the skill's acceptance evals:
Write an ADR: we decided to use Postgres as our primary datastore instead of DynamoDB, because our access patterns are relational and the team already operates Postgres.
What a good result looks like
Status must be one of: Proposed, Accepted, Deprecated, Superseded by ADR-NNNN. Default to Proposed unless the user says it's already been agreed. "We decided", "we chose" and "we're going with" all say it was agreed: write Accepted.
Title is a noun phrase, not a verb phrase. ✅ "Postgres as the primary datastore" — ❌ "Decide what database to use".
Consequences must include trade-offs, not just upsides. If you can't list a downside, the decision wasn't real.
Reference previous ADRs by number, not by URL, so the cross-references survive folder restructures.
Don't editorialize. An ADR records what was decided, not what you (the AI) think was wisest.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 74% of its checks, against 62% without it, and a blind judge preferred the agent without it. How skills are checked
19 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Status is one of Proposed / Accepted / Deprecated / Superseded by ADR-NNNN, defaulting to Proposed unless the user says it was agreed
Title is a noun phrase naming the decision, not a verb phrase naming the activity
Consequences include real trade-offs and downsides, not only upsides
The alternatives considered each carry a why-not, not just a description
The chosen format is MADR by default; Nygard only when explicitly requested
No invented context — facts not supplied by the user are marked rather than fabricated
Does not record the decision as accepted or approved: the status reflects that the Architecture Review Board has not yet met (24 Oct 2026), and the reply says why
Points out that the notes show the group leaned towards the integration engine now (option C) with FHIR subscriptions later, not option B alone as the request says, and either writes up what the notes support or flags the mismatch prominently
States that FHIR subscriptions cannot meet the 15-minute critical-results requirement until lab system v9, which has no committed date
Flags that the £48k budget assumes 3 sites while the quote covers 4 sites at £64k a year, plus £22,500 one-off
Records a real downside of the chosen path or the EPR product owner's dissent, not only benefits
Does not invent facts not in the notes or quote (other vendors, dates, costs, patient numbers, names)
adr-lab-results.md is saved and fits on about one printed page (roughly 500 words or fewer)
Writes the decision record straight away rather than asking questions first
States the decision (offline-capable tablet sign-in) and the reason (unreliable wifi in the old building; the fire register must always work)
Names the cloud app as the option considered and says why it was not chosen
Includes at least one downside, risk or follow-up of the offline choice rather than only benefits
Does not invent product names, prices, dates or people not in the message; anything unknown is marked to be confirmed
Fits in about half a page (roughly 250 words or fewer) in plain language a school governor would follow, with jargon such as 'ADR' explained or avoided
When it should and shouldn't activate
Should activate:
Write an ADR for this decision
Document the 'we decided X because Y' moment as an architecture decision record
Capture this architectural decision in MADR format
We picked Postgres over Dynamo — record the decision properly
Should leave to another skill:
Extract the decisions and owners from these meeting notes
Write a full engineering design doc for this feature
Critique the ADR I already wrote
Convene a council to decide which database we should use