Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From pm-skills
Creates Architecture Decision Records (ADRs) in Nygard format to document significant technical decisions, context, and consequences. Use for system architecture, technology selection, or development patterns.
npx claudepluginhub product-on-purpose/pm-skills --plugin pm-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/pm-skills:develop-adrThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Creates structured Architecture Decision Records (ADR) in Nygard format with context, options, decision, consequences, and tradeoffs for any technical choice.
Generates standardized Architecture Decision Records (ADRs) documenting technical decisions, context, evaluated alternatives, rationale, and consequences. Saves sequentially to docs/adr/.
Generates Architectural Decision Records (ADRs) by detecting project template conventions, assigning sequential numbers, supporting MADR/Nygard/Alexandrian formats, and saving markdown files. Use for documenting technical decisions.
Share bugs, ideas, or general feedback.
An Architecture Decision Record documents a significant technical decision along with its context and consequences. ADRs capture the "why" behind architectural choices so future team members understand the reasoning . especially important when they question why something was done a particular way. This skill follows Michael Nygard's lightweight ADR format.
When asked to create an ADR, follow these steps:
Assign a Number and Title ADRs are numbered sequentially (ADR-001, ADR-002, etc.) for easy reference. The title should be a short noun phrase describing the decision, like "Use PostgreSQL for order data" or "Adopt React for frontend."
Set the Status New ADRs start as "Proposed." After team review, they become "Accepted," "Deprecated," or "Superseded by ADR-XXX." Status changes should be tracked.
Describe the Context Explain the circumstances that led to this decision. What problem are you solving? What forces are at play (technical constraints, team expertise, timeline, cost)? This section should help a reader who wasn't there understand why this decision was needed.
State the Decision Clearly articulate what you decided. Use active voice: "We will use..." rather than "It was decided..." Be specific about what is and isn't included in the decision.
Document the Consequences List the outcomes of this decision . positive, negative, and neutral. Good ADRs are honest about trade-offs. What becomes easier? What becomes harder? What new constraints or options does this create?
Use the template in references/TEMPLATE.md to structure the output.
Before finalizing, verify:
See references/EXAMPLE.md for a completed example.