From pm-engineering
Generates Architecture Decision Records (ADRs) in Nygard format for technical decisions, including context, options with pros/cons, rationale, consequences, and tradeoffs.
npx claudepluginhub mohitagw15856/pm-claude-skills --plugin pm-engineeringThis skill uses the workspace's default tool permissions.
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*.
Creates Nygard-format ADRs to document significant technical decisions, context, and consequences. Use for system architecture, technology selection, or development patterns.
Generates standardized Architecture Decision Records (ADRs) documenting technical decisions, context, evaluated alternatives, rationale, and consequences. Saves sequentially to docs/adr/.
Generates Architecture Decision Records (ADRs) capturing context, rationale, alternatives, and consequences in numbered, status-tracked Markdown format.
Share bugs, ideas, or general feedback.
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.]
[Optional but valuable: any specific patterns, gotchas, or guidance for the team implementing based on this decision. Link to relevant tickets, RFCs, or design docs if applicable.]
[Optional: "This decision should be reviewed if [condition] — e.g. team grows beyond 20 engineers, or traffic exceeds 10M requests/day."]