postmortem

# Lessons Learned: Structured Retrospective Analyse incidents using a structured framework, identify root causes, and encode preventive measures directly into skills, guards, or documentation. The goal is systematic improvement, not blame. ## When to Use - After incidents, mistakes, rollbacks, or near-misses - When the user says "what went wrong", "lessons learned", "post-mortem", "retrospective", or "how do we prevent this" - After a stuck session where significant time was lost - After a wrong-approach event (plan existed but execution diverged) ## Process ### Phase 1: Incident Definition Capture the facts first, analysis later. ```markdown ## Incident Summary **What happened:** [Factual description] **When:** [Date/time] **Impact:** [What was affected, scope] **Resolution:** [How it was fixed/rolled back] **Time to resolution:** [How long to fix] ``` ### Phase 2: Timeline Reconstruction Build a chronological sequence of events: | Time | Action | Actor | Outcome | |------|--------|-------|---------| | HH:MM | [What was done] | [Claude/User] | [Result] | Key questions: - What was the trigger? - Where did the sequence diverge from expected? - What was the point of no return? ### Phase 3: Root Cause Analysis (5 Whys) ``` 1. Why did [incident] happen? → Because [immediate cause] 2. Why did [immediate cause] happen? → Because [deeper cause] 3. Why did [deeper cause] happen? → Because [systemic issue] 4. Why did [systemic issue] exist? → Because [proc...