Architecture Decision RecordCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: architecture-decision-record
description: "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."
---

# 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

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked *(assumed, confirm)* and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).
- **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.]

**Key constraints:**
- [Constraint 1: e.g. "Must be deployable on-premise for enterprise customers"]
- [Constraint 2: e.g. "Team has no prior Go experience"]
- [Add as many as are relevant]

---

## Options Considered

For each option, produce:

### Option [N]: [Name]

**Description:** [What this option is — 1–3 sentences]

**Pros:**
- [Pro 1]
- [Pro 2]

**Cons:**
- [Con 1]
- [Con 2]

**Why this was ruled out (if not chosen):** [Honest reason]

---

## Decision

**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.]

---

## Consequences

### Positive Consequences
- [What this decision enables or improves]
- [What risk it mitigates]

### Negative Consequences / Accepted Tradeoffs
- [What we're giving up or taking on as a result of this decision]
- [Technical debt or limitations introduced]
- [What must now be true for this decision to remain valid]

### Risks
- [What could cause this decision to be wrong in hindsight]
- [What would trigger us to revisit this decision]

---

## Implementation Notes

[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.]

---

## Review Date

[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".]

---

## Deeper Materials

This skill ships with support files — use them when they are available:

- **`references/decision-scoping.md`** — What Deserves an ADR (and What "Context" Must Contain). Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
- **`templates/adr.md`** — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

## Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

| 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 |

## Quality Checks

- [ ] Context explains the *why* — not just the *what*
- [ ] At least 2 options are documented (including the rejected ones)
- [ ] Rejected options include honest reasons for rejection
- [ ] Consequences include *negative* consequences — no decision is consequence-free
- [ ] Decision is stated in plain language in the Decision section
- [ ] Risks section identifies what would invalidate this decision
- [ ] Context section states the problem explicitly in its first 1–2

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.