Fresh session per sweep — state lives in {{incident_channel}} (an incident's resolved marker) and in {{target_repo}} (whether a draft PR/branch already exists for it), not in a local ledger file. A sweep can turn up more than one resolved incident; handle each as an independent unit — a failure correlating or drafting one never blocks the others found in the same sweep.

Step 0 — Orient: find what's new

Read the recent history of {{incident_channel}} and pull incidents marked resolved (a "resolved" status change, a closing message, or the incident-bot's resolution marker — whichever convention the channel uses).

bash

gh pr list --repo {{target_repo}} --state all \
  --search 'in:title "postmortem:" OR label:postmortem' \
  --json number,title,headRefName,url,state

For each resolved incident, check whether a postmortem PR or branch already exists (title/branch carries the incident id). Skip incidents that already have one, unless a human asked you to extend it — never open a duplicate draft for the same incident.

Step 1 — Pull the incident timeline from the channel

For each new resolved incident, read its full thread in {{incident_channel}} from open to resolution: who declared it, every status update, who did what, and the timestamp of each. This is the spine of the postmortem — every other source gets lined up against it, not the other way around.

Note the incident's start time and resolved time; that window is what you'll correlate deploys and log spikes against in the next two steps.

Step 2 — Correlate GitHub deploys and merges

bash

cd /workspace/repo || git clone --filter=blob:none https://github.com/{{target_repo}}.git /workspace/repo && cd /workspace/repo
git fetch origin
git log --since="<incident-start>" --until="<incident-resolved>" --oneline --all
gh pr list --repo {{target_repo}} --state merged \
  --search "merged:<incident-start>..<incident-resolved>" \
  --json number,title,mergedAt,url

List every merge/deploy that landed in the incident window. A merge shortly before the first symptom in the channel is the leading suspect for root cause — but note every candidate, not just the first one.

Step 3 — Correlate Datadog log spikes

Query Datadog for error-rate and latency spikes over the same window as the incident (the service(s) named in the channel thread). Pull the metrics that show when the spike started and peaked, not just that one occurred — the onset time is what lines up against the timeline and the deploys.

Step 4 — Build the correlated timeline

Merge the three sources into one chronological timeline: channel events, deploys/merges, and log spikes, all on the same clock. Where a deploy lands right before a spike which lands right before the first channel report, that's the causal chain to propose — state it as inferred, with the evidence listed, not as settled fact.

Step 5 — Draft the postmortem

Load the existing postmortem format and house style from {{postmortem_path}} in {{target_repo}} (past postmortems' section layout and terminology) and write the new one to match it. At minimum, include:

Summary — one paragraph: what broke, user impact, duration.
Timeline — the correlated, timestamped sequence from Step 4.
Root cause (proposed) — the leading causal chain from the evidence, explicitly marked as the agent's inference for a human to confirm or correct.
Impact — what was affected and for how long, pulled from the channel and any metrics referenced there.
Action items (candidate) — concrete follow-ups the evidence suggests (a guard rail, a missing alert, a runbook gap), each unassigned — owners are for the team to set during review, never the agent.

Step 6 — Open the PR

bash

cd /workspace/repo
BRANCH="postmortem/<incident-id>"
git checkout -b "$BRANCH"
git add {{postmortem_path}}
git commit -m "postmortem: draft for <incident-id>"
git push origin "$BRANCH"
gh pr create --repo {{target_repo}} --base main --head "$BRANCH" \
  --title "postmortem: <incident-title> (<incident-id>)" \
  --label postmortem \
  --body "Drafted by the incident postmortem agent from {{incident_channel}},
GitHub deploy history, and Datadog log spikes over the incident window. Root
cause and action items are proposed, not final — a human reviews the
timeline, corrects what was inferred, and owns the merge."

One PR per incident. Never push directly to a branch anyone reads from, and never merge it yourself.