post-incident-review
From the author
Use this skill when an incident or a serious near miss is closed and the team must learn from it, or an auditor asks for lessons learned, and someone says "run the post-mortem", "post-incident review", "lessons learned", "retro on the outage", "blameless review", "root cause of the incident" or "what do we change after this breach". Builds the timeline from records before the meeting, runs a blameless discussion, finds the contributing factors, and turns them into a few owned, dated actions linked to updates of the risk register, controls, playbooks and supplier records, then writes the review and an action tracker.
Install
npx skills add better-isms/grcskills --skill post-incident-review -a claude-code
Installs to .claude/skills/post-incident-review/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 82
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- incident-postmortemgithub/awesome-copilotUse when an outage, production incident, or significant service degradation has occurred and the team needs to write a structured blameless post-mortem. Triggers on phrases like "write a post-mortem", "incident review", "what went wrong", "outage report", "root cause analysis", or "RCA". Covers timeline reconstruction, contributing factor analysis, impact quantification, and action item generation with owners.Writing★ 40.4K
- post-mortemalirezarezvani/claude-skills/c-level-agents:post-mortem [decision] — Honest retrospective on an executed decision, scored against original assumptions and dissent. Closes the strategic sprint loop. Use when a decision hits its 90-day review checkpoint or its kill criteria trigger — e.g. scoring last quarter's pricing change against its pre-committed success metrics.Engineering★ 28.7K
- after-action-reportrampstackco/claude-skillsRun a structured after-action review (postmortem, retrospective) on a launch, incident, or completed project to capture timeline, root cause analysis, contributing factors, and actionable lessons. Use this skill whenever the user wants to run a postmortem, retrospective, AAR, or after-action review on any past event. Triggers on after-action report, AAR, postmortem, retrospective, retro, post-incident review, what went well what didn't, lessons learned, blameless postmortem, root cause analysis, RCA, five whys. Also triggers when the user has just shipped something or just resolved an incident and wants to capture learnings.Engineering★ 994
- write-a-postmorteminkeep/open-knowledgeWrite a blameless incident postmortem under postmortems/ following the Google SRE shape — evidence-based timeline, trigger vs root cause vs symptom, contributing factors, what went well, and owned+dated+verifiable action items. Read when asked to write a postmortem, do an incident review, run a root cause analysis, write up the outage, retro on the outage, or when the user says we had an incident and wants it documented. Do NOT read to frame a proposal (use frame-a-proposal), write a spec (use write-a-spec), record a decision (use record-a-decision), or review a design (use review-a-design) — a postmortem documents an incident that already happened, it does not propose, specify, decide, or critique future work.Writing★ 4.7K
- postmortem-writingwshobson/agentsWrite effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response processes.Writing★ 41.7K
- incident-managementcbrock84/headcountRuns an operational incident from detection to closed action — declaring it and naming a commander, separating the people restoring service from the people communicating, keeping a timeline as it happens, deciding when it is over, and running a review that produces a small number of changes someone actually completes. Use this to set up an incident process, run one, work out why the same failure keeps recurring, or fix a review practice that generates findings nobody closes.Engineering★ 2.1K
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in