IT incident post-mortem
Reconstructs an IT service incident and produces a blameless post-mortem with impact, contributing factors, corrective actions, and customer-facing facts. Use for outages, security-adjacent service failures, major incidents, and recurring support escalations.
Published Aug 21, 2026 · Updated Aug 26, 2026
Requirements
Add the incident taxonomy, severity policy, and post-mortem template. Define impact metrics, service-level terms, and time-zone conventions. Specify action ownership and follow-up review cadence. Set rules for security, privacy, and customer-facing content.
Skill document
The full SKILL.md your agent reads and follows.
IT incident post-mortem
Purpose
Turn fragmented incident evidence into a reliable account of what happened, why controls failed, and what will reduce recurrence.
Scope
Operational incidents affecting availability, performance, data handling, support, or service commitments. Excluded: live remediation, blame assignment, and legal or regulatory reporting decisions.
Data basis
- Incident timeline, logs or alerts, ticket history, communication record, service agreement, change history, and similar incidents.
- The fixed records, tables, or folders in the skill scope that hold the relevant history or schema.
Result
A post-mortem document, action register, and factual customer-summary draft.
Quality criteria
- The timeline cites the source for each material event.
- Impact quantifies affected services, users, duration, and commitments where data exists.
- Trigger, contributing factors, detection gap, and root cause are separated.
- Actions have a measurable completion criterion and owner or missing owner.
- The customer summary contains no internal speculation or blame.
Instructions
Resolve timestamps to one stated time basis and flag conflicting times. Distinguish evidence from interpretation and avoid using a proximate trigger as the whole cause. Compare the incident with prior cases to identify systemic patterns. Include what worked as well as what failed. Keep security-sensitive details out of the customer version unless explicitly approved in scope.
Adapt before use
Keep the source trail close to every conclusion and preserve the difference between a source fact, a calculated value, an assumption, and a recommendation. Use stable identifiers across the document and sheet so a reviewer can move from a summary statement to the underlying row and source. Prefer a complete, transparent partial result over a confident answer built on missing evidence.
- Add the incident taxonomy, severity policy, and post-mortem template.
- Define impact metrics, service-level terms, and time-zone conventions.
- Specify action ownership and follow-up review cadence.
- Set rules for security, privacy, and customer-facing content.
Related skills
- Access provisioning checklist
Converts employee roles and lifecycle events into a system-by-system provisioning or deprovisioning checklist with approvals, dependencies, and audit evidence fields. Use for joiner, mover, leaver, role-change, access-request, and identity-control preparation.
- Audit evidence pack
Organizes audit requests into evidence tests, evaluates supplied documents for coverage and period, and produces a traceable evidence tracker with control narratives and gaps. Use for SOC, ISO, internal control, customer audit, certification, and audit-readiness preparation.
- Backup and recovery verification
Checks backup coverage, retention, failures, and recovery-test evidence against system criticality and recovery objectives, then produces a verification report and remediation list. Use for backup audits, disaster-recovery readiness, RTO/RPO reviews, resilience checks, and recurring IT control evidence.
- Change release record
Turns a proposed production change into a structured risk, test, approval, rollback, and verification record with traceable evidence. Use for change management, release readiness, deployment review, CAB preparation, rollback planning, and audit documentation.