Every engineering team has the same post-incident ritual. The incident happens. Someone writes up a quick summary in Slack. Someone else promises to update the runbook. A post-mortem gets scheduled. Two weeks later, the runbook still hasn’t been updated, the post-mortem doc is half-finished, and the next time the same incident happens, the on-call engineer is back to figuring it out from scratch.
The problem isn’t laziness. It’s that writing documentation after a stressful incident is the last thing anyone wants to do, and it competes with the next sprint’s feature work. The documentation debt compounds until the runbooks are so stale that nobody trusts them.
The Incident Response workflow
The Engineering starter pack includes a workflow called Incident Response. It takes the raw incident data — timeline, symptoms, actions taken, root cause — and produces three outputs in one pass.
-
Incident Report — A structured post-incident report with: incident summary, timeline of events, impact assessment (users affected, duration, severity), root cause analysis, contributing factors, and immediate actions taken. The format is consistent across incidents, which makes pattern recognition possible across months of reports.
-
Runbook Update — The AI takes the incident details and generates additions or updates to the relevant runbook. If the incident revealed a new failure mode, it writes detection steps, diagnostic commands, and remediation procedures. If it’s a known failure mode with a new wrinkle, it updates the existing section. The output is structured as runbook-ready content, not a narrative summary.
-
Engineering Lead Review (Approval Gate) — Before publishing anything, the workflow pauses for review. The eng lead verifies the timeline accuracy, validates the root cause analysis, and approves the runbook additions. This gate is critical — AI-generated runbooks need a human who was there to confirm the procedures are correct.
-
Post-Mortem Generation — After approval, the AI generates a full post-mortem document: what happened, why it happened, what prevented faster resolution, and action items to prevent recurrence. Each action item has a suggested owner and priority.
Why consistency matters for incident docs
When incident reports follow different formats, you can’t compare them. You can’t ask “how many P1 incidents this quarter were caused by database issues?” unless every report uses the same severity scale and categorization. You can’t track whether remediation times are improving unless every report includes the same timing fields.
The Incident Report recipe enforces a consistent schema. Every report has the same sections, the same severity categories, the same timing fields. Over time, this becomes a structured dataset you can query, not just a folder of documents.
What the engineer still does
The workflow needs accurate input. The engineer provides:
- What happened — Timeline of events, symptoms observed, alerts fired
- What they did — Diagnostic steps taken, commands run, fixes applied
- What caused it — Root cause and contributing factors
The AI doesn’t investigate the incident — it documents it. The investigation, the debugging, the fix — that’s the engineer’s expertise. The AI’s job is to turn that expertise into well-structured documentation that the next on-call engineer can actually use.
Runbook updates are particularly valuable here. An engineer who just spent two hours debugging a production issue knows exactly what steps to follow next time. Normally that knowledge stays in their head or in a Slack thread. The workflow captures it in a runbook section with specific commands and decision points.
The Feature Launch workflow
The Engineering pack also includes a Feature Launch workflow that handles the other documentation gap: release communications.
- Write changelog entries from commit history and PR descriptions
- Generate user-facing release notes with the right level of detail
- Update API documentation if endpoints changed
- Package everything for review
And the Sprint Cycle workflow automates planning and retrospective documentation: generate sprint goals from backlog items, create documentation plans for new features, and structure retrospective notes into actionable improvements.
The full Engineering pack
The Engineering starter pack includes two additional workflows alongside Incident Response:
- Feature Launch — Release notes, changelog, and documentation updates in one pass
- Sprint Cycle — Planning, documentation, and retrospective automation
The standalone recipes — tech spec writer, API documentation generator, code review feedback, architecture decision records — work individually or as building blocks for custom engineering workflows.