architecture-decision-record

mohitagw15856/pm-claude-skillsDeveloper ToolsAudit passedSnapshot c5ab87eb8cf6

Installs: 0

Summary

Create an Architecture Decision Record (ADR) for any technical decision. Use when asked to document a technical decision, write an ADR, record an architecture choice, or capture why a technology or approach was selected. Produces a structured ADR with context, decision, consequences, and tradeoffs.

SKILL.md

Architecture Decision Record (ADR) Skill

This skill produces a complete Architecture Decision Record (ADR) following the Nygard format — the most widely adopted standard. ADRs document the reasoning behind significant technical decisions so future team members understand not just what was decided, but why.

Required Inputs

Ask the user for these if not provided:

ADR number (sequential number in your ADR registry — e.g. 012; or "next available" if unknown)
Decision title (brief, e.g. "Use PostgreSQL as primary datastore")
Context (what situation led to this decision needing to be made?)
Options considered (at least 2; if only 1 is given, prompt for alternatives that were considered or ruled out)
Decision made (which option was chosen)
Reason for choice
Status (Proposed / Accepted / Deprecated / Superseded)
Author and date
Team context (optional — team size, relevant experience, org constraints; helps calibrate formality and depth of the Context section)

Output Format

ADR-[NNN]: [Decision Title]

Date: [YYYY-MM-DD] Status: [Proposed / Accepted / Deprecated / Superseded by ADR-NNN] Author(s): [Name(s)] Deciders: [Who had final say — individual or team]

Context

[3–6 sentences. Describe the situation, constraints, and forces at play that made this decision necessary. Include: the problem being solved, relevant system state, team constraints, timeline pressures, or non-negotiable requirements. Write as if explaining to someone joining the team 18 months from now who has no prior context.]

Dimension	0	5	10
Context reconstruction	Assumes the reader already knows the problem and the pressures	Problem stated, but the forces (team constraints, scale, deadline, forcing event) are missing	A reader two years later could guess the decision from the Context section alone
Options honesty	Only the chosen option, or rejected options written as strawmen	≥2 options, but rejection reasons are circular ("didn't meet requirements")	Every rejected option has genuine strengths and a specific losing constraint tied to a context pressure
Consequence balance	All consequences are positive	Token negatives with no operational specifics	Negatives name real debts, new operational burdens, and what must stay true for the decision to hold
Revisit triggers	No risks or review conditions stated	"Review periodically" — no measurable condition	Specific, measurable trigger conditions that would invalidate the decision, with an owner

architecture-decision-record

Summary

SKILL.md

Architecture Decision Record (ADR) Skill

Required Inputs

Output Format

ADR-[NNN]: [Decision Title]

Context

Options Considered

Option [N]: [Name]

Decision

Consequences

Positive Consequences

Negative Consequences / Accepted Tradeoffs

Risks

Implementation Notes

Review Date

Deeper Materials

Scoring Rubric (0–40)

Quality Checks

Anti-Patterns

Usage Examples

Related skills