postmortem-template
Write this after a significant bug or incident is resolved. The goal is **systems, not scapegoats** — ask how the process let the defect through, not who typed it.
$ npx -y skills add vanara-agents/skills --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
Write this after a significant bug or incident is resolved. The goal is **systems, not scapegoats** — ask how the process let the defect through, not who typed it.
Agent definition
postmortem-template.mdBlameless Postmortem Template
Write this after a significant bug or incident is resolved. The goal is **systems, not scapegoats** — ask how the process let the defect through, not who typed it.
Summary
- **Title:** _short description of the failure_
- **Date / duration:** _when it started, when it was resolved_
- **Severity / impact:** _who/what was affected, how badly (users, data, revenue)_
- **Status:** Resolved / Mitigated / Monitoring
Timeline (UTC)
| Time | Event | |---|---| | 14:01 | Deploy of `abc123` | | 14:05 | Error rate alarm fires | | 14:12 | On-call acknowledges, begins investigation | | 14:30 | Root cause identified (see below) | | 14:38 | Fix deployed, error rate normal |
Root cause
State the **confirmed** cause, distinguished from the symptom, with `file:line` and the commit that introduced it. Explain *why the bad state arose*, not just where it crashed.
> e.g. `applyDiscount` mutated the shared `cart` array (`src/cart.js:48`), so a retried request applied > the discount twice. The symptom was a wrong total at checkout; the cause was shared mutable state.
Detection
- How was it found? (alarm / customer report / log)
- How long until detection? Could a metric or test have caught it sooner?
Resolution & recovery
- What fixed it (the minimal change at the cause)?
- Any cleanup needed (data backfill, cache invalidation)?
The five whys
1. Why did the total double? → discount applied twice. 2. Why twice? → request was retried and the cart was mutated. 3. Why was it mutated? → `applyDiscount` edited the array in place. 4. Why in place? → no immutability convention in cart code. 5. Why no convention? → no lint rule / review check for shared mutation.
Action items
| Action | Owner | Type | Status | |---|---|---|---| | Add regression test for double-retry discount | | prevent | | | Make cart operations immutable | | fix-class | | | Add alarm on total-mismatch metric | | detect | |
What went well / what was lucky
_Separate good process from good fortune — luck isn't repeatable._
Read more
Blameless Postmortem Template
Write this after a significant bug or incident is resolved. The goal is **systems, not scapegoats** — ask how the process let the defect through, not who typed it.
Summary
- **Title:** _short description of the failure_
- **Date / duration:** _when it started, when it was resolved_
- **Severity / impact:** _who/what was affected, how badly (users, data, revenue)_
- **Status:** Resolved / Mitigated / Monitoring
Timeline (UTC)
| Time | Event | |---|---| | 14:01 | Deploy of `abc123` | | 14:05 | Error rate alarm fires | | 14:12 | On-call acknowledges, begins investigation | | 14:30 | Root cause identified (see below) | | 14:38 | Fix deployed, error rate normal |
Root cause
State the **confirmed** cause, distinguished from the symptom, with `file:line` and the commit that introduced it. Explain *why the bad state arose*, not just where it crashed.
> e.g. `applyDiscount` mutated the shared `cart` array (`src/cart.js:48`), so a retried request applied > the discount twice. The symptom was a wrong total at checkout; the cause was shared mutable state.
Detection
- How was it found? (alarm / customer report / log)
- How long until detection? Could a metric or test have caught it sooner?
Resolution & recovery
- What fixed it (the minimal change at the cause)?
- Any cleanup needed (data backfill, cache invalidation)?
The five whys
1. Why did the total double? → discount applied twice. 2. Why twice? → request was retried and the cart was mutated. 3. Why was it mutated? → `applyDiscount` edited the array in place. 4. Why in place? → no immutability convention in cart code. 5. Why no convention? → no lint rule / review check for shared mutation.
Action items
| Action | Owner | Type | Status | |---|---|---|---| | Add regression test for double-retry discount | | prevent | | | Make cart operations immutable | | fix-class | | | Add alarm on total-mismatch metric | | detect | |
What went well / what was lucky
_Separate good process from good fortune — luck isn't repeatable._
🐒 Free agents, skills & packs for Claude Code One subscription. An army of Claude Code agents. 30 production-grade agents, skills, and packs for Claude Code — free, Apache-2.0, install with one command.
Repo: vanara-agents/skills
Other agents on vanara-agents-skills.
- AGENT
Use when designing a new HTTP/GraphQL API or changing an existing one — modeling resources, defining endpoint contracts, choosing status codes, pagination, filtering, error envelopes, versioning, and idempotency. Produces a reviewable API contract plus an OpenAPI snippet, not
Open agent - review-notes
This shows how the api-designer agent reviews a flawed draft. Findings are severity-ranked so the implementer fixes the contract-breakers first. Severity legend: **CRITICAL** (breaks clients / data risk), **HIGH** (real bug or inconsistency), **MEDIUM** (maintainability),
Open agent - contract-and-openapi
The contract is the deliverable. Express it as an **OpenAPI 3.1** document so it is human-readable *and* machine-checkable. This reference covers how to structure that document and what `scripts/lint-openapi.mjs` enforces.
Open agent - design-checklist
Run through this before declaring an API contract done. It is ordered the way you should *design*: resources first, cross-cutting rules last. Every box is a place real APIs go wrong in production.
Open agent - versioning-and-evolution
APIs are forever once published: a consumer you've never met may depend on any field you expose. Design so you can **add without breaking**, and version explicitly when you must break.
Open agent - pr-comment-template
Copy-paste templates for leaving review comments. Keep each comment to one finding: an anchor, the problem, and the fix.
Open agent