adr

Create and manage ADRs with standardized naming and lifecycle workflows.

Updated Nov 2, 2025
One-click install
npx skills add https://github.com/SelrahcD/claude-marketplace --skill adr-selrahcd
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adr
Source: https://github.com/SelrahcD/claude-marketplace/tree/main/selrahcd-dot-claude/skills/adr
Command: npx skills add https://github.com/SelrahcD/claude-marketplace --skill adr-selrahcd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ADRs provide a structured way to capture architecture decisions, rationale, and trade-offs so teams can revisit and understand why certain designs were chosen.

Core Features & Use Cases

  • Create ADRs in docs/adr/ with a standardized naming scheme (NNNN-kebab-case-title.md) to ensure consistent ordering and retrieval.
  • List, show, and supersede ADRs to reflect ongoing architectural evolution and dependencies between decisions.
  • Deprecate ADRs when decisions become obsolete while preserving historical context.
  • Templates and guidance enforce consistent content, status, and owner attribution for each decision.

Quick Start

Create a new ADR with /adr new <title> and fill in the required sections.

Frequently Asked Questions about adr

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

FAQPage Schema
How do I create architecture decision records with consistent file naming?

Use the /adr new command to generate architecture decision records in docs/adr/ with a standardized NNNN-kebab-case-title.md naming scheme, enforcing consistent ordering, retrieval, and lifecycle tracking.

Why do I need architecture decision records for project governance?

Architecture decision records provide a structured format to capture design rationale and trade-offs, ensuring traceable decisions and consistent governance so teams can revisit and understand why certain designs were chosen.

How do I supersede or deprecate an ADR while preserving historical context?

Supersede or deprecate ADRs through built-in lifecycle workflows that update status tracking while preserving historical context, reflecting ongoing architectural evolution and dependencies between decisions without deleting obsolete records.

Can I use ADRs to track design trade-offs and owner attribution for auditability?

Yes, ADRs enforce standardized templates and guidance that ensure consistent content, status tracking, and owner attribution for each decision, providing auditability for design trade-offs across the project.

What is the best way to manage architectural evolution and dependencies between decisions?

Manage architectural evolution by listing, showing, and superseding ADRs through a structured lifecycle that reflects dependencies between decisions while enforcing standardized naming, status tracking, and templated content for consistency.

Are there limitations to using ADRs for documenting software architecture decisions?

ADRs are limited to documenting architecture decisions, rationale, and trade-offs rather than replacing technical specifications, requiring teams to manually maintain lifecycle states and owner attribution to ensure ongoing auditability.