architecture-decision-records

Create and manage Architecture Decision Records using MADR, Lightweight, Y-Statement, Deprecation, and RFC templates.

1|Updated Jun 18, 2025
One-click install
npx skills add https://github.com/knopki/dotfiles --skill architecture-decision-records-knopki
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-decision-records
Source: https://github.com/knopki/dotfiles/tree/main/home/private_dot_config/opencode/skills/architecture-decision-records
Command: npx skills add https://github.com/knopki/dotfiles --skill architecture-decision-records-knopki

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides a structured framework for documenting significant technical decisions, ensuring clarity, consistency, and maintainability of architectural choices over time.

Core Features & Use Cases

  • Standardized Documentation: Offers multiple templates (MADR, Lightweight, Y-Statement, Deprecation, RFC) for various decision-making scenarios.
  • Lifecycle Management: Guides users through the process of proposing, accepting, deprecating, or superseding decisions.
  • Best Practices: Includes guidelines on ADR creation, review processes, and common pitfalls to avoid.
  • Use Case: When deciding on a new primary database for a project, use this Skill to create an Architecture Decision Record (ADR) that captures the context, decision drivers, considered options, the final decision, and its consequences.

Quick Start

Use the architecture-decision-records skill to write a new ADR for adopting TypeScript in the frontend.

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 should I document technical decisions?

An Architecture Decision Record (ADR) documents significant technical choices by capturing context, decision drivers, considered options, and consequences. You should write an ADR whenever making impactful software design decisions to ensure clarity and maintainability over time.

How do I write an Architecture Decision Record for adopting a new framework?

To write an Architecture Decision Record, select a template like MADR or Lightweight, then document the context, decision drivers, considered options, final decision, and consequences. This Skill guides you through proposing and accepting the technical decision using standardized formats.

Can I use MADR or Y-Statement formats for software design documentation?

Yes, you can use MADR, Y-Statement, Lightweight, Deprecation, and RFC formats for software design documentation. This Skill supports these multiple templates to handle various architectural decision-making scenarios and documentation requirements.

What is the best way to manage the lifecycle of technical decisions and deprecate old ones?

The best way to manage the lifecycle of technical decisions is using ADR guidelines for proposing, accepting, deprecating, or superseding records. This Skill provides structured lifecycle management to track when architectural choices are replaced or retired.

Does this ADR documentation approach support the RFC format for technical decisions?

Yes, this ADR documentation approach supports the RFC format alongside MADR, Y-Statement, Lightweight, and Deprecation templates. It includes guidelines for review processes to ensure comprehensive documentation of architectural rationale and consequences.