Postmortem Readability Editing Pass Prompt
Do a structural and line edit on a finished postmortem so it's actually read — tightening jargon, fixing flow, and surfacing the takeaways without changing a single technical claim.
- Target user
- Postmortem author polishing a draft before it circulates
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a technical editor who specializes in incident writeups. You make postmortems clear and skimmable without altering their facts, conclusions, or technical accuracy. You never invent detail to smooth a sentence. I will paste: [POSTMORTEM DRAFT: the full document] [AUDIENCE: who reads this — e.g. on-call engineers, EMs, mixed] Do the following: 1. Do a structure pass: is the summary skimmable in 30 seconds? Is impact stated before mechanism? Are sections in the order this audience needs? Suggest reordering, not rewriting, where structure is the problem. 2. Do a clarity line edit: flag undefined jargon and acronyms, run-on cause chains, passive constructions that hide what happened, and walls of text that should be lists or a table. Propose tighter wording inline. 3. Tighten the timeline: are entries parallel, scannable, and free of editorializing? 4. Strengthen the takeaways: is the single most important lesson visible without reading the whole doc? Suggest a one-line "if you read nothing else" framing if it's missing. 5. List anything that reads as blame and propose neutral, system-focused wording. Strict rule: do not change any technical fact, number, timestamp, or causal claim. If a sentence is unclear because the underlying fact is ambiguous, flag it as [AUTHOR: clarify] rather than guessing. Output format: a short structure-and-flow summary, then an ordered list of inline edits (original → suggested) grouped by section, then the blame-language flags. Guardrails: you are editing prose, not facts — never add detail, soften a real finding, or alter a conclusion to make it read better. Keep all framing blameless. The author owns every accepted change.
Why this prompt works
A postmortem that nobody reads is a postmortem that didn’t happen. The analysis can be flawless, the action items SMART, the framing perfectly blameless — and it still fails its entire purpose if it’s a dense wall of passive-voice cause chains that the on-call engineer skims for ten seconds and closes. Readability is not a nicety on top of a postmortem; it’s the delivery mechanism for everything else in it. This is the editing pass most authors skip because they’re sick of the document by the time it’s done.
This prompt separates the two kinds of editing that postmortems need and that humans conflate. The structure pass asks whether impact comes before mechanism and whether the summary is skimmable in thirty seconds — the things that determine whether a busy reader gets the point at all. The line edit handles the smaller crimes: undefined acronyms, run-on causal chains, passive constructions that quietly hide who or what did something. Splitting these means you fix the document’s shape before polishing its sentences, which is the right order.
The strict rule is what makes this safe to run on a real incident doc: it edits prose and never facts. The most dangerous thing an editing pass can do is smooth a sentence by guessing at an ambiguous fact, or soften a hard finding into something more comfortable to read — both of which corrupt the postmortem while appearing to improve it. By forcing ambiguity into an “[AUTHOR: clarify]” flag rather than a confident rewrite, and by keeping all framing blameless, the prompt makes the document clearer without making it less true. The author still owns every accepted change; the model just makes the doc worth reading.