Skip to content
Get packs

Guide · Agent skill

How to use the Chaos Engineer agent skill (chaos-engineer)

Updated · written with AI from the project's own documentation and checked against our catalogue data

The chaos-engineer skill is a set of instructions and reference files that an AI agent can load to help you plan chaos engineering work: deliberately breaking parts of a system in a controlled way to see whether it stays up. It is aimed at SREs, DevOps engineers and teams preparing a game day. After reading this guide you will know what the skill does, how to install it, how to ask for help in plain language, and which safety checks to keep in place before any failure is injected.

Chaos EngineerJeffallan/claude-skills · MIT

Quick start

  1. 1Download the ZIP. Download the chaos-engineer ZIP from the skill page on this site.
  2. 2Place the skill folder. Unzip it so the chaos-engineer folder sits in ~/.claude/skills/ for personal use, or in your project's .claude/skills/ folder.
  3. 3Or upload it in the apps. In the Claude apps, go to Settings → Capabilities → Skills and upload the ZIP.
  4. 4Install the tools you need. For Litmus examples, have kubectl, cluster access and Litmus Chaos. For latency tests, install the toxiproxy CLI and server.
  5. 5Describe your goal. Ask in plain language, naming the system, the failure and the environment, and the artifact you want.
  6. 6Review the output. Check namespaces, labels and targets, and switch any production references to staging before applying.
  7. 7Test the abort path. Confirm the rollback steps work before starting the experiment, then monitor and write a learning summary afterward.

What is an agent skill and what does this one do?

An agent skill is a folder containing a SKILL.md file and optional reference files. When the skill is installed, an agent such as Claude can read it and follow its guidance when a request matches the skill's description. The chaos-engineer skill covers designing chaos experiments, building failure injection frameworks, and running game day exercises for distributed systems.

The skill helps the agent produce concrete artifacts: experiment design documents, runbooks, experiment manifests, rollback procedures and post-mortem templates. Its core workflow is system analysis, experiment design, controlled execution, learning and improvement, and finally automation in CI/CD.

  • Write a hypothesis and define steady-state metrics
  • Limit blast radius, starting with the smallest possible scope
  • Plan rollback and abort paths
  • Plan and run game day exercises
  • Write post-mortem templates
  • Provide example commands for Litmus Chaos, toxiproxy and Chaos Monkey

Install the chaos-engineer skill

Download the chaos-engineer ZIP from the skill page on this site. Unzip it so that the chaos-engineer folder (containing SKILL.md and the references folder) sits inside a skills directory. For a personal install, use ~/.claude/skills/. For a single project, put it in the project's .claude/skills/ folder.

You can also upload the ZIP in the Claude apps under Settings → Capabilities → Skills. Use this route if you work in the apps rather than a local project folder.

  • Personal install: ~/.claude/skills/chaos-engineer/
  • Project install: .claude/skills/chaos-engineer/ inside your project
  • Claude apps: Settings → Capabilities → Skills, then upload the ZIP

Check what you need before you start

The skill itself does not run scripts and does not use the network. The examples it produces depend on tools you install separately. The examples assume familiarity with Kubernetes, distributed systems and the command line.

For the Litmus examples you need kubectl and access to a Kubernetes cluster, with Litmus Chaos installed in that cluster. The network latency example needs the toxiproxy CLI and server. The Chaos Monkey example is optional and needs a Chaos Monkey / Spinnaker configuration.

  • kubectl and cluster access (Litmus examples)
  • Litmus Chaos installed in the cluster (ChaosEngine examples)
  • toxiproxy CLI and server (network latency example)
  • Chaos Monkey / Spinnaker configuration (optional Chaos Monkey example)

Trigger the skill with natural requests

You do not need a special command. Describe the task in plain language and mention the kind of work involved. The skill's description lists triggers such as chaos experiments, resilience testing, blast radius control, game days, fault injection, Chaos Monkey and Litmus Chaos.

Good requests name the system, the failure you want to test and the environment. Ask for the output you need, such as a runbook or a manifest, so the agent knows which artifact to produce.

  • Design a chaos experiment that kills pods in our checkout service and checks that orders still complete. We run it in staging first.
  • Help me plan a game day for a database failover, with a runbook and a post-mortem template.
  • Write a hypothesis, steady-state metrics and a rollback plan for adding 300ms latency to our payment database connection.
  • Create a blast radius limit for a Litmus pod-delete experiment on three replicas.

Read the generated experiment before you run it

The skill's pod-delete example is a Litmus ChaosEngine manifest. It verifies a baseline, applies the experiment, watches the ChaosResult, tails logs and includes an abort path. Its example manifests target a namespace called production. Change the namespace to a staging environment before applying anything, and check every name, label and namespace against your cluster.

The abort command in the example sets engineState to stop on the ChaosEngine, then checks the rollout status of the deployment. Test this path before the experiment starts. The skill's safety checklist asks for an automated rollback of 30 seconds or less that is scripted and tested in advance.

  • Confirm the kubectl context points at the cluster you intend to use
  • Replace production namespaces with a staging namespace for first runs
  • Run the abort command once in a safe setting to confirm it works
  • Keep the monitoring commands open during the experiment
kubectl patch chaosengine my-service-pod-delete \n -n production --type merge -p '{"spec":{"engineState":"stop"}}'\nkubectl rollout status deployment/my-service -n production

Follow the safety checklist for every experiment

The skill sets out constraints that apply to every experiment. Establish steady state before injecting any failure. Cap the blast radius and change only one failure condition at a time. Customer-facing environments need safety nets such as circuit breakers, feature flags or canary isolation.

Every experiment should end with a written learning summary and at least one tracked improvement. The skill's guidance on game days covers planning, execution and learning.

  • Steady state first: define and verify baseline metrics
  • Blast radius cap: start small and expand only after validation
  • Single variable: one failure condition at a time
  • No production without safety nets
  • Close the loop with a learning summary and tracked improvement

What people use it for

  • Designing a pod-delete experiment on a staging Kubernetes service with a capped share of replicas affected
  • Adding controlled network latency to a downstream database connection with toxiproxy and removing it afterward
  • Writing a game day plan for a database failover, including objectives, roles and scenarios
  • Producing a post-mortem template after an experiment reveals a weakness
  • Planning a Chaos Monkey configuration that restricts kills to specific accounts and excludes canary instances

Frequently asked questions

Is the chaos-engineer skill free?

The skill is published under the MIT licence, as stated in its SKILL.md. The tools it references, such as Litmus Chaos, toxiproxy and Chaos Monkey, are separate projects with their own licences and setup requirements.

What do I need to install before using it?

The skill itself needs no scripts or network access. The example commands need kubectl with a Kubernetes cluster and Litmus Chaos for the ChaosEngine examples, the toxiproxy CLI and server for the latency example, and optionally a Chaos Monkey / Spinnaker configuration.

Where do I put the skill so Claude can find it?

Unzip the folder into ~/.claude/skills/ for personal use or into a project's .claude/skills/ folder. In the Claude apps you can instead upload the ZIP under Settings → Capabilities → Skills.

Is it safe to run the generated commands against production?

Not without review. The example manifests target a production namespace, and a wrong target could cause a real outage. Review every namespace and label, start in staging, and confirm the abort path works first.

What are alternatives to chaos-engineer for chaos testing?

The skill's reference files cover Chaos Monkey, Gremlin and Pumba, along with Litmus Chaos and Chaos Mesh for Kubernetes. Choose based on your platform and whether you need a guided design workflow or only the tool itself.

Why isn't the skill triggering or showing up?

Check that the chaos-engineer folder, including SKILL.md, sits directly inside the correct skills directory. Then describe your task using terms from the skill, such as chaos experiment, game day or fault injection.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

This skill suits SRE and DevOps engineers planning resilience tests for production-like services, teams preparing a first game day, and engineers setting up fault injection in a staging Kubernetes cluster. It is not a good fit for running experiments straight against production, for small single-server apps without redundancy, or for non-technical users, because it assumes Kubernetes and CLI experience.

Download the skill