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
The ADR must include a required-skills preflight list — which skills must be loaded before implementation starts, and why each one is needed
When architecture shape is important, capture visual artifacts (diagrams/review pages) and link them from the ADR

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:

Find existing ADRs. Check 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
Check the tech stack. Read package.json, go.mod, requirements.txt, Cargo.toml, or equivalent. Note relevant dependencies and versions.
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.
Check for ADR references in code. Look for ADR-NNNN references in comments and docs (see "Code ↔ ADR Linking" below). This reveals which existing decisions govern which parts of the codebase.
Draft required-skills preflight. Based on impacted areas, list the skills that must be loaded before implementation starts. Use canonical skill names and include a one-line reason per skill.
Note what you found. Carry this context into Phase 1 — it will sharpen your questions and prevent the ADR from contradicting existing decisions.
Capture a visual baseline when helpful. If visual-explainer is available, run /project-recap for unfamiliar systems or /generate-web-diagram for current architecture. Use this as pre-decision context, not as a replacement for written reasoning.

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):

What are you deciding? — Get a short, specific title. Push for a verb phrase ("Choose X", "Adopt Y", "Replace Z with W").
Why now? — What broke, what's changing, or what will break if you do nothing? This is the trigger.
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?").
Which skills are required before implementation starts? — List canonical skill names and why each is needed. If coverage is unclear, call out the gap and queue find-skills.
What does success look like? — Measurable outcomes. Push past "it works" to specifics (latency, throughput, DX, maintenance burden).
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.
What's your current lean? — Capture gut intuition early. Often reveals unstated priorities.
Who needs to know or approve? — Decision-makers, consulted experts, informed stakeholders.
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.
Would visual artifacts reduce ambiguity? — If yes, decide which outputs are required (/generate-web-diagram, /plan-review, /diff-review) and where links should live.

Adaptive follow-ups: Based on answers, probe deeper where the decision is fuzzy. Common follow-ups:

"What's the worst-case outcome if this decision is wrong?"
"What would make you revisit this in 6 months?"
"Is there anything you're explicitly choosing NOT to do?"
"What prior art or existing patterns in the codebase does this relate to?"
"I found [existing ADR/pattern] — does this new decision interact with it?"

When to stop: You have enough when you can fill every section of the ADR — including the Implementation Plan — without making things up. If you're guessing at any section, ask another question.

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:

Here's what I'm capturing for the ADR:

Title: {title}

Trigger: {why now}

Constraints: {list}

Required skills (preflight): {skill names + why needed}

Options: {option 1} vs {option 2} [vs ...]

Lean: {which option and why}

Non-goals: {what's explicitly out of scope}

Related ADRs/code: {what exists that this interacts with}

Affected files/areas: {where in the codebase this lands}

Verification: {how we'll know it's implemented correctly}

Visual artifacts: {which diagrams/reviews to generate, if any}

Does this capture your intent? Anything to add or correct?

Do NOT proceed to Phase 2 until the human confirms the summary.

Phase 2: Draft the ADR

Choose the ADR directory.
- If one exists (found in Phase 0), use it.
- If none exists, create docs/decisions/ (MADR default) or adr/ (simpler repos).
Choose a filename strategy.
- If existing ADRs use numeric prefixes (0001-...), continue that.
- Otherwise use slug-only filenames (choose-database.md).
Choose a template.
- Use assets/templates/adr-simple.md for straightforward decisions (one clear winner, minimal tradeoffs).
- Use assets/templates/adr-madr.md when you need to document multiple options with structured pros/cons/drivers.
- See references/template-variants.md for guidance.
Fill every section from the confirmed intent summary. Do not leave placeholder text. Every section should contain real content or be removed (optional sections only).
Write the Implementation Plan (including required skills preflight). This is the most important section for agent-first ADRs. It tells the next agent exactly what to do and which skills to load before starting. See the template for structure.
Write Verification criteria as checkboxes. These must be specific enough that an agent can programmatically or manually check each one.
Generate visual artifacts (recommended for architecture-impacting ADRs).
- Use /generate-web-diagram for proposed architecture or flow.
- Use /plan-review <adr-file> after drafting to validate Implementation Plan coverage.
- If superseding/changing an existing architecture, use /diff-review for before/after comparison.
- Record output HTML paths and link them in ## Visual Artifacts (or ## More Information if the section is omitted).
Generate the file.
- Preferred: run scripts/new_adr.js (handles directory, naming, and optional index updates).
- If you can't run scripts, copy a template from assets/templates/ and fill it manually.

Phase 3: Review Against Checklist

After drafting, review the ADR against the agent-readiness checklist in references/review-checklist.md.

Present the review as a summary, not a raw checklist dump. Format:

ADR Review

✅ Passes: {list what's solid — e.g., "context is self-contained, implementation plan covers affected files, verification criteria are checkable"}

⚠️ Gaps found:

{specific gap 1 — e.g., "Implementation Plan doesn't mention test files — which test suite should cover this?"}

{specific gap 2}

Recommendation: {Ship it / Fix the gaps first / Needs more Phase 1 work}

Only surface failures and notable strengths — do not recite every passing checkbox.

If there are gaps, propose specific fixes. Do not just flag problems — offer solutions and ask the human to approve.

Do not finalize until the ADR passes the checklist or the human explicitly accepts the gaps.

For ADRs with visuals, run /fact-check <visual-or-adr-output> if available before final recommendation to verify claims against the codebase.

Consulting ADRs (Read Workflow)

Agents should read existing ADRs before implementing changes in a codebase that has them. This is not part of the create-an-ADR workflow — it's a standalone operation any agent should do.

When to Consult ADRs

Before starting work on a feature that touches architecture (auth, data layer, API design, infrastructure)
When you encounter a pattern in the code and wonder "why is it done this way?"
Before proposing a change that might contradict an existing decision
When a human says "check the ADRs" or "there's a decision about this"
When you find an ADR-NNNN reference in a code comment

How to Consult ADRs

Find the ADR directory. Check docs/decisions/, adr/, docs/adr/, decisions/. Also check for an index file (README.md or index.md).
Scan titles and statuses. Read the index or list filenames. Focus on accepted ADRs — these are active decisions.
Read relevant ADRs fully. Don't just read the title — read context, decision, consequences, non-goals, AND the Implementation Plan. The Implementation Plan tells you what patterns to follow and what files are governed by this decision.
Respect the decisions. If an accepted ADR says "use PostgreSQL," don't propose switching to MongoDB without creating a new ADR that supersedes it. If you find a conflict between what the code does and what the ADR says, flag it to the human.
Follow the Implementation Plan. When implementing code in an area governed by an ADR, follow the patterns specified in its Implementation Plan. If the plan says "all new queries go through the data-access layer in src/db/," do that.
Reference ADRs in your work. Add ADR-NNNN references in code comments and PR descriptions (see "Code ↔ ADR Linking" below).

Code ↔ ADR Linking

ADRs should be bidirectionally linked to the code they govern.

ADR → Code (in the Implementation Plan)

The Implementation Plan section names specific files, directories, and patterns:

## Implementation Plan
- **Required skills (load before implementation starts)**: `inngest-steps` (durable step patterns), `system-bus` (repo conventions)
- **Affected paths**: `src/db/`, `src/config/database.ts`, `tests/integration/`
- **Pattern**: all database queries go through `src/db/client.ts`

Code → ADR (in comments)

When implementing code guided by an ADR, add a comment referencing it:

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

Keep these lightweight — one comment at the entry point, not on every line. The goal is discoverability: when a future agent reads this code, they can find the reasoning.

Why This Matters

An agent working in src/db/ can find which ADRs govern that area
An agent reading an ADR can find the code that implements it
When an ADR is superseded, the code references make it easy to find everything that needs updating

ADR ↔ Visual Linking

Architecture-changing ADRs should also link to generated visual artifacts.

ADR → Visual

Include a ## Visual Artifacts section (or use ## More Information) with stable paths to generated HTML, for example:

## Visual Artifacts
- Proposed architecture: `docs/decisions/diagrams/0007-auth-flow.html`
- Plan validation: `docs/decisions/diagrams/0007-plan-review.html`

Visual → ADR

Name visual files with ADR IDs/slugs where possible (for example 0007-auth-flow.html) so future agents can map pages back to the decision quickly.

ADR Hunting — Finding the Next One to Work On

When the current task is done and it's time to pick the next ADR, use the rubric-based ranking.

Quick Path

joelclaw vault adr next

Returns the top 3 candidates from proposed/accepted ADRs, sorted by the NRC+Novelty rubric (Need × 0.5 + Readiness × 0.3 + Confidence × 0.2, adjusted by Novelty). Each candidate shows score, band, axis breakdown, and rationale.

Decision Criteria

When choosing between candidates:

Readiness 5/5 trumps higher score — if two ADRs are close in score but one has readiness 5/5, pick that one. It means the implementation path is clear and you can ship in one session.
Accepted > Proposed — accepted means Joel already approved the decision. Proposed may need design discussion first.
Check if already shipped — some ADRs are implemented but not marked shipped. Before starting work, grep the codebase for evidence the ADR is already done (like ADR-0104 was).
Compound value — prefer ADRs that build on recently shipped work. If you just shipped memory injection, the next gateway improvement compounds on that.

Full Diagnostics

# See all open ADRs with rubric ranking
joelclaw vault adr rank

# Show 10 candidates
joelclaw vault adr next --count 10

# Read a specific candidate
joelclaw vault read ADR-0194

After Picking

Read the full ADR: joelclaw vault read ADR-XXXX
Accept it if still proposed: update status: accepted in frontmatter
Check if it's already (partially) implemented — grep codebase before building
Update status to shipped when done, with a verification section

Other Operations

Update an Existing ADR

Identify the intent:
- Accept / reject: change status, add any final context.
- Deprecate: status → deprecated, explain replacement path.
- Supersede: create a new ADR, link both ways (old → new, new → old).
- Add learnings: append to ## More Information with a date stamp. Do not rewrite history.
Use scripts/set_adr_status.js for status changes (supports YAML front matter, bullet status, and section status).

Mandatory: Sync to System Knowledge

After ANY ADR create, update, accept, reject, deprecate, or supersede:

joelclaw send system/adr.sync.requested -d '{"source":"adr-skill"}'

This syncs the ADR to the system_knowledge Typesense collection so agents can find it via semantic search. This is not optional. If you skip it, the brain is stale and agents make decisions without current context.

For bulk sync (e.g., after editing multiple ADRs):

joelclaw knowledge sync

Post-Acceptance Lifecycle

After an ADR is accepted:

Create implementation tasks. Each item in the Implementation Plan and each follow-up in Consequences should become a trackable task (issue, ticket, or TODO).
Reference the ADR in PRs. Link to the ADR in PR descriptions: "Implements ADR-0004."
Add code references. Add ADR-NNNN comments at key implementation points.
Check verification criteria. Once implementation is complete, walk through the Verification checkboxes. Update the ADR with results in ## More Information.
Revisit when triggers fire. If the ADR specified revisit conditions ("if X happens, reconsider"), monitor for those conditions.
Refresh visual artifacts if architecture drifted. Regenerate diagrams/reviews and keep ADR links current.

Index

If the repo has an ADR index/log file (often README.md or index.md in the ADR dir), keep it updated.

Preferred: let scripts/new_adr.js --update-index do it. Otherwise:

Add a bullet entry for the new ADR.
Keep ordering consistent (numeric if numbered; date or alpha if slugs).

Bootstrap

When introducing ADRs to a repo that has none:

node /path/to/adr-skill/scripts/bootstrap_adr.js

This creates the directory, an index file, and a filled-out first ADR ("Adopt architecture decision records") with real content explaining why the team is using ADRs. Use --json for machine-readable output. Use --dir to override the directory name.

Categories (Large Projects)

For repos with many ADRs, organize by subdirectory:

docs/decisions/
  backend/
    0001-use-postgres.md
  frontend/
    0001-use-react.md
  infrastructure/
    0001-use-terraform.md

Numbers are local to each category. Choose a categorization scheme early (by layer, by domain, by team) and document it in the index.

Resources

Visual Explainer (optional companion)

If visual-explainer is installed as a skill, use it to generate rich HTML visualizations of ADR content.

Install:

pi install https://github.com/nicobailon/visual-explainer

Primary commands:

/diff-review — before/after architecture diagrams when an ADR changes system design
/plan-review <adr-file> — cross-reference ADR implementation plan against actual codebase
/project-recap — architecture snapshot useful when writing new ADRs for unfamiliar areas
/generate-web-diagram — Mermaid architecture diagrams to embed or reference from ADRs
/fact-check <doc-or-html> — verify review/plan claims against the current codebase

These produce self-contained HTML pages in ~/.agent/diagrams/ with light/dark themes and interactive Mermaid diagrams.

Recommended ADR flow:

Phase 0: /project-recap (optional baseline)
Phase 2: /generate-web-diagram (proposed architecture)
Phase 3: /plan-review <adr-file> and /fact-check <output>
Save durable artifacts under the repo (for example docs/decisions/diagrams/) and link from the ADR

scripts/

scripts/new_adr.js — create a new ADR file from a template, using repo conventions.
scripts/set_adr_status.js — update an ADR status in-place (YAML front matter or inline). Use --json for machine output.
scripts/bootstrap_adr.js — create ADR dir, README.md, and initial "Adopt ADRs" decision.

references/

references/review-checklist.md — agent-readiness checklist for Phase 3 review.
references/adr-conventions.md — directory, filename, status, and lifecycle conventions.
references/template-variants.md — when to use simple vs MADR-style templates.
references/examples.md — filled-out short and long ADR examples with implementation plans.

assets/

assets/templates/adr-simple.md — lean template for straightforward decisions.
assets/templates/adr-madr.md — MADR 4.0 template for decisions with multiple options and structured tradeoffs.
assets/templates/adr-readme.md — default ADR index scaffold used by scripts/bootstrap_adr.js.

Script Usage

From the target repo root:

# Simple ADR
node /path/to/adr-skill/scripts/new_adr.js --title "Choose database" --status proposed

# MADR-style with options
node /path/to/adr-skill/scripts/new_adr.js --title "Choose database" --template madr --status proposed

# With index update
node /path/to/adr-skill/scripts/new_adr.js --title "Choose database" --status proposed --update-index

# Bootstrap a new repo
node /path/to/adr-skill/scripts/bootstrap_adr.js --dir docs/decisions

Notes:

Scripts auto-detect ADR directory and filename strategy.
Use --dir and --strategy to override.
Use --json to emit machine-readable output.