postmortem
FeaturedTest a retrospective causal question against outcome evidence. Use when: a postmortem is explicitly requested; finishing a task does not require a report or lesson.
Install
Quality Score: 97/100
Skill Content
Details
- Author
- boshu2
- Repository
- boshu2/agentops
- Created
- 10 months ago
- Last Updated
- today
- Language
- Go
- License
- Apache-2.0
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
premortem-postmortem
Run premortems before risky work and postmortems after incidents or failures. Use when the user asks for premortem, postmortem, incident review, retrospective, launch risk, "how will this fail", or "what killed this". Build the causal chain from evidence and produce the premortem/postmortem document with owners and verification.
engineering-incident-postmortem
Runs a blameless incident post-mortem: reconstructs the timeline from evidence, separates trigger from cause from contributing conditions, and produces owned, dated remediation actions. Use when an incident, outage, degradation, or severe bug has been resolved and a written review is due, or when a draft post-mortem needs review before it goes to a review board. Trigger on 'write the post-mortem', 'RCA for the outage', 'incident review', 'five whys', 'what was the root cause', 'corrective actions for INC-'. Not for triaging an incident that is still live — that is engineering-incident-command; not for routine bug write-ups with no customer or availability impact, which belong in the ticket.
project-postmortem
Generate an evidence-grounded project retrospective — pulled from git history and decision docs, not memory — that grades the project on separate dimensions, splits what went right from wrong, reduces the failure to its root ordering error, extracts transferable lessons for the next project, and names what survives. Use whenever a project ships, stalls, or gets sunset and someone wants the writeup — "post-mortem", "retrospective", "what went wrong with X", "we're sunsetting X, write it up", or mid-project "why did this go sideways". The method cites commit hashes or sources for every claim, builds a timeline of when validation happened vs building, separates pros from cons including uncomfortable symmetries, and ends with a per-dimension scorecard plus a what-survives list — then runs a check that fails any vanity scorecard or uncited narrative. Distinct from drift-check (audits live docs) and conductor-memory/session-bookend (capture session state for continuity); this extracts backward-looking lessons.