incident-postmortem-a400ef — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited incident-postmortem-a400ef (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output enforces blameless framing throughout — system gaps over individual failures — and drives toward specific, closeable action items rather than vague process commitments.
Not quite this? Use agent-incident-postmortem when an AI agent caused the incident (runaway tool use, a shipped hallucination).The action items don't have to stay on the page: hand them to action-runner, which previews them (dry-run, risk-rated), runs only what you approve via the connected action MCP, and records what was done back to the brain. Typical: file a follow-up issue per action item (🟡), assigned to its owner with a due date. This skill proposes; action-runner gates and runs — never silently.
Third in the incident-response spine: `/slo-error-budget` (frame) → `/debugging-log-analyser` → `incident-postmortem` → `/oncall-runbook`. It receives the root-cause diagnosis from /debugging-log-analyser (read it rather than re-diagnosing) and hands /oncall-runbook the contributing factors and prioritised action items — and the error budget from /slo-error-budget decides how urgent those actions are. Blameless, root cause vs contributing factors, and action item are defined once in docs/craft/incident-response.md; blameless is the load-bearing rule.
A postmortem fails the moment it assigns blame — the honest data dries up and every future incident is under-reported. Phase 1 sets that frame; everything depends on it.
that let a competent person make the move, never the person. This isn't politeness — it's the precondition for the truthful timeline the rest of the skill needs. Done when: the framing is explicit and no sentence in the document blames an individual; failures are attributed to system gaps.
resolution with real timestamps (from the diagnosis and logs, not memory). Detection, mitigation, and resolution are distinct events — track each. Done when: the timeline has real timestamps and separates detection/mitigation/ resolution, and the impact is quantified (users, duration, scope).
the contributing factors are what let it reach users and persist (the missing alert, the skipped canary, the unclear runbook). A postmortem with a root cause and no contributing factors hasn't looked hard enough. Done when: at least the load-bearing contributing factors are named, each pointing at a system gap that's fixable.
specific action items, each with an owner and a date; vague "improve monitoring" items decay. Prioritise them against the error budget (spent → now; healthy → soon). Done when: every action item has an owner and a date, and /oncall-runbook could turn the detection/mitigation learnings into an entry without re-analysing the incident.
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).
If a professional-brain (brain/) exists, use it before asking:
entities/ file and any related prior decisions/ or past incidents (recurring root causes are the most important thing to surface).decisions/, and the root-cause learning to knowledge/ — tag a measured cause [data] and a suspected one [hunch], never the reverse.Incident ID: [ID] Severity: [P1/P2/P3] Date: [Date] Duration: [Start time → Resolution time — total duration] Status: [Resolved / Monitoring / Ongoing] Author: [Leave blank for user to fill] Last updated: [Date]
[3–5 sentences. Describe what happened, who was affected, and what was done to resolve it. Written for a non-technical stakeholder. No jargon. No blame.]
| Dimension | Details |
|---|---|
| Users affected | [Number or percentage] |
| Services degraded | [List affected services] |
| Business impact | [Revenue, SLA breach, support tickets, etc. if known] |
| Duration | [Total time from first detection to full resolution] |
List events in chronological order. Each entry: [HH:MM UTC] — [What happened. Who did what. What changed.]
Rules for timeline entries:
Timeline, drawn — also render the incident timeline as a Mermaid Gantt so the gaps (e.g. detection → escalation) are visible at a glance (it renders live in the playground and exports as PNG). Use the incident phases as bars; keep it blameless and system-focused:
gantt
title Incident timeline (UTC)
dateFormat HH:mm
axisFormat %H:%M
section Phases
Undetected impact :22:00, 18m
Detection :milestone, 22:18, 0m
Investigation :22:18, 22m
Mitigation :22:40, 15m
Resolved :milestone, 22:55, 0mPrimary root cause: [One clear sentence. Technical but plain. "A misconfigured deployment config caused..."]
Contributing factors:
Why did our existing safeguards not prevent this? [Honest paragraph explaining why monitoring, tests, or processes didn't catch this earlier. This is where blameless analysis matters most — focus on system gaps, not individual failures.]
What fixed it? [Clear description of the actual fix — one paragraph] Why did this work? [Brief technical explanation] Was there a temporary mitigation before full resolution? [Yes/No — describe if yes]
| # | Action | Owner | Due Date | Priority |
|---|---|---|---|---|
| 1 | [Specific, testable action] | [Team or person] | [Date] | P1/P2/P3 |
Rules for action items:
[3–5 honest observations about the response. Include: fast collaboration, good runbooks used, effective escalation, clear communication. This section builds team confidence and reinforces good habits.]
[3–5 key insights from this incident that are worth sharing beyond this team. Write these as transferable lessons — e.g. "Our runbook for database failover didn't account for read-replica lag. All runbooks involving database failover should be reviewed."]
[Optional — list external communications sent: status page updates, customer emails, support responses. Include timestamps.]
Score any output of this skill before handing it over; 32+ is ship-quality.
| Dimension | 0 | 5 | 10 |
|---|---|---|---|
| Blamelessness with truth | Names-and-shames, or sanitizes so much the story vanishes | Blameless wording but individual actions blurred | Individuals' actions stated factually inside a systems framing — honest and safe at once |
| Root-cause depth | Stops at the symptom or "human error" | Names a system gap but only one "why" deep | Root cause plus contributing factors explain why the system allowed it, not just what broke |
| Timeline forensic quality | Sparse, unordered, or missing detection-to-resolution beats | Complete but without timestamps or decision points | Timestamped, includes detection lag, decision points, and dead ends actually explored |
| Action-item accountability | Vague improvements, no owners | Owners assigned but items unticketable or dateless | Every item ticketable with owner and due date, mapped to a root cause or contributing factor |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.