adr

Record design and architecture decisions with context, alternatives, and consequences.

123|22|Updated Apr 7, 2026
One-click install
npx skills add https://github.com/AlexZio00/claude-code-skills --skill adr-alexzio00
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adr
Source: https://github.com/AlexZio00/claude-code-skills/tree/main/adr
Command: npx skills add https://github.com/AlexZio00/claude-code-skills --skill adr-alexzio00

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ADRs provide structured context for architectural decisions, preventing re-litigating choices and guiding future work by recording the rationale, alternatives considered, and trade-offs.

Core Features & Use Cases

  • Capture decision context, alternatives rejected, and consequences to form a complete record.
  • Enforce a consistent file naming convention and storage location (docs/decisions/YYYY-MM-DD-<title>.md).
  • Support a lightweight workflow: draft, review, approve, and save for future reference.

Quick Start

Create an ADR by documenting what was decided, the alternatives considered, the rationale, and consequences, then save it to docs/decisions/YYYY-MM-DD-<title>.md

Frequently Asked Questions about adr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is an architecture decision record and why do I need to document it?

An architecture decision record (ADR) captures design choices, context, alternatives rejected, and consequences to prevent re-litigating decisions and guide future work. It ensures future sessions understand constraints not visible in code.

How do I create an ADR file for my software engineering project?

To create an ADR, document what was decided, alternatives considered, rationale, and consequences, then save it to docs/decisions/YYYY-MM-DD-<title>.md with standard frontmatter including Date, Status, and Deciders.

When should I write an architecture decision record in my workflow?

Write an architecture decision record after a design or architecture decision is made. It supports a lightweight workflow of draft, review, approve, and save to provide structured context for constraints not visible in code.

What structure and metadata should an ADR include to capture alternatives and consequences?

An ADR should include standard frontmatter with Date, Status, and Deciders, followed by sections capturing decision context, the choice made, alternatives rejected, and consequences to form a complete record.

Does this ADR workflow enforce a specific file naming convention and storage location?

Yes, the ADR workflow enforces a consistent file naming convention and storage location, saving records under docs/decisions/YYYY-MM-DD-<title>.md to maintain structured architectural governance.

What are the limitations of using ADRs for software architecture governance?

ADRs capture historical context and rationale but do not enforce decisions automatically in code. They are strictly documentation, meaning future sessions must read the records to understand constraints not visible in the codebase.