architecture-decision-record

Document architectural decisions using Nygard format ADR templates.

10|Updated Aug 26, 2025
One-click install
npx skills add https://github.com/ArieGoldkin/ai-agent-hub --skill architecture-decision-record
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-decision-record
Source: https://github.com/ArieGoldkin/ai-agent-hub/tree/main/skills/architecture-decision-record
Command: npx skills add https://github.com/ArieGoldkin/ai-agent-hub --skill architecture-decision-record

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ADRs capture the rationale behind significant technical decisions to preserve architectural memory.

Core Features & Use Cases

  • ADR Templates: Standardized formats (Nygard templates) for decisions.
  • Evaluation & Consequences: Document trade-offs and outcomes.
  • Lifecycle & References: Track status and related docs.
  • Use Case: Record ADRs for database migrations or service boundaries.

Quick Start

Create an ADR for a major decision, including context, decision, and consequences.

Frequently Asked Questions about architecture-decision-record

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

FAQPage Schema
What is an architecture decision record and why document architectural choices?

An architecture decision record (ADR) is a structured document that captures the rationale, context, and consequences of significant technical decisions. ADRs preserve architectural memory by documenting why choices were made, trade-offs evaluated, and outcomes expected, enabling teams to understand decision history and avoid repeating past analysis.

How do I create an ADR using the Nygard format?

Create an ADR by following the Nygard template: include status, context (why the decision arose), decision (what was chosen), consequences (outcomes and trade-offs), and alternatives considered. Document the decision title, date, and participants, then store the ADR in version control alongside your codebase for team access and traceability.

When should I use ADRs for backend systems and infrastructure decisions?

Use ADRs for major backend decisions: database migrations, service boundary definitions, API design patterns, technology selections, and governance policies affecting multiple teams. ADRs are essential when decisions have long-term architectural impact, involve trade-offs between competing approaches, or require team alignment on rationale.

Can I apply ADRs across different teams and technology stacks?

Yes. ADRs use standardized Nygard templates that work across teams and contexts. The structured format—context, decision, consequences, alternatives—translates to any technology choice: databases, frameworks, infrastructure platforms, or governance patterns, enabling consistent architectural documentation across diverse backend systems.

What's the difference between ADRs and other architectural documentation?

ADRs differ from general documentation by explicitly capturing decision rationale and alternatives considered, not just final state. They answer why a choice was made and what was rejected, creating a decision log rather than a static architecture diagram, enabling future developers to understand constraints and past reasoning.

How do ADRs support onboarding and architectural memory in growing teams?

ADRs serve as an architectural reference for new team members, explaining why systems are structured as they are without requiring oral history. Versioned and reviewed ADRs create institutional memory, prevent repeating rejected decisions, and help teams make consistent choices aligned with documented architectural patterns.