architecture-decision-records

Document technical decisions with context, options, trade-offs, and consequences.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/snuffomega/pricechart --skill architecture-decision-records-snuffomega
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-decision-records
Source: https://github.com/snuffomega/pricechart/tree/main/.skills/architecture-decision-records
Command: npx skills add https://github.com/snuffomega/pricechart --skill architecture-decision-records-snuffomega

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the problem of losing architectural context—why a decision was made and what trade-offs were accepted—so teams can onboard faster and avoid repeating past mistakes.

Core Features & Use Cases

  • Decision documentation with rationale: Records context, drivers, options considered, and consequences so future readers can understand the “why,” not just the “what.”
  • ADR lifecycle and traceability: Tracks status over time (proposed, accepted, deprecated, superseded, rejected) and links related ADRs to form a decision graph.
  • Practical templates for consistency: Provides multiple ADR formats (standard MADR, lightweight, Y-statement, deprecation, and RFC-style) to match decision complexity.

Use cases include capturing technology choices (e.g., database or API patterns), documenting integration/security architecture decisions, and creating onboarding-ready records for teams maintaining a system over time.

Quick Start

Use the architecture-decision-records skill to write a new ADR describing an important system decision, including context, considered options with trade-offs, the chosen approach, and the expected consequences.

Frequently Asked Questions about architecture-decision-records

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

FAQPage Schema
What is an architecture decision record and when do I need one?

An architecture decision record (ADR) captures the context, rationale, and trade-offs behind significant technical choices. You need an ADR when adopting frameworks or making database, API, security, and integration decisions to preserve context for team onboarding.

How do I document technical trade-offs for a system design decision?

To document technical trade-offs for system design, record the context, drivers, and considered options alongside expected consequences. Using a consistent ADR template ensures future readers understand the accepted trade-offs and the specific reasoning behind the chosen approach.

What is the best way to track architectural decision history over time?

The best way to track decision history is maintaining an ADR lifecycle with statuses like proposed, accepted, deprecated, superseded, or rejected. Linking related records forms a decision graph that preserves traceability across evolving software systems.

Can I use a lightweight ADR format for simple engineering governance decisions?

Yes, you can use a lightweight ADR format for simple engineering governance decisions. Multiple templates like MADR, Y-statement, and RFC-style formats match decision complexity, allowing you to produce consistent artifacts without excessive overhead for straightforward choices.

How do I write an ADR to accelerate team onboarding?

Write an ADR for team onboarding by clearly detailing context, options considered with trade-offs, the final decision, and consequences. This preserves the why behind technical choices, preventing new engineers from repeating past mistakes and accelerating system comprehension.