Stats
Actions
Tags
From pm-engineering
Creates a structured Architecture Decision Record (ADR) documenting context, options, decision, consequences, and tradeoffs for any technical choice.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pm-engineering:architecture-decision-recordThe summary Claude sees in its skill listing — used to decide when to auto-load this 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*.
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.
Ask the user for these if not provided:
Date: [YYYY-MM-DD] Status: [Proposed / Accepted / Deprecated / Superseded by ADR-NNN] Author(s): [Name(s)] Deciders: [Who had final say — individual or team]
[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.]
Key constraints:
For each option, produce:
Description: [What this option is — 1–3 sentences]
Pros:
Cons:
Why this was ruled out (if not chosen): [Honest reason]
We will [chosen option].
[2–4 sentences explaining the decision in plain language. This should be readable in isolation — someone should understand the decision from this paragraph alone without reading the full document.]
[Include if the decision has non-obvious implementation gotchas, or if there are related tickets/RFCs implementers will need. Skip only if the decision is purely tooling selection with no implementation ambiguity.]
[Include unless the decision is permanent or self-evidently final. State a specific trigger condition — e.g. "Review if team grows beyond 20 engineers or traffic exceeds 10M requests/day" — not just "should be reviewed periodically".]
npx claudepluginhub mohitagw15856/pm-claude-skills --plugin pm-engineeringGenerates Architecture Decision Records with context, rationale, alternatives, and status lifecycle. Prevents forgotten design rationale.
Generates standardized Architecture Decision Records (ADRs) documenting technical decisions, context, evaluated alternatives, rationale, and consequences. Saves sequentially to docs/adr/.
Creates Architecture Decision Records in Nygard format to document technical decisions, context, and consequences. Use when making choices about architecture, technology selection, or development patterns.