What each part of the prompt does
- Four marked moments
- Asking for start, detection, end of impact and confirmed fix makes the gaps visible. The distance between the problem starting and someone noticing is usually the most useful number in the whole review, and it is easy to lose in a long chat log.
- "Not measured" instead of a guess
- Models like to fill an impact section with plausible figures. Telling Claude to write "not measured" when the notes give no number keeps invented user counts out of a document that leadership may quote later.
- Confirmed versus suspected cause
- During an incident several theories get posted and only one survives. Two separate lists stop an early guess from being written up as the root cause just because it appeared in the notes first.
- Roles, not names
- Blameless reviews get honest input next time. Naming the on-call engineer or the database owner by role keeps the focus on the system and makes the follow-up table still readable after people change teams.
Variations to try
Same idea, one thing changed.
With a customer status update <role>You are writing a blameless post-incident review for [TEAM NAME].</role> <notes> [INCIDENT NOTES] </notes> <context> - Service or feature affected: [SERVICE] - Time zone to use for every timestamp: [TIME ZONE] - Who will read this: [AUDIENCE], which includes customers </context> <instructions> 1. Sort every event in the notes into one timeline. Convert all times to [TIME ZONE]. When a time is missing, write "time unknown" and place the event where the notes suggest. 2. Mark four moments in the timeline: when the problem started, when someone noticed, when the impact stopped, and when the fix was confirmed. 3. Write a summary of three or four sentences: what broke, who felt it, for how long, and what ended it. 4. Describe the impact using only what the notes show. If the notes give no figure for affected users or failed requests, write "not measured" instead of estimating. 5. Split the cause into two lists: confirmed (the notes show evidence) and suspected (a theory nobody has proven yet). 6. List what helped the response and what slowed it down. 7. Propose follow-up actions. Each one names a role as owner, a concrete change, and a way to tell it is done. </instructions> <format> Write the internal review first with the headings Summary, Timeline, Impact, Cause, What helped, What slowed us down, Follow-ups. Then add a customer status update under 150 words in plain language: what happened, when it was fixed and what changes next. Leave out internal system names in the customer update. </format> <rules> Name roles, never people. No blame words such as "careless" or "should have known". Do not invent timestamps, numbers or causes. Mark anything you are unsure of as "to confirm". </rules>
Quick first draft for the channel <role>You are writing a blameless post-incident review for [TEAM NAME].</role> <notes> [INCIDENT NOTES] </notes> <context> - Service or feature affected: [SERVICE] - Time zone to use for every timestamp: [TIME ZONE] - Who will read this: [AUDIENCE] </context> <instructions> 1. Sort every event in the notes into one timeline. Convert all times to [TIME ZONE]. When a time is missing, write "time unknown" and place the event where the notes suggest. 2. Mark four moments in the timeline: when the problem started, when someone noticed, when the impact stopped, and when the fix was confirmed. 3. Write a summary of three or four sentences: what broke, who felt it, for how long, and what ended it. 4. Describe the impact using only what the notes show. If the notes give no figure for affected users or failed requests, write "not measured" instead of estimating. 5. Split the cause into two lists: confirmed (the notes show evidence) and suspected (a theory nobody has proven yet). 6. List what helped the response and what slowed it down. 7. Propose follow-up actions. Each one names a role as owner, a concrete change, and a way to tell it is done. </instructions> <format> This is a first draft for the incident channel while the review meeting is still being planned. Give only the Summary, the Timeline table and a list of open questions the team must answer before the full review. </format> <rules> Name roles, never people. No blame words such as "careless" or "should have known". Do not invent timestamps, numbers or causes. Mark anything you are unsure of as "to confirm". </rules>
If the result isn't right
- Export the incident channel as plain text before pasting; screenshots lose the timestamps Claude needs to order events.
- If two sources disagree about a time, keep both in the notes. Claude will flag the conflict as something to confirm rather than picking one silently.
- Read the follow-ups table last and delete anything that cannot be finished in a few weeks; long-term wishes belong in a separate roadmap item.
- Run the prompt again after the review meeting with the meeting notes added, so the final version reflects what the team agreed.