architecture-decision

Document architecture decisions as structured ADRs with context, alternatives, and consequences.

1|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill architecture-decision-kalilurrahman
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-decision
Source: https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts/tree/main/06-system-design/architecture-decision
Command: npx skills add https://github.com/kalilurrahman/kr-claudiator-skills-original-prompts --skill architecture-decision-kalilurrahman

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Architectural decisions often live in chat threads or tribal knowledge and get lost when teams change, making it impossible to understand why a system was built a certain way. This Skill produces formal Architecture Decision Records (ADRs) that capture context, options, trade-offs, and rationale in version control. ## Core Features & Use Cases - Structured ADR Template: Generates records with status, deciders, context, decision, alternatives with pros/cons, and consequences (positive, negative, neutral). - Decision Lifecycle Management: Supports statuses from Proposed through Accepted, Rejected, Superseded, and Deprecated, with an index structure for organizing ADRs in docs/adr/. - Common Patterns & Anti-Patterns: Includes templates for technology choices, architectural patterns, and build-vs-buy decisions, plus examples of vague or incomplete ADRs to avoid. - Use Case: Your team must choose between PostgreSQL, MySQL, and MongoDB for a payments system. Use this Skill to produce an ADR documenting requirements, cost estimates, trade-offs, and follow-up actions so future engineers understand the reasoning. ## Quick Start Ask the AI to write an ADR for choosing PostgreSQL over MySQL and MongoDB as the primary database, including context, alternatives, and consequences.

Frequently Asked Questions about architecture-decision

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

FAQPage Schema
How do I write an architecture decision record?

An ADR documents the context and requirements, the chosen decision, 3-5 alternatives with pros and cons, and the positive, negative, and neutral consequences. Store it as a numbered Markdown file in version control with a status like Accepted or Proposed.

When should I write an ADR?

Write an ADR for significant decisions like technology choices, architectural patterns, API design, deployment strategy, security models, and data model changes. Skip it for implementation details, code style, routine library updates, and bug fixes.

What is the difference between ADR statuses like Superseded and Deprecated?

Superseded means the decision was replaced by a newer ADR, which should be linked from the old record. Deprecated means the decision is still in use but planned for removal. Accepted decisions remain the current state of the system.

Should ADRs be edited after they are accepted?

No, ADRs are immutable once accepted because they capture the decision at a point in time. If a decision changes, write a new ADR that supersedes the old one and link them, preserving the decision history.

What tools can manage architecture decision records?

ADRs can be plain Markdown files in a docs/adr directory with an index README. CLI tools like adr-tools and adr-log automate creation and listing, while Log4brains provides a web UI for browsing ADRs.