← ClaudeAtlas

postmortem-fixlisted

Turn an escaped defect or production incident into a concrete prevention patch plan (root cause + control gap + multi-layer fix). Declaring an incident is intentional; only invoke explicitly when the operator says this is post-incident or postmortem work.
prilive-com/go-tdd-pack · ★ 0 · Code & Development · score 76
Install: claude install-skill prilive-com/go-tdd-pack
# Postmortem Fix Given a defect that made it to production, or a test/review escape, turn the incident into prevention — not just a fix. ## Step 1: State the user-visible failure One sentence. What did the user, operator, or downstream system see? Do not describe the internal bug yet. Describe the observation. ## Step 2: State the true root cause The root cause is the earliest decision or assumption that made the failure possible, not the last line that misbehaved. Ask "why" until you reach something actionable. - **Symptom**: what broke - **Proximate cause**: which line of code was wrong - **Root cause**: what allowed the wrong line to ship Example: - Symptom: Orders weren't being placed after 2am UTC. - Proximate cause: Cron job's timezone was local, not UTC. - Root cause: No convention or lint rule requires explicit timezones in scheduled-job config. ## Step 3: Identify what control failed Not all bugs are bugs-in-code. Most escaped defects reveal a process gap: - **Missing invariant**: the code didn't encode an assumption it relies on - **Missing test**: the failure scenario had no test that would catch it - **Missing review discipline**: the reviewer missed what reviewers are expected to catch - **Missing hook/gate**: CI or pre-commit didn't reject the bad pattern - **Missing policy**: the team has no convention for handling this class of change - **Architecture boundary leak**: code in module A depended on an internal detail of module B Name speci