ADR Skill

Philosophy

ADRs created with this skill are executable specifications for coding agents. A human approves the decision; an agent implements it. The ADR must contain everything the agent needs to write correct code without asking follow-up questions.

This means:

• Constraints must be explicit and measurable, not vibes
• Decisions must be specific enough to act on ("use PostgreSQL 16 with pgvector" not "use a database")
• Consequences must map to concrete follow-up tasks
• Non-goals must be stated to prevent scope creep
• The ADR must be self-contained — no tribal knowledge assumptions
• The ADR must include an implementation plan — which files to touch, which patterns to follow, which tests to write, and how to verify the decision was implemented correctly

When to Write an ADR

Write an ADR when a decision:

• Changes how the system is built or operated (new dependency, architecture pattern, infrastructure choice, API design)
• Is hard to reverse once code is written against it
• Affects other people or agents who will work in this codebase later
• Has real alternatives that were considered and rejected

Do NOT write an ADR for:

• Routine implementation choices within an established pattern
• Bug fixes or typo corrections
• Decisions already captured in an existing ADR (update it instead)
• Style preferences already covered by linters or formatters

When in doubt: if a future agent working in this codebase would benefit from knowing why this choice was made, write the ADR.

Proactive ADR Triggers (For Agents)

If you are an agent coding in a repo and you encounter any of these situations, stop and propose an ADR before continuing:

• You are about to introduce a new dependency that doesn't already exist in the project
• You are about to create a new architectural pattern (new way of handling errors, new data access layer, new API convention) that other code will need to follow
• You are about to make a choice between two or more real alternatives and the tradeoffs are non-obvious
• You are about to change something that contradicts an existing accepted ADR
• You realize you're writing a long code comment explaining "why" — that reasoning belongs in an ADR

How to propose: Tell the human what decision you've hit, why it matters, and ask if they want to capture it as an ADR. If yes, run the full four-phase workflow. If no, note the decision in a code comment and move on.

Creating an ADR: Four-Phase Workflow

Every ADR goes through four phases. Do not skip phases.

Phase 0: Scan the Codebase

Before asking any questions, gather context from the repo:

1. Find existing ADRs. Check contributing/decisions/, docs/decisions/, adr/, docs/adr/, decisions/ for existing records. Read them. Note:

   • Existing conventions (directory, naming, template style)
   • Decisions that relate to or constrain the current one
   • Any ADRs this new decision might supersede

2. Check the tech stack. Read package.json, go.mod, requirements.txt, Cargo.toml, or equivalent. Note relevant dependencies and versions.

3. Find related code patterns. If the decision involves a specific area (e.g., "how we handle auth"), scan for existing implementations. Identify the specific files, directories, and patterns that will be affected by the decision.

4. Check for ADR references in code. Look for ADR references in comments and docs (see "Code ↔ ADR Linking" below). This reveals which existing decisions govern which parts of the codebase.

5. Note what you found. Carry this context into Phase 1 — it will sharpen your questions and prevent the ADR from contradicting existing decisions.

Phase 1: Capture Intent (Socratic)

Interview the human to understand the decision space. Ask questions one at a time, building on previous answers. Do not dump a list of questions.

Core questions (ask in roughly this order, skip what's already clear from context or Phase 0):

1. What are you deciding? — Get a short, specific title. Push for a verb phrase ("Choose X", "Adopt Y", "Replace Z with W").
2. Why now? — What broke, what's changing, or what will break if you do nothing? This is the trigger.
3. What constraints exist? — Tech stack, timeline, budget, team size, existing code, compliance. Be concrete. Reference what you found in Phase 0 ("I see you're already using X — does that constrain this?").
4. What does success look like? — Measurable outcomes. Push past "it works" to specifics (latency, throughput, DX, maintenance burden).
5. What options have you considered? — At least two. For each: what's the core tradeoff? If they only have one option, help them articulate why alternatives were rejected.
6. What's your current lean? — Capture gut intuition early. Often reveals unstated priorities.
7. Who needs to know or approve? — Decision-makers, consulted experts, informed stakeholders.
8. What would an agent need to implement this? — Which files/directories are affected? What existing patterns should it follow? What should it avoid? What tests would prove it's working? This directly feeds the Implementation Plan.

When to stop: You have enough when you can fill every section of the ADR — including the Implementation Plan — without making things up.

Intent Summary Gate: Before moving to Phase 2, present a structured summary of what you captured and ask the human to confirm or correct it.

Phase 2: Draft the ADR

1. Choose the ADR directory (use existing or create docs/decisions/).
2. Choose a filename strategy (date prefix or slug-only, matching existing convention).
3. Choose a template (simple or MADR).
4. Fill every section from the confirmed intent summary.
5. Write the Implementation Plan — tells the next agent exactly what to do.
6. Write Verification criteria as checkboxes.
7. Generate the file (prefer running scripts/new_adr.js).

Phase 3: Review Against Checklist

After drafting, review the ADR against the agent-readiness checklist in references/review-checklist.md. Present a summary of passes and gaps, not a raw checklist dump.

Consulting ADRs (Read Workflow)

Agents should read existing ADRs before implementing changes in a codebase that has them.

1. Find the ADR directory.
2. Scan titles and statuses.
3. Read relevant ADRs fully (context, decision, consequences, non-goals, AND Implementation Plan).
4. Respect accepted decisions.
5. Follow the Implementation Plan patterns.
6. Reference ADRs in your work via code comments.

Code ↔ ADR Linking

Add ADR path comments at entry points of code governed by a decision:

// ADR: Using better-sqlite3 for test database
// See: docs/decisions/2025-06-15-use-sqlite-for-test-database.md
import Database from 'better-sqlite3';

Resources

• scripts/new_adr.js — create a new ADR file from a template
• scripts/set_adr_status.js — update an ADR status in-place
• scripts/bootstrap_adr.js — create ADR dir and initial decision
• references/review-checklist.md — agent-readiness checklist
• references/adr-conventions.md — directory, filename, status, lifecycle conventions
• assets/templates/adr-simple.md — lean template
• assets/templates/adr-madr.md — MADR 4.0 template

Mirrored from https://github.com/vercel/ai — original author: vercel, license: Apache-2.0. This is an unclaimed mirror. Content and ownership transfer to the author when they claim this account.