/nw-post-mortem-framework
Blameless post-mortem structure, incident timeline reconstruction, response evaluation, and organizational learning
$ npx -y skills add nWave-ai/nWave --skill nw-post-mortem-framework --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/nw-post-mortem-framework
Context preview
The summary Claude sees to decide when to auto-load this skill.
Blameless post-mortem structure, incident timeline reconstruction, response evaluation, and organizational learning
SKILL.md
nw-post-mortem-framework.SKILL.mdname: nw-post-mortem-framework
description: Blameless post-mortem structure, incident timeline reconstruction, response evaluation, and organizational learning
user-invocable: false
disable-model-invocation: true
Post-Mortem Framework
Principles
- **Blameless**: focus on systems/processes, not individuals. People make reasonable decisions given available info.
- **Evidence-based**: every finding backed by logs, metrics, or documented actions
- **Action-oriented**: every finding produces concrete, assigned action item
- **Learning-focused**: capture what worked alongside what failed
Post-Mortem Document Structure
# Post-Mortem: [Incident Title]
**Date**: [incident date]
**Duration**: [start to resolution]
**Severity**: [P0-P3]
**Author**: [analyst]
## Summary
[2-3 sentence overview: what happened, impact, resolution]
## Timeline
| Time | Event | Source |
|------|-------|--------|
| HH:MM | [event] | [log/metric/report] |
## Impact
- Users affected: [number/percentage]
- Duration of impact: [time]
- Business impact: [quantified if possible]
- Systems affected: [list]
## Root Cause Analysis
[5 Whys analysis with evidence at each level]
## Detection and Response
- Time to detect: [duration] -- [how detected]
- Time to respond: [duration] -- [first action]
- Time to mitigate: [duration] -- [mitigation applied]
- Time to resolve: [duration] -- [permanent fix]
## What Went Well
- [positive observations about detection, response, recovery]
## What Could Be Improved
- [areas where detection, response, recovery fell short]
## Action Items
| ID | Action | Owner | Priority | Due Date |
|----|--------|-------|----------|----------|
| 1 | [specific action] | [team/person] | [P0-P3] | [date] |
## Lessons Learned
- [key takeaways for the organization]
Incident Timeline Reconstruction
Sources
1. Monitoring alerts/dashboards (timestamps) | 2. Deployment logs/CI-CD records 3. Communication channels (Slack, email, incident) | 4. VCS (commits, merges, deploys) | 5. User reports/support tickets
Quality Checks
Events chronological with verified timestamps | gaps >5 min noted/explained | decision points identified with available info | causal relationships noted
Response Effectiveness Evaluation
Detection
Detected by monitoring or users? | Duration onset-to-detection? | Existing alerts relevant? Missing?
Escalation
Right team at right time? | Procedures followed? | Communication clear to stakeholders?
Resolution
Mitigation effective? | Rollback considered/viable? | Duration mitigation-to-permanent-fix?
Organizational Learning
Knowledge Capture
Document root causes as reusable patterns | update runbooks | share in retrospectives
Process Improvements
Update monitoring/alerting per detection gaps | revise deployment per rollback effectiveness | strengthen testing for failure scenario
Action Item Tracking
Every item has owner + due date | track in standups/sprint reviews | verify effectiveness post-deployment
Read more
name: nw-post-mortem-framework description: Blameless post-mortem structure, incident timeline reconstruction, response evaluation, and organizational learning user-invocable: false disable-model-invocation: true
Post-Mortem Framework
Principles
- **Blameless**: focus on systems/processes, not individuals. People make reasonable decisions given available info.
- **Evidence-based**: every finding backed by logs, metrics, or documented actions
- **Action-oriented**: every finding produces concrete, assigned action item
- **Learning-focused**: capture what worked alongside what failed
Post-Mortem Document Structure
# Post-Mortem: [Incident Title] **Date**: [incident date] **Duration**: [start to resolution] **Severity**: [P0-P3] **Author**: [analyst] ## Summary [2-3 sentence overview: what happened, impact, resolution] ## Timeline | Time | Event | Source | |------|-------|--------| | HH:MM | [event] | [log/metric/report] | ## Impact - Users affected: [number/percentage] - Duration of impact: [time] - Business impact: [quantified if possible] - Systems affected: [list] ## Root Cause Analysis [5 Whys analysis with evidence at each level] ## Detection and Response - Time to detect: [duration] -- [how detected] - Time to respond: [duration] -- [first action] - Time to mitigate: [duration] -- [mitigation applied] - Time to resolve: [duration] -- [permanent fix] ## What Went Well - [positive observations about detection, response, recovery] ## What Could Be Improved - [areas where detection, response, recovery fell short] ## Action Items | ID | Action | Owner | Priority | Due Date | |----|--------|-------|----------|----------| | 1 | [specific action] | [team/person] | [P0-P3] | [date] | ## Lessons Learned - [key takeaways for the organization]
Incident Timeline Reconstruction
Sources
1. Monitoring alerts/dashboards (timestamps) | 2. Deployment logs/CI-CD records 3. Communication channels (Slack, email, incident) | 4. VCS (commits, merges, deploys) | 5. User reports/support tickets
Quality Checks
Events chronological with verified timestamps | gaps >5 min noted/explained | decision points identified with available info | causal relationships noted
Response Effectiveness Evaluation
Detection
Detected by monitoring or users? | Duration onset-to-detection? | Existing alerts relevant? Missing?
Escalation
Right team at right time? | Procedures followed? | Communication clear to stakeholders?
Resolution
Mitigation effective? | Rollback considered/viable? | Duration mitigation-to-permanent-fix?
Organizational Learning
Knowledge Capture
Document root causes as reusable patterns | update runbooks | share in retrospectives
Process Improvements
Update monitoring/alerting per detection gaps | revise deployment per rollback effectiveness | strengthen testing for failure scenario
Action Item Tracking
Every item has owner + due date | track in standups/sprint reviews | verify effectiveness post-deployment
AI agents that guide you from idea to working code, with human judgment at every gate. nWave runs inside Claude Code. It breaks feature delivery into seven waves (discover, diverge, discuss, design, devops, distill, deliver).
Repo: nWave-ai/nWave
Other skills on nwave.
- /nw-ab-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Open skill - /nw-abr-critique-dimensions
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Open skill - /nw-ad-critique-dimensions
Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof
Open skill - /nw-agent-creation-workflow
Detailed 5-phase workflow for creating agents - from requirements analysis through validation and iterative refinement
Open skill - /nw-agent-testing
5-layer testing approach for agent validation including adversarial testing, security validation, and prompt injection resistance
Open skill - /nw-architectural-styles-tradeoffs
Architectural style selection decision matrices, trade-off analysis, structural enforcement rules, and combination patterns. Load when choosing or evaluating architecture styles.
Open skill

