Reflection Prompt for Postmortem Drafting

Use this prompt when an incident analyst or SRE has completed a first draft of a blameless postmortem and needs a structured self-critique before the document goes to wider review. The prompt acts as a second-pass reasoning layer that examines the draft for missing contributing factors, weak or cosmetic action items, hindsight bias, and gaps in the causal timeline. It is designed for engineering teams that treat postmortems as learning artifacts, not compliance paperwork, and who want to catch shallow analysis before it becomes the official record.

This prompt is not a replacement for human review, a postmortem authoring tool, or a root-cause analysis engine. It does not write the postmortem; it critiques an existing draft. Do not use it when the incident is still active, when the timeline is incomplete, or when the author has not yet committed to a blameless framing. The prompt assumes the draft contains a timeline, a description of contributing factors, and proposed action items. If those sections are missing, the critique will be noisy and unhelpful. For high-severity incidents with regulatory or legal exposure, always route the output through human counsel before finalizing.

Wire this prompt into your postmortem workflow as a pre-review gate. After the draft is written, run the reflection prompt and attach the critique to the document. Use the critique to revise the draft before sending it to peer reviewers. This catches the most common failure modes—hindsight bias, single-cause narratives, and action items that sound good but don't prevent recurrence—while the author still has context fresh in mind. Avoid using the reflection output as a score or grade; it is a revision aid, not a performance metric.

This prompt template is designed to be dropped into an AI harness that feeds a draft postmortem and a verified incident timeline to a model. The model's job is not to rewrite the postmortem but to produce a structured critique that identifies gaps in contributing factors, weak or cosmetic action items, and instances of hindsight bias. The output is a machine-readable critique that can be reviewed by a human before the postmortem is finalized.

textCopy
You are an incident analysis reviewer. Your task is to critique a draft postmortem for completeness, causal depth, and actionability. You do not rewrite the postmortem. You produce a structured analysis that a human reviewer will use to improve the document.

## INPUTS

[DRAFT_POSTMORTEM]

[VERIFIED_TIMELINE]

[SEVERITY_LEVEL]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

## INSTRUCTIONS

1. Parse the [DRAFT_POSTMORTEM] and the [VERIFIED_TIMELINE]. The timeline is the ground truth for event sequencing and durations.
2. Identify every contributing factor mentioned in the draft. For each factor, check whether the timeline supports, contradicts, or is silent about it. Flag contradictions.
3. Identify contributing factors present in the timeline but absent from the draft. These are missing factors.
4. For each action item in the draft, classify it as:
   - **Specific and Preventative**: directly addresses a contributing factor with a concrete owner and completion criterion.
   - **Vague or Cosmetic**: uses language like "investigate," "monitor," or "improve" without a measurable outcome.
   - **Missing**: a contributing factor has no corresponding action item.
5. Scan the draft for hindsight bias markers: language that assumes the incident was obviously preventable given information that was only available after the fact. Flag each instance with the sentence and an explanation.
6. Check whether the draft distinguishes between contributing factors that were known at the time of the incident and those discovered during the investigation. Flag conflation.
7. Assess whether the severity classification in [SEVERITY_LEVEL] is consistent with the impact described in the draft and timeline. Flag discrepancies.
8. Produce your output strictly according to [OUTPUT_SCHEMA].
9. Adhere to all [CONSTRAINTS].

## OUTPUT

Return only valid JSON conforming to [OUTPUT_SCHEMA]. Do not include commentary outside the JSON structure.

To adapt this template, replace each square-bracket placeholder with the concrete values for your incident review workflow. [DRAFT_POSTMORTEM] should contain the full text of the draft. [VERIFIED_TIMELINE] must be a chronologically ordered list of events with timestamps, derived from monitoring data, chat logs, and deployment records—not from the draft itself. [SEVERITY_LEVEL] should map to your organization's severity definitions (e.g., SEV1, SEV2). [OUTPUT_SCHEMA] must be a strict JSON schema defining the expected structure of the critique, including arrays for missing factors, action item classifications, and hindsight bias flags. [CONSTRAINTS] should specify any domain-specific rules, such as required sections, prohibited language, or compliance requirements.

Before integrating this prompt into a production pipeline, validate it against at least five historical postmortems where you know the ground truth. Compare the critique output against what a skilled human reviewer would flag. Measure precision (flagged items that are genuine issues) and recall (genuine issues the prompt missed). If recall is low, add explicit examples of subtle failure patterns to [CONSTRAINTS] or include few-shot examples in the prompt. If precision is low, tighten the classification definitions. Always route the critique to a human reviewer before the postmortem is finalized—this prompt is an accelerator, not a replacement for engineering judgment in incident analysis.

The reflection prompt is not a standalone generator—it is a critique step that sits between an initial draft and a final human review. Wire it into your postmortem pipeline as a second-pass analysis: the system first generates a draft postmortem from incident data, then passes that draft to the reflection prompt for structured self-critique. The output is a list of identified gaps, weak action items, and hindsight-bias flags that the original draft missed. This critique should be surfaced alongside the draft, not used to auto-rewrite it without human oversight. The reflection step adds the most value when the initial draft was produced by the same model or a less-capable model, because it catches the model's own blind spots before a human reviewer spends time on them.

Build the harness with three explicit stages: draft generation, reflection critique, and human review merge. In the reflection stage, pass the full draft text as [DRAFT] and the incident timeline as [TIMELINE]. Use a structured output schema that enforces the critique fields: missing_contributing_factors (array of strings), weak_action_items (array of objects with action_item and weakness fields), hindsight_bias_flags (array of objects with statement and bias_type fields), and causal_gaps (array of objects with claimed_cause, missing_evidence, and suggested_investigation fields). Validate the output against this schema before surfacing it. If the model returns malformed JSON or omits required fields, retry once with a stricter format instruction appended to the prompt. After two failures, flag the draft for full human review and log the failure for prompt debugging.

For model choice, use a model with strong reasoning capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent—because the reflection task requires detecting subtle logical gaps and counterfactual reasoning. Set temperature to 0.2 or lower to reduce variance in critique quality across runs. If your incident volume is high, consider batching drafts through the reflection step asynchronously and surfacing critiques in your postmortem tool as inline annotations rather than separate documents. Always log the full prompt, draft, and critique output for auditability. The reflection output should never auto-close a postmortem; it should feed into a human review queue where an incident analyst accepts, rejects, or modifies each critique finding. This keeps the human accountable for the final postmortem while using the model to reduce the cognitive load of catching their own oversights.