🎫 From Postmortem to Well-Scoped Engineering Tickets With AI

I once audited a year of postmortem action items for a team that swore they “always followed up.” Of forty-seven items, nine had been done. The other thirty-eight were sitting in a doc as bullet points like “improve monitoring” and “add better validation.” Not one of them was a ticket. Not one had an owner, an acceptance criterion, or a place in anyone’s backlog. They weren’t ignored out of malice—they were ignored because “improve monitoring” is not a thing a human can pick up on a Tuesday and finish by Friday. It’s a wish, and wishes don’t ship.

The gap between a postmortem and an actual fix is the gap between a bullet point and a well-scoped ticket. Crossing it is tedious: you have to translate each finding into a discrete, ownable, testable unit of work with enough context that a stranger could pick it up. That translation is exactly what AI is good at, and exactly what tired engineers skip at the end of an incident.

What makes an action item a real ticket

A bullet point becomes a ticket when it survives five questions. “Improve monitoring” answers none of them; a real ticket answers all.

What, specifically? “Add a burn-rate alert on the checkout API SLO” — not “improve monitoring.”

Why—what’s the link to the incident? The ticket should reference the postmortem and the exact gap it closes, so it doesn’t get deprioritized by someone who’s forgotten the context.

Who owns it? A team at minimum, ideally a person. An unowned ticket is a deferred ticket.

When is it done—acceptance criteria? “Alert fires within 90 seconds when budget burn exceeds 2%/min, verified by a game-day injection.” Testable, not aspirational.

How big? A rough size, so it can actually be slotted into a sprint instead of looming as an undefined boulder.

The art is also in splitting. “Fix the failover” is three tickets: detection, the automation fix, and a runbook update. A finding that maps to one giant ticket never gets started; the same finding split into three S-sized tickets gets two of them done this sprint.

A prompt that converts findings into tickets

I feed the model the action-items and counterfactual sections of the finished postmortem and have it draft tickets in the format my tracker wants. The constraint that matters: it must split fat findings and it must not invent acceptance criteria it can’t ground in the incident.

Convert these postmortem action items into well-scoped engineering
tickets. For each item:

- TITLE: imperative, specific, <80 chars
- CONTEXT: 1-2 sentences linking to the incident and the exact gap
  it closes. Reference the postmortem.
- ACCEPTANCE CRITERIA: bullet list, testable, observable. Each must
  be something you could verify. If you can't derive a real criterion
  from the input, write "NEEDS OWNER INPUT: <question>".
- SIZE: S / M / L (rough)
- SUGGESTED OWNER TEAM: based on the system named in the finding
- PRIORITY HINT: tie to the impact/recurrence risk described

SPLIT any finding that bundles detection + fix + docs into separate
tickets. Do NOT invent acceptance criteria. Output one block per
ticket, ready to paste into Jira/GitHub.

Action items:
<paste the action items and counterfactual section>

NEEDS OWNER INPUT is the honesty valve again. If the postmortem says “make failover safer” without saying what safe looks like, the model shouldn’t fabricate a threshold—it should ask. A ticket with a made-up acceptance criterion is worse than one that admits it needs a number, because someone will build to the wrong target.

A ticket the model drafts, you approve

Title: Add burn-rate alert on checkout API SLO (2%/min)

Context: During INC-2291, the checkout outage went undetected for 37 minutes because alerting was threshold-based, not budget-based. This closes the detection gap identified in the postmortem’s counterfactual analysis.

Acceptance criteria:

• Alert fires within 90s when error-budget burn exceeds 2%/min over a 5-min window
• Routes to the checkout on-call rotation in PagerDuty
• Verified by injecting a controlled error burst in a game day
• Runbook link attached to the alert

Size: S Owner team: Checkout Priority: High (recurrence risk; 20% of monthly budget burned last time)

---

Title: Make payments failover verify promotion before reporting success

Context: INC-2291 contributing factor: failover reported success on initiation, not completion, hiding a stalled promotion.

Acceptance criteria:

• Failover routine polls promotion status and fails loudly if not promoted within 60s
• NEEDS OWNER INPUT: should it auto-roll-back or just alert?

Size: M Owner team: Data Priority: High

That single “make failover safer” finding became two tickets, one of them S-sized and shippable this sprint, the other honestly flagging the one design decision a human has to make. That’s the difference between an action list and a fixed system.

Keep the human as the editor and the assigner

The model drafts; it does not assign and it does not decide priority for real. Two judgments stay with people. First, ownership—the model can guess a team from the system name, but only a lead knows who has capacity and context, and an unowned ticket is a dead ticket. Second, the cut line—a postmortem might generate twelve tickets and the honest answer is you’ll do four this quarter. Picking which four is prioritization work the AI can inform but not own. The fastest way to make postmortem follow-through collapse is to flood the backlog with twelve auto-generated tickets nobody triages; do four well-scoped ones that actually close.

The loop only counts if the tickets ship. Drafting them fast and well removes the excuse that “we didn’t have time to write them up,” which is the excuse that kills most postmortem follow-through. The AI buys you that time; the discipline of assigning, sizing, and closing is still yours.

This ticket-conversion prompt lives with the rest of my incident snippets in the prompts library, and the follow-through theme runs through the postmortems category. For where these action items come from in the first place, see the blameless postmortem guide.

Turn the bullet into a ticket with an owner and an acceptance criterion. That’s the only part of the postmortem that changes anything.