architecture-decision-records

Name: architecture-decision-records
Availability: InStock
Author: ankurjain1121

Create structured ADR documents with context, decision, and consequences sections.

1|Updated Jan 15, 2026

Search Tags:#architecture #documentation #adr #rationale #decision-record #technology-evaluation

Ready to run

npx skills add https://github.com/Ankurjain1121/dev-workflow-skills --skill architecture-decision-records-ankurjain1121

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: architecture-decision-records
Source: https://github.com/Ankurjain1121/dev-workflow-skills/tree/main/plugins/framework-dev/skills/architecture-decision-records
Command: npx skills add https://github.com/Ankurjain1121/dev-workflow-skills --skill architecture-decision-records-ankurjain1121

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ADRs provide a structured way to capture context, decisions, and consequences of architectural choices, preventing knowledge loss and conflicting implementations.

Core Features & Use Cases

Standardized templates for documenting decisions (Context, Decision, Alternatives, Rationale, Consequences).
Decision-history traceability to track changes over time and reason about evolution.
Cross-team collaboration by making rationale accessible to engineers, product managers, and stakeholders.

Quick Start

Create an ADR document in the project repository with a clear title, date, status, and initial context. Fill in sections for Context, Decision, Alternatives, Rationale, and Consequences using ADR-001 as a template reference. Keep the ADR’s scope focused on significant architectural choices and link related ADRs for traceability.

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 why do I need to document rationale?▼

An architecture decision record (ADR) is a structured document that captures the context, decision, alternatives, and consequences of architectural choices. Documenting rationale prevents knowledge loss and conflicting implementations across project teams.

How do I write an ADR for technology evaluation and pattern selection?▼

To write an ADR for technology evaluation, create a document with a title, date, status, and context. Fill in sections for Context, Decision, Alternatives, Rationale, and Consequences using a standardized template to ensure decision-history traceability.

When should I create an architecture decision record instead of general documentation?▼

You should create an architecture decision record for significant architectural choices like technology evaluation, pattern selection, and architecture evolution. Keep the ADR scope focused on these decisions and link related ADRs for traceable consequences.

Can I use ADR documentation for cross-team collaboration and architecture evolution?▼

Yes, ADR documentation supports cross-team collaboration by making rationale accessible to engineers, product managers, and stakeholders. It provides decision-history traceability to track changes over time and reason about architecture evolution across projects.

What sections are required in a standardized ADR template for capturing trade-offs?▼

A standardized ADR template requires sections for Context, Decision, Alternatives, Rationale, and Consequences. These sections capture architectural decisions, trade-offs, and rationales while ensuring traceable consequences and decision-history traceability across projects.

What are the limitations of using ADRs for documenting architectural decisions?▼

ADRs focus on significant architectural choices like pattern selection and technology evaluation, so minor decisions may not warrant documentation. Scope must be kept focused to maintain decision-history traceability and prevent knowledge loss without creating excessive overhead.