Chaos Engineering

Helps you deliberately break things in production-like environments to find weaknesses before they find you. You'd reach for this when you want to test how your system handles network latency, service failures, resource exhaustion, or other real-world chaos. The approach is straightforward: inject failures, observe what breaks, fix it, repeat. Honestly, it's one of those things that feels reckless until you've had a 3am outage that chaos testing would have caught. Works best when you have monitoring in place to actually see what happens when you start yanking cables.

skills.sh installs: 497
GitHub stars: 29.5K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add alirezarezvani/claude-skills --skill chaos-engineering --agent claude-code

Installs into .claude/skills of the current project.

Files

Chaos Engineering

Design experiments that surface real weaknesses in production systems — without becoming outages. Most "chaos engineering" attempts skip steady-state measurement, define no abort criteria, and have no blast-radius bound. This skill enforces the discipline that makes chaos experiments safe and useful.

When to use

Planning a chaos experiment (what to break, where, when, how to abort)
Calculating blast radius before running the experiment
Reviewing an existing experiment plan for safety
Choosing a chaos tool (Chaos Toolkit / Chaos Mesh / Litmus / Gremlin / AWS FIS)
Writing a chaos experiment postmortem
Running a Game Day exercise

When NOT to use

General incident response (use incident-response)
Threat hunting / red-team (use red-team, threat-detection)
Performance load testing (different goal — chaos is about failure modes, not capacity)
Production debugging (chaos discovers weaknesses preemptively, not after-the-fact)