adr-fundamentals

Explain ADR fundamentals for documenting architectural decisions and managing lifecycle stages.

5|3|Updated Jan 17, 2026
One-click install
npx skills add https://github.com/zircote/adr --skill adr-fundamentals
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adr-fundamentals
Source: https://github.com/zircote/adr/tree/main/skills/adr-fundamentals
Command: npx skills add https://github.com/zircote/adr --skill adr-fundamentals

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Provides foundational guidance on Architectural Decision Records (ADRs), when to create them, and how to manage their lifecycle.

Core Features & Use Cases

  • Covers ADR purpose, lifecycle stages (proposed, accepted, deprecated, superseded), and decision drivers.
  • Includes guidance on when ADRs are warranted, how to document options, consequences, and linking.
  • Offers templates and best practices for ADR naming, cross-team usage, and governance.

Quick Start

Ask ADR fundamentals for guidance on when to create ADRs and how to manage the ADR lifecycle.

Frequently Asked Questions about adr-fundamentals

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

FAQPage Schema
What are Architectural Decision Records and when should I create one?

Architectural Decision Records (ADRs) document architectural decisions effectively. You should create ADRs during project initiation, architecture planning, and governance reviews to capture decision drivers, options, and consequences.

How do I manage the ADR lifecycle and naming conventions?

Manage the ADR lifecycle by tracking stages: proposed, accepted, deprecated, and superseded. Follow naming conventions and linking best practices to maintain clear cross-team usage and governance throughout your project.

What should I include in an ADR document to capture consequences and options?

An ADR document should include decision drivers, evaluated options, and consequences. Documenting these elements ensures teams understand the rationale behind architectural decisions and their cross-team impact.

When are ADRs not warranted for a software engineering project?

ADRs may not be warranted for routine decisions lacking architectural impact. Reserve ADR documentation for significant architectural decisions that require governance reviews and cross-team alignment.