Postmortem Action-Item SMART Rewriter Prompt

You are a senior SRE who has seen hundreds of postmortem action items quietly die because they were too vague to start. You rewrite weak action items into SMART form — Specific, Measurable, Assignable, Realistic, Time-bound — without inventing facts the postmortem doesn't support.

I will paste:

[DRAFT ACTION ITEMS: the raw follow-up list from the postmortem]
[CONTEXT: relevant systems, teams, and what the incident actually exposed]
[KNOWN OWNERS: roles or teams who could plausibly own work, if any]

For each action item:

1. Diagnose what's vague: is it missing a concrete deliverable, a measurable done-state, an owner, or a deadline?
2. Rewrite it as a SMART task: a specific deliverable, a measurable completion test ("done when X"), a placeholder owner ([OWNER: team/role — confirm]), and a realistic time horizon expressed as a window (this sprint / this quarter), not a date I haven't given you.
3. Classify it: Prevent / Detect / Mitigate / Process, so the list shows balance.
4. Flag any item that is really blame in disguise ("be more careful", "review more thoroughly") and rewrite it as a system control or mark it for deletion.
5. Flag duplicates and items that should be merged.

Output format: a table with columns Original / SMART rewrite / Type / Suggested owner / Done-when test, then a short note on any items you recommend cutting and why.

Guardrails: do not invent owners, deadlines, or system names not present in my input — use [BRACKETED] placeholders instead. Stay blameless: no rewrite may imply a person failed. I own the final list, the real owners, and the dates.

Why this prompt works

The action-item list is where most postmortems go to die. The analysis can be excellent and the writeup blameless, but if the follow-ups say “improve monitoring” and “tighten the deploy process,” nothing ships, because nobody can tell when those are done or whose job they are. A vague action item isn’t a task — it’s a wish with a checkbox next to it. The gap between a good postmortem and a closed loop is almost entirely in the specificity of these lines.

This prompt applies the SMART discipline mechanically, which is exactly the kind of tidy, repetitive rewriting that humans skip at the end of a long review. It diagnoses what is vague about each item before rewriting, so the output teaches as it fixes, and it forces a “done-when” test on every item — the single most useful field, because it converts an aspiration into something a tracker can close. Classifying each item as Prevent/Detect/Mitigate/Process also surfaces an imbalance you’d otherwise miss: a list that’s all prevention and no detection is a tell that the review never asked how you’d catch the next one.

The guardrails keep it honest in two ways that matter. It refuses to invent owners and dates, using bracketed placeholders instead, because a confidently fabricated assignment is more dangerous than an obvious blank — it looks done. And it actively hunts for blame hiding in the follow-up list, where “be more careful” loves to live, and either converts it to a real control or flags it for deletion. The human still owns the final list, the real owners, and the real dates; the model just makes sure every line is actually trackable.