Agent skill · writing content · aiskillstore
architecture-decision-record
Use this skill when documenting significant architectural decisions. Provides ADR templates following the Nygard format with sections for context, decision, consequences, and alternatives. Helps teams maintain architectural memory and rationale for backend systems, API designs, database choices, and infrastructure decisions.
Why this skill is useful
Codifies a structured approach to documenting architectural decisions that the AI could infer but doesn't have a standard for.
What it needs
About 6k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
Architecture Decision Record Overview Architecture Decision Records (ADRs) are lightweight documents that capture important architectural decisions along with their context and consequences. This skill provides templates, examples, and best practices for creating and maintaining ADRs in your projects. When to use this skill: Making significant technology choices (databases, frameworks, cloud providers) Designing system architecture or major components Establishing patterns or conventions for the team Evaluating trade-offs between multiple approaches Documenting decisions that will impact future development Why ADRs Matter ADRs serve as architectural memory for your team: Context Preservation: Capture why decisions were made, not just what was decided Onboarding: Help new team members understand architectural rationale Prevent Revisiting: Avoid endless debates about settled decisions Track Evolution: See how architecture evolved over time Accountability: Clear ownership and decision timeline ADR Format (Nygard Template) Each ADR should follow this structure: 1. Title Format: ADR-####: [Decision Title] Example: ADR-0001: Adopt Microservices Architecture 2. Status Current state of the decision: Proposed: Under consideration Accepted: Decision approved and being implemented Superseded: Replaced by a later decision (reference ADR number) Deprecated: No longer recommended but not yet replaced Rejected: Considered but not adopted (document why) 3. Context What to include: Problem statement or opportunity Business/technical constraints Stakeholder requirements Current state of the system Forces at play (conflicting concerns) Example: 4. Decision What to include: The choice being made Key principles or patterns to follow What will change as a result Who is responsible for implementation Be specific and actionable: ✅ "We will adopt microservices architecture using Node.js with Express" ❌ "We will consider using microservices" Example: 5. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/architecture-decision-record