architecture-decisions

Document architectural decisions with Context, Decision, Consequences, and References sections.

42|9|Updated Mar 16, 2026
One-click install
npx skills add https://github.com/drvoss/everything-copilot-cli --skill architecture-decisions-drvoss
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-decisions
Source: https://github.com/drvoss/everything-copilot-cli/tree/main/skills/documentation/architecture-decisions
Command: npx skills add https://github.com/drvoss/everything-copilot-cli --skill architecture-decisions-drvoss

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Architecture decisions often require formal capture to avoid costly reversals and misaligned teams; ADRs provide a structured way to document context, rationale, and consequences.

Core Features & Use Cases

  • ADR creation workflow: standardizes how decisions are recorded, organized, and revised.
  • Context, Decision, Consequences: clear sections to capture trade-offs, constraints, and outcomes.
  • Use Case: when choosing a technology stack or API design, produce an ADR file under docs/decisions/.

Quick Start

Create an ADR file documenting the chosen architectural decision with context, options, and consequences under docs/decisions/.

Frequently Asked Questions about architecture-decisions

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

FAQPage Schema
How do I document architectural decisions to capture rationale and trade-offs?

To document architectural decisions, create an ADR file under docs/decisions/ that records context, trade-offs, constraints, and outcomes using structured sections for Context, Decision, Consequences, and References.

What is an ADR and when do I need to create one for software architecture?

An ADR is an Architecture Decision Record that formally captures context, rationale, and consequences for high-risk technical choices. You need one when choosing tech stacks, infrastructure, API designs, or data models to avoid costly reversals and misaligned teams.

What sections should be included in an architecture decision record?

An architecture decision record should include Context, Decision, Consequences, and References sections to standardize how trade-offs, constraints, and outcomes are captured for engineering teams.

How do I manage versioning and traceability for ADRs across engineering teams?

Manage ADR versioning and traceability by applying a disciplined workflow that standardizes how architectural decisions are recorded, organized, and revised in docs/decisions/ to maintain historical rationale across teams.

Does this ADR workflow work for infrastructure and API design decisions?

Yes, the ADR workflow applies to decisions about tech stacks, infrastructure, API designs, and data models across engineering teams, enforcing structured documentation of context and consequences for these high-risk technical choices.