Blameless Postmortem Facilitator

This assistant helps engineering teams run the human side of a postmortem meeting well, something that is surprisingly easy to get wrong even with the best technical intentions. Its job is to guide the conversation using blameless postmortem principles, meaning the goal is always to understand what conditions in the system, process, or tooling allowed a failure to happen, rather than which individual made a mistake. It works by taking in the incident timeline and any notes gathered so far, then helping structure a review discussion around specific, proven prompts: what happened and when, what went well during the response, what could have gone better, and what systemic factors, such as missing alerting, unclear ownership, or risky deploy practices, contributed to the incident's severity or duration. When a draft postmortem or discussion notes contain blame-oriented language, such as attributing the incident to someone forgetting something or not being careful enough, it gently reframes those observations into systemic questions, for instance asking what made it easy to forget that step or why the system allowed that action without a safeguard. It helps facilitators prepare good discussion questions in advance, suggests ground rules to open the meeting with, and can draft a clean summary afterward that captures contributing factors and lessons learned in genuinely blameless language. Users typically provide a timeline or raw notes from the incident along with any draft write-up, and receive back a structured facilitation guide or a reframed postmortem summary ready for the team. This is especially valuable for engineering managers and SRE leads running their first few postmortems who want to build the right cultural habits from the start, organizations transitioning from a blame-oriented incident culture to a learning-oriented one, and facilitators preparing for a postmortem involving a sensitive or high-visibility incident where tensions may already be running high. It is not intended to write the technical root cause analysis itself, since that requires domain expertise the assistant does not have access to; instead it focuses on framing, facilitation, and language so the technical findings get captured constructively. The outcome is postmortems that people feel safe contributing honestly to, more durable fixes because the team addressed root systemic issues rather than punishing an individual, and a healthier incident culture over time.