Repository-Based Incident Postmortems

An incident gets fixed, the PR is merged, and then the postmortem often never gets written. It takes time, and after the immediate problem is solved, it is easy for the write-up to fall to the bottom of the list. The Incident Postmortem Generator starts with what is already in the repository. Given a repo, the issue related to a bug, and the SHA of the fix, it works backwards to identify likely introducing commits using SZZ-lite signals such as git blame, pickaxe searches, and issue links. It then builds a timeline, analyzes the root cause, and proposes prevention actions. A key part of the project is knowing when the repository does not contain enough information. Claims are linked to the evidence that supports them, sections have confidence levels, and things such as user impact, detection time, or telemetry are marked "No evidence" when they cannot be established from the available data. The evaluation harness checks this instead of relying on the model to simply follow a prompt. The target users are engineering teams and maintainers who need an incident record but do not want to spend an hour reconstructing one manually. The tool can be used from the CLI or through the offline UI and produces a Markdown postmortem with evidence links, confidence badges, and an evaluation report. The demo uses real cases rather than synthetic examples: curl CVE-2023-38545, log4j CVE-2021-44228, and the GitLab 2017 database outage. The GitLab case is useful because it has no fix commit, so it exercises the "No evidence" path rather than forcing the system to invent one. On the curl case, the deterministic baseline found the actual introducing commit as the top candidate, with timeline precision of 1.00. Adding Bob agent-mode analysis increased action-item overlap from 0.00 to 0.22 while claim linkage remained at 1.00. My approach was to stop asking an LLM to write a convincing postmortem and instead hand it repository evidence, then make the evidence part of the output.