✅ Rewriting Vague Postmortem Action Items Into Trackable Work With AI

Pull up any tracker that’s been collecting postmortem action items for a year and search for the phrase “improve monitoring.” You’ll find a graveyard. Half a dozen tickets, all open, all from different incidents, none of them ever started — not because the team is lazy but because nobody can tell when “improve monitoring” is done or whose job it is. A vague action item isn’t a task. It’s a feeling with a ticket number.

The analysis in a postmortem can be excellent and the whole thing still produces zero durable change, because the gap between “good postmortem” and “the next incident doesn’t recur” lives almost entirely in the specificity of the action items. This is tedious rewriting work, which is exactly why it gets skipped at the end of a long review and exactly where AI helps.

Why action items rot

An action item dies for one of four reasons, and they’re worth naming because the fix differs:

• No concrete deliverable. “Improve monitoring” doesn’t say what to build. Nobody can start.
• No done-state. “Make deploys safer” has no test for completion, so it’s never closeable.
• No owner. Assigned to a team in the abstract, which means assigned to nobody.
• No time horizon. “Eventually” is where good intentions go to die.

There’s a fifth, sneakier failure: the action item that’s really blame in disguise. “Be more careful during config changes” and “review migrations more thoroughly” look like tasks but are actually “the human should be better,” which is unactionable and also a blameless-culture violation. These should be deleted or converted into a real control.

The SMART rewrite, done by a model

SMART — Specific, Measurable, Assignable, Realistic, Time-bound — is an old framework, and it’s old because it works. The mechanical part of applying it to a list of action items is perfect for AI: it’s repetitive, it’s pattern-based, and it’s the part humans rush through.

Rewrite each postmortem action item into SMART form.

For each item:
1. Diagnose what's vague: missing deliverable, done-state, owner,
   or deadline?
2. Rewrite as: a specific deliverable + a measurable "done when X"
   test + a placeholder owner [OWNER: team/role — confirm] + a
   realistic window (this sprint / this quarter — NOT a date I
   didn't give you).
3. Classify: Prevent / Detect / Mitigate / Process.
4. Flag any item that's blame in disguise ("be more careful") and
   either rewrite as a system control or mark for deletion.
5. Flag duplicates to merge.

Rules: Do NOT invent owners, dates, or system names not in my
input — use [BRACKETS]. No rewrite may imply a person failed.

Draft items: <paste>
Context: <systems and what the incident exposed>

Two constraints in there are load-bearing. The “done when X” test is the single most valuable field, because it’s what makes a tracker able to close the thing. And the refusal to invent owners and dates matters more than it looks: a confidently fabricated assignment is worse than a blank, because it looks finished, gets filed, and then sits unowned while everyone assumes someone has it.

Before and after

Here’s the kind of transformation it produces, after a human fills in the real owners:

Original	SMART rewrite	Type	Done-when
Improve monitoring	Add a burn-rate alert on the checkout API SLO that pages at 2% budget/min	Detect	Alert exists in prod, tested via synthetic burn, routes to [OWNER]
Make deploys safer	Enable progressive rollout (10/50/100%) with auto-halt on error-rate regression for the payments service	Prevent	Next payments deploy uses staged rollout with auto-halt
Be more careful with config	(blame — deleted) → Add schema validation gate blocking invalid config in CI	Prevent	CI rejects a known-bad config in a test
Review migrations more	(blame — converted) → Add a CI linter blocking irreversible DDL without a reviewed rollback plan	Prevent	Linter blocks an un-reversible migration in a test PR

Notice the bottom two rows. Both started as “the human should be better” and both became actual controls that help anyone in that seat, which is the entire blameless principle expressed as engineering. The model proposed the rewrites; a human decided the config validator was worth building and assigned the real owner.

The balance check you didn’t ask for but need

Classifying each item as Prevent/Detect/Mitigate/Process produces a side benefit: it exposes imbalance. A list that’s all Prevent and no Detect is a tell. It means the review fixated on stopping this exact failure and never asked the more durable question — “if this class of thing happens again in a new form, how would we catch it sooner?” Prevention is brittle because it only blocks the failures you imagined. Detection is general. A healthy action-item list usually has at least one Detect item, and the classification makes its absence obvious.

What the human keeps

The model makes every line trackable; it does not get to own the list. Two judgments stay with a person. First, the real owners and real dates — the placeholders exist precisely so a human fills them with commitments people have actually agreed to, not assignments a model guessed. Second, pruning: the model will faithfully rewrite all fifteen items into beautiful SMART form, but a postmortem with fifteen action items is one that ships none of them, because the team can’t fund all fifteen. Pick the two or three with the best leverage, mark the rest as explicitly deferred, and close the loop on the ones you kept.

The action-item rewriter prompt lives in the prompts library, and it sits right next to the ticket-generation work for the step after — turning the kept items into well-scoped engineering tickets. For the broader closing-the-loop habit, that’s its own discipline worth building.

“Improve monitoring” will never ship. “Add a burn-rate alert at 2% budget/min, done when it pages a synthetic burn” ships this sprint. The difference is fifteen minutes of rewriting you can mostly hand to a model.