Community

chaos-experiment-design

Open Agent Skill · coding · works with Claude Code, Codex, Cursor, and compatible agents

Plan chaos and resilience experiments safely with hypotheses, blast radius limits, and abort criteria. Use whenever the user asks for chaos engineering, game days, fault injection, resilience experiments, or how to safely break things in staging or production.

View on GitHub

Chaos Experiment Design

Chaos without a hypothesis is vandalism. Scope blast radius, define steady state, abort criteria, and learnings — prefer staging before prod.

Workflow

  1. Hypothesis: if X fails, Y still holds (SLO/user journey).
  2. Steady-state metrics and dashboards.
  3. Fault: type, target, magnitude, duration.
  4. Blast radius, blast radius controls, abort conditions.
  5. Observability and comms (who knows, status page if needed).
  6. Runbook for inject + stop; post-experiment notes.
  7. Never surprise prod; approval for prod experiments.

Output format

## Experiment: <name>
**Hypothesis:** …
**Steady state:** …
**Method:** …
**Blast radius:** …
**Abort if:** …
**Schedule / env:** …
**Rollback:** …
**Learning questions:** …

Rules

  1. No unannounced production chaos.
  2. One variable at a time when possible.
  3. Customer-impacting faults need explicit approval language.
  4. Capture learning even if the system “passed”.
  5. Do not invent tool-specific syntax you are unsure of.

Edge cases

  • Game days: facilitation roles + scenario script.
  • Multi-region: partial vs full region loss.
  • Data plane faults: disk full, poison messages, clock skew.