testland/chaos-experiment-author
Build-an-X workflow for a chaos experiment per the Principles of Chaos Engineering - defines steady-state hypothesis, picks the variables (real-world events: network latency, node failure, region outage), sets the blast radius (which percentage / namespace / user cohort), automates execution, and emits the verdict (steady-state held / didn't hold). Includes the five-check pre-flight validation of the steady-state hypothesis (measurable, baselined, SLI-backed tolerance, defined measurement window, metric moves under the fault) with hard-reject rules, and routes the tool choice: Chaos Mesh has its own standalone skill, while LitmusChaos and Gremlin setup live in this skill's references. Use to scope and pre-flight-validate a chaos experiment before running it via Chaos Mesh / Litmus / Gremlin / Toxiproxy.
77
97%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
chaostoolkit-tolerance.mdreferences/
Chaos Toolkit steady-state-hypothesis block and tolerance forms
Reference for the steady-state hypothesis validation section of
chaos-experiment-author. The five pre-flight checks there validate a
hypothesis expressed in this schema; this file is the schema and tolerance
detail they assume.
The steady-state-hypothesis object
Per chaostoolkit.org/reference/api/experiment/, the
steady-state-hypothesis object requires:
title(string): human-readable rationale for the hypothesis.probes(array): one or more probe objects, each with:type:"probe"name: identifier stringprovider: execution specification (HTTP, process, or Python)tolerance: the gate value; if the probe's return value does not satisfy the tolerance, the experiment bails before running the method.
Tolerance forms supported
Per chaostoolkit.org/reference/api/experiment/:
| Tolerance form | Syntax example | Evaluation |
|---|---|---|
| Scalar equality | "tolerance": 200 | probe return == 200 |
| Boolean equality | "tolerance": true | probe return == true |
| String equality | "tolerance": "OK" | probe return == "OK" |
| Inclusive range | "tolerance": [95, 100] | 95 <= value <= 100 |
| Membership | "tolerance": [200, 201, 204] | value in list |
| Regex | "tolerance": {"type": "regex", "pattern": "^healthy$"} | regex match |
| JSONPath | "tolerance": {"type": "jsonpath", "path": "$.status", "expect": "up"} | JSONPath extract + compare |
| Range object | "tolerance": {"type": "range", "range": [95.0, 100.0]} | numeric bounds |
Execution flow
Per chaostoolkit.org/reference/concepts/: probes run once before the method (baseline check) and once after (deviation check). A probe that fails before the method means the system is already outside its acceptable state; the experiment must not run. A probe that fails after the method means the chaos activity caused the system to leave its steady state.