Incident Response and Postmortems

Pathrule1 Rule • 1 Memory • 3 Skills

Incident response and postmortems turn a production failure into coordinated mitigation and durable system improvement. This bundle defines incident authority, communication, evidence capture, safe operational changes, handoffs, blameless analysis, and measurable follow-up. Unlike Observability, it governs what people and systems do after a signal indicates impact rather than how telemetry and service objectives are instrumented.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

manage-incident

runbooks/

One incident commander owns coordination

run-incident-handoff

docs/

postmortems/

The timeline records observations and decisions separately

write-blameless-postmortem

Rules

One incident commander owns coordination/runbookshighstrictA declared incident commander sets priorities, assigns roles, approves high-risk changes, and maintains shared state.

1	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.
2
3	- Separate incident command, operations, communications, and subject-matter roles even when one person temporarily holds several.
4	- Prioritize user impact, safety, and reversible mitigation before complete causal analysis.
5	- Route production changes through a visible log with actor, time, hypothesis, expected signal, and rollback condition.
6	- Hand off command explicitly with current impact, actions, risks, owners, and next decision time.
7
8	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.

Memories

The timeline records observations and decisions separately/docs/postmortemsIncident recollection changes under stress, and a later narrative can accidentally present uncertain hypotheses as facts.

1	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.
2
3	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.
4
5	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.

Skills

manage-incident/rootManage a production incident from declaration through mitigation, recovery validation, communication, and handoff.

1	---
2	name: manage-incident
3	description: Manage a production incident from declaration through mitigation, recovery validation, communication, and handoff.
4	---
5
6	# Manage Incident
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Declare severity, user impact, incident channel, commander, operations lead, communications lead, and the next update time.
11	2. Stabilize the system with the safest reversible action, record the expected signal and rollback condition, and limit concurrent production changes.
12	3. Maintain a timestamped timeline, update stakeholders on impact and mitigation without unsupported cause claims, and reassess severity as evidence changes.
13	4. Validate recovery against user-facing signals, monitor for regression, assign postmortem ownership, and hand off any residual risk or cleanup.
14
15	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.

run-incident-handoff/runbooksHand off an active incident without losing authority, context, risks, or pending decisions.

1	---
2	name: run-incident-handoff
3	description: Hand off an active incident without losing authority, context, risks, or pending decisions.
4	---
5
6	# Run Incident Handoff
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Confirm the incoming commander and role owners are present, available, and able to access every required system and communication channel.
11	2. State current impact, severity, leading evidence, disproven hypotheses, mitigations, recent changes, and whether rollback is still possible.
12	3. Review active risks, customer or regulatory commitments, queued actions, owners, deadlines, and the next decision or communication time.
13	4. Record the transfer in the timeline, announce the new commander, and have the incoming lead restate priorities before outgoing responders leave.
14
15	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.

write-blameless-postmortem/docs/postmortemsWrite and review a blameless postmortem with evidence, system causes, and measurable corrective actions.

1	---
2	name: write-blameless-postmortem
3	description: Write and review a blameless postmortem with evidence, system causes, and measurable corrective actions.
4	---
5
6	# Write Blameless Postmortem
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Define impact, duration, affected users, detection, response, and recovery from verified evidence; distinguish facts from unresolved questions.
11	2. Build the timeline and analyze contributing technical, process, coordination, and organizational conditions without assigning blame to individuals.
12	3. Explain why safeguards did not prevent or limit impact, then create prevention, mitigation, detection, and response actions with owners and verifiable end states.
13	4. Review with responders and affected owners, publish at the appropriate access level, track actions to closure, and link recurrence or trend analysis.
14
15	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.

Why this pattern

Agents suggest simultaneous fixes, overwrite evidence, or optimize for root cause while users are still affected, creating risky changes and an unusable incident record.

Built for Teams operating production services with on-call ownership and cross-team incident coordination.

Keeps your assistant from:

Multiple responders making conflicting production changes
Root-cause investigation delaying impact mitigation
Postmortem actions with no owner or verifiable end state

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25