Postmortem Findings to Engineering Tickets Prompt
Convert postmortem findings into well-scoped engineering tickets — each with a clear title, candidate owner role, acceptance criteria, defense type, and a realistic due date — so the lessons turn into tracked work instead of a buried action-items list.
- Target user
- SRE / eng manager turning postmortem findings into tracked work
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a staff SRE who has watched too many postmortem action items die as a paragraph no one ever opened. You turn findings into tickets a team can actually pick up, scope, and close. I will paste the findings or action-items section: [POSTMORTEM FINDINGS / ACTION ITEMS] [TEAM CONTEXT: which teams/roles exist, rough capacity, and any sprint cadence] For each finding, produce a ticket draft: 1. Title: a concrete, outcome-focused title (the change, not the symptom). Avoid "investigate" titles unless investigation genuinely is the unit of work. 2. Problem statement: 2-3 sentences linking the ticket to the incident and the contributing factor it addresses. 3. Acceptance criteria: a testable list — "done" is observable, not "improve X." Include how someone would verify it. 4. Owner role: the role best placed to own it (not a named person). Flag where ownership is genuinely unclear as [NEEDS OWNER DECISION]. 5. Defense type: prevent / detect / mitigate — what layer this adds. 6. Effort and due date: a rough size and a realistic target, framed as a proposal. Split anything too large to fit one sprint into smaller tickets. Also: flag findings that should NOT become a ticket (already covered, or so vague they need refinement first) and say why. Output format: one ticket block per finding using the fields above, then a short list of findings parked for refinement. Guardrails: do not invent scope or commit owners — owner, effort, and dates are proposals for humans to confirm. Keep language blameless; tickets describe system changes, not corrective action against people. Mark any assumption about team capacity or feasibility as [UNVERIFIED]. The owning teams confirm acceptance, effort, and dates.
Why this prompt works
The graveyard of postmortems is the action-items list: a wall of well-meaning bullets that lives in a wiki page no one revisits. The reason is almost never bad intent — it is that the findings were never scoped into work a team could actually pick up. “Improve our alerting” is not a ticket; it is a wish. Turning each finding into a titled, owned, acceptance-criteria’d unit of work is the difference between a postmortem that changes the system and one that documents it.
This prompt enforces the fields that make a ticket pick-up-able: an outcome-focused title, a problem statement that ties back to the contributing factor, and testable acceptance criteria where “done” is observable rather than aspirational. It also tags each ticket with its defense type — prevent, detect, or mitigate — which lets a team see whether the remediation set is balanced or stacked entirely on prevention with no improved detection.
The guardrails keep it honest. The model proposes owners, effort, and dates, but it does not commit anyone — those belong to the owning team, and committing them on paper is exactly how action items earn their reputation for being ignored. Findings too vague to scope are parked for refinement rather than forced into fake tickets, and every ticket is framed as a system change, never a corrective action against a person, preserving the blameless contract.