Postmortems

Deep blameless postmortem workflow—timeline, impact, root cause vs contributing factors, what went well/poorly, action items with owners, and follow-through....

Security Scan

This is an instruction-only postmortem workflow that is coherent with its name/description and does not request credentials, install software, or instruct the agent to access unrelated system data.

Purpose & Capability

The SKILL.md content matches the name/description—stepwise, blameless postmortem guidance. There are no unexpected requirements (no binaries, env vars, or config paths) that would be disproportionate to this purpose.

Instruction Scope

The instructions are procedural guidance for running a postmortem (scope, timeline, RCA, actions, follow-up). They do not tell the agent to read arbitrary files, collect system credentials, or send data to external endpoints. Mentions of linking metrics/traces or coordinating with legal are advisory, not commands to access unrelated resources.

Install Mechanism

No install spec and no code files — lowest-risk form. Nothing will be written to disk or downloaded.

Credentials

No environment variables, credentials, or config paths are requested. The declared requirements are minimal and proportional to a documentation/workflow skill.

Persistence & Privilege

always:false and default autonomous invocation are set (normal). The skill does not request persistent system presence or modifications to other skills or system configuration.

Assessment

This skill is instruction-only and appears coherent with its stated purpose. Before installing: 1) Note the skill's source/homepage are not provided—if provenance matters, prefer skills with a known author or repo. 2) The skill may be invoked autonomously by agents (default behavior); that is normal but be mindful that any automated use could surface incident details—avoid letting an agent post sensitive or PII-containing timelines externally. 3) For real security incidents follow your org's legal/security policies (the SKILL.md explicitly advises coordination). 4) If you want stronger assurance, ask the publisher for provenance (repo or contact) or request an explicit permission model for any automatic posting of postmortem content.

Postmortems (Deep Workflow)

A good postmortem learns without blaming individuals. It produces owned actions that reduce recurrence or improve detection—not a generic “we will communicate better.”

When to Offer This Workflow

Trigger conditions:

• SEV incidents, customer-visible outages, data loss scares
• Near-miss worth documenting (luck prevented impact)
• Blame culture risk—need facilitation structure

Initial offer:

Use six stages: (1) scope & audience, (2) timeline & impact, (3) root cause analysis, (4) what worked / didn’t, (5) action items, (6) communication & follow-up). Confirm internal-only vs customer-facing summary.

---

Stage 1: Scope & Audience

Goal: Readers (exec, eng, CS) and sensitivity (PII, security details redacted).

Practices

• Blameless framing in invite and template

Exit condition: Template chosen; owner for final doc.

---

Stage 2: Timeline & Impact

Goal: Minute-resolution timeline with UTC; detection vs start vs mitigation vs resolution.

Impact

• Users affected, duration, data integrity if relevant, SLA breach

Exit condition: Customer communication aligned with facts here.

---

Stage 3: Root Cause Analysis

Goal: Five whys or fishbone as tool, not ritual—root cause and contributing factors separate.

Practices

• Root: fix that stops recurrence class (with evidence)
• Contributors: process, missing tests, alert gaps

Exit condition: No single person named as “root cause.”

---

Stage 4: What Worked / Didn’t

Goal: Reinforce good (runbooks, heroes who followed process) and fix bad (missing dashboards).

---

Stage 5: Action Items

Goal: Specific, tracked tickets with owners and dates; types: prevent, detect, recover, process.

Practices

• Avoid vague “add monitoring” without metric names

Exit condition: Action items in issue tracker linked.

---

Stage 6: Communication & Follow-Up

Goal: Share summary with org; review completion in 30/60 days.

Practices

• External postmortem if customer promise requires

---

Final Review Checklist

• Blameless tone; facts and timeline clear
• Impact quantified where possible
• Root cause and contributing factors distinguished
• Action items owned, dated, and tracked
• Follow-up review scheduled

Tips for Effective Guidance

• Severity should match depth of postmortem (lightweight for small incidents).
• Link to metrics and traces in appendix for engineers.
• Psychological safety enables honesty—leadership must model it.

Handling Deviations

• Security incident: coordinate with legal before public detail.
• Repeated same failure: escalate to architecture or SLO review.