Runbook to Postmortem Connector Orchestrator

The Prompt

You are an operational knowledge engineer. Turn live operational signals into a runbook-backed postmortem draft plan with controlled, approval-gated writeback steps.

PREFERRED LLM / FAMILY:
{{preferred_llm}}

INCIDENT SNAPSHOT:
{{incident_snapshot}}

SIGNAL INVENTORY:
{{signal_inventory}}

ROOT CAUSE HYPOTHESES:
{{root_cause_hypotheses}}

WRITE TARGETS:
{{write_targets}}

RETROSPECTIVE AUDIENCE:
{{retrospective_audience}}

LEARNING TARGETS:
{{learning_targets}}

Return exactly these sections:

1) Chronology Draft
- Reconstructed timeline with signal anchors and confidence levels.
- Gaps in timeline evidence and verification tasks.

2) Runbook Comparison
- Compare planned runbook steps vs executed actions.
- Missing or duplicated actions and root-cause impact on workflow.

3) Draft Incident Brief
- Incident impact summary.
- Affected systems, users, and recovery quality indicators.

4) Postmortem Bundle (DRAFT)
- Findings rows: claim, evidence, owner, confidence, proposed actions.
- Corrective action table for process, tooling, and runbook updates.
- Lessons-learned and follow-up owners.

5) Connector Writeback Plan
- Read sources, draft updates, approval requirements.
- MCP draft payloads for runbook or knowledge pages.

6) Governance and Verification
- What must be signed off before updating shared operating docs.
- Retention and audit requirements.
- Trigger list for model review if confidence is low.

Rules:
- Only propose writebacks in draft mode with explicit approvals.
- Avoid over-certainty around root causes; include unknowns.
- Include a short "what remains unresolved" section.

When to Use

Use this when incident follow-up is delayed because evidence is spread across multiple systems and teams need a single, auditable draft for postmortem and process updates.

Variables

Variable	Description	Example
preferred_llm	Model family for synthesis and timeline reasoning	gpt, o3
incident_snapshot	High-level incident summary and boundary conditions	”Billing webhook lag spike affecting 8% of monthly invoices.”
signal_inventory	Sources and telemetry to inspect	”Monitoring graphs, on-call notes, incident Slack thread, Jira tasks.”
root_cause_hypotheses	Initial hypotheses to test	”Queue backpressure, schema mismatch, cache eviction.”
write_targets	Places to draft postmortem outputs	”Notion, Confluence, Jira knowledge base.”
retrospective_audience	Audience for postmortem content	”SRE, Incident Commander, Product Lead.”
learning_targets	Training goals for teams	”Improve incident runbook adoption and escalation timing.”

Tips & Variations

• Add a second pass that only edits action owners and owners of follow-up tasks.
• Request a “confidence map” so each claim has evidence freshness and contradiction markers.
• Require a one-line impact summary for leadership and one technical section for operators.
• Ask for a “known-unknowns” backlog item list before finalizing.

Example Output

• Chronology draft highlights evidence-backed timeline with explicit signal gaps.
• Postmortem bundle includes action recommendations split into “immediate”, “next sprint”, and “longer term”.
• Connector plan marks all suggested MCP writes as DRAFT and links them to approvers.

Related site references

• AI Use Case: Runbooks and postmortem knowledge loop
• AI Use Case: Meeting follow-through system
• Tool: n8n
• Tool: LangChain
• Tool: OpenClaw
• Model: GPT
• Model: o3
• Concept: Tool use and function calling