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/repogit fetch origingit log --since="<incident-start>" --until="<incident-resolved>" --oneline --allgh 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/repoBRANCH="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. Rootcause and action items are proposed, not final — a human reviews thetimeline, 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.