# Pathrule Pattern: Incident Response and Postmortems (1.0.0) # ::pathrule:package:incident-response-postmortems ### [RULE] One incident commander owns coordination (path: /runbooks) A declared incident commander sets priorities, assigns roles, approves high-risk changes, and maintains shared state. Without explicit authority, responders duplicate work, make incompatible changes, and leave stakeholders unsure which update is current. Enforce this boundary in /runbooks so invalid work stops before it reaches another subsystem or creates an externally visible side effect. - Separate incident command, operations, communications, and subject-matter roles even when one person temporarily holds several. - Prioritize user impact, safety, and reversible mitigation before complete causal analysis. - Route production changes through a visible log with actor, time, hypothesis, expected signal, and rollback condition. - Hand off command explicitly with current impact, actions, risks, owners, and next decision time. Verification: Run a simulation with conflicting hypotheses and a shift change; confirm responders can identify the commander, approved action, rollback condition, and current status instantly. --- ### [MEMORY] The timeline records observations and decisions separately (path: /docs/postmortems) Incident recollection changes under stress, and a later narrative can accidentally present uncertain hypotheses as facts. Capture timestamps, observed signals, declared impact, decisions, actions, results, communications, and role changes from durable system sources where possible. Mark hypotheses and confidence at the time they were made instead of rewriting them after root cause is known. Normalize clocks and preserve links to logs, deploys, tickets, and chat without copying sensitive customer content. Use the timeline to examine detection, coordination, mitigation, and communication, not only the final technical trigger. Keep the decision explicit at /docs/postmortems; moving it into an incidental caller makes behavior depend on which route happened to execute first. See /runbooks for live command and the postmortem skill for analysis. That related boundary consumes this decision and carries the evidence that proves it still holds. --- ### [SKILL] manage-incident (path: /) --- name: manage-incident description: Manage a production incident from declaration through mitigation, recovery validation, communication, and handoff. --- # Manage Incident Run this procedure whenever the governed surface changes or its operational evidence becomes stale. 1. Declare severity, user impact, incident channel, commander, operations lead, communications lead, and the next update time. 2. Stabilize the system with the safest reversible action, record the expected signal and rollback condition, and limit concurrent production changes. 3. Maintain a timestamped timeline, update stakeholders on impact and mitigation without unsupported cause claims, and reassess severity as evidence changes. 4. Validate recovery against user-facing signals, monitor for regression, assign postmortem ownership, and hand off any residual risk or cleanup. Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory. --- ### [SKILL] run-incident-handoff (path: /runbooks) --- name: run-incident-handoff description: Hand off an active incident without losing authority, context, risks, or pending decisions. --- # Run Incident Handoff Run this procedure whenever the governed surface changes or its operational evidence becomes stale. 1. Confirm the incoming commander and role owners are present, available, and able to access every required system and communication channel. 2. State current impact, severity, leading evidence, disproven hypotheses, mitigations, recent changes, and whether rollback is still possible. 3. Review active risks, customer or regulatory commitments, queued actions, owners, deadlines, and the next decision or communication time. 4. Record the transfer in the timeline, announce the new commander, and have the incoming lead restate priorities before outgoing responders leave. Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory. --- ### [SKILL] write-blameless-postmortem (path: /docs/postmortems) --- name: write-blameless-postmortem description: Write and review a blameless postmortem with evidence, system causes, and measurable corrective actions. --- # Write Blameless Postmortem Run this procedure whenever the governed surface changes or its operational evidence becomes stale. 1. Define impact, duration, affected users, detection, response, and recovery from verified evidence; distinguish facts from unresolved questions. 2. Build the timeline and analyze contributing technical, process, coordination, and organizational conditions without assigning blame to individuals. 3. Explain why safeguards did not prevent or limit impact, then create prevention, mitigation, detection, and response actions with owners and verifiable end states. 4. Review with responders and affected owners, publish at the appropriate access level, track actions to closure, and link recurrence or trend analysis. Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.