Stats
Actions
Tags
From simpsons-development
Homer Simpson incident response protocol — 6-phase loop for chaos monkey, production resilience, failure recovery, and operator-proof hardening
How this skill is triggered — by the user, by Claude, or both
Slash command
/simpsons-development:homer-protocolThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> "D'oh!"
"D'oh!"
A production resilience protocol that asks: can your system survive having Homer at the controls? Homer works at a nuclear power plant. He sleeps on the job, presses buttons he shouldn't, ignores warnings, and makes bad decisions under pressure. Despite all of this, Springfield hasn't melted down (mostly). That's not because Homer is competent — it's because the safety systems are (barely) good enough.
This protocol tests whether your system's guardrails, fallbacks, monitoring, and recovery mechanisms can survive the worst-case operator. It's chaos monkey with a donut.
Character essence: Homer is the human failure mode. He represents every misconfiguration, ignored alert, fat-fingered command, and "I'll fix it later" that actually hits production. If your system can survive Homer, it can survive anything.
Sector 7-G --> D'oh! --> Why You Little!
^ |
| v
Coming Up Milhouse <-- Mmm... Donuts <-- Laws of Thermodynamics
Homer falls asleep at the controls.
Homer's default state is inattention. He's at the control panel, but he's asleep, eating donuts, or watching TV. The plant has to run without him. Your system needs to survive operator absence.
Homer energy: Homer didn't DO anything wrong. He just... didn't do anything. That's the test.
Actions:
Output: Survivability report — which failures were detected (alerts fired), which were silent, which caused cascading damage, and how long until human intervention was required.
Something breaks in production. For real.
Homer doesn't just neglect things — he actively causes incidents. He presses the wrong button, spills coffee on the console, or vents radioactive gas because he confused two switches.
Homer energy: "I don't know what I pressed but everything is beeping." That's the scenario.
Actions:
Output: Incident log for each injection — time to detection, time to mitigation, data loss (if any), user impact, and whether automated recovery worked.
Homer's first instinct is to strangle the problem.
When things go wrong, Homer panics. He makes it worse. He grabs Bart by the neck instead of solving the actual problem. This phase tests whether your incident response process prevents panic-driven escalation.
Homer energy: "Why you little!" is the wrong response to every incident. This phase checks whether your process prevents it.
Actions:
Output: Incident response audit — runbook gaps, communication failures, access problems, and response time measurements.
Homer gets distracted from the fix halfway through.
Homer starts fixing the problem, then sees donuts. He abandons the fix, leaving the system in a half-repaired state — often worse than the original failure.
Homer energy: The worst state isn't "broken." It's "half-fixed." Homer is the king of half-fixed.
Actions:
Output: Partial-state assessment — which mid-operation abandonments are recoverable, which create silent corruption, which are detected by monitoring.
Even Homer occasionally gets it right when he goes back to basics.
Homer's rare moments of clarity come when he stops panicking and applies fundamentals. This phase is the actual incident post-mortem.
Homer energy: This is the moment Homer says something accidentally profound. Strip away the panic and the donuts, and the physics still applies.
Actions:
Output: Post-mortem document with timeline, root causes, contributing factors, and specific remediation actions.
Somehow, it all works out.
Springfield survives every Homer-caused disaster. Not because Homer fixes things — but because the safety systems, recovery mechanisms, and (eventually) the right people get it resolved. This phase turns incident findings into permanent improvements.
Homer energy: "Everything's Coming Up Milhouse" is aspirational. The goal is a system where Homer CAN'T cause a disaster — not because he's careful, but because the system won't let him.
Actions:
Output: Hardening backlog with prioritized items. Updated runbooks. New monitoring/alerting. Improved deploy gates.
| Phase | Name | Promise |
|---|---|---|
| 1 | Sector 7-G — Passive Failure Simulation | PASSIVE FAILURES MAPPED |
| 2 | D'oh! — Active Incident Injection | INCIDENTS INJECTED |
| 3 | Why You Little! — Panic Response Audit | RESPONSE AUDITED |
| 4 | Mmm... Donuts — Distraction & Priority Failure | DISTRACTIONS TESTED |
| 5 | Laws of Thermodynamics — Root Cause | ROOT CAUSES FOUND |
| 6 | Everything's Coming Up Milhouse — Recovery | HOMER DONE |
| Trigger | Scope |
|---|---|
| Before production launch | Full loop in staging |
| Quarterly game day | Full loop in production (with safety nets) |
| After a real incident | Phases 5-6 for the specific incident, then Phase 2 to verify fixes |
| New infrastructure component | Phases 1-2 focused on the new component |
| On-call rotation handoff | Phase 3 (can the new on-call follow the runbook?) |
BEFORE --> DURING --> AFTER --> ALWAYS
Lisa Ralph Bart Marge
|
v
Homer
"To alcohol! The cause of, and solution to, all of life's problems."
npx claudepluginhub reggiechan74/simpsons-development --plugin simpsons-developmentGuides chaos engineering workflows: define steady state, map failure domains, design experiments for network failures, timeouts, DNS issues using tc and toxiproxy. For resilience tests and game days.
Designs chaos engineering experiments through 6 phases: scope definition, steady-state baseline, hypothesis formation, failure injection planning, execution, and results analysis. For resilience testing and game days.
Guides chaos engineering experiments: planning failure modes, defining steady-state metrics, and scoping blast radius for resilience validation.