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.