chaos-engineering
Design rigorous chaos engineering experiments and resilience audits to verify production system reliability.
skill install https://www.promptspace.in/skills/chaos-engineeringThe Science of Controlled Failure
Moving beyond generic checklists, this skill transforms your AI agent into a senior Chaos Engineer. It addresses the fundamental problem of "theoretical resilience" by replacing vague recommendations with falsifiable, evidence-based experimitalic textents. Instead of suggesting you "add retries," it helps you design the exact stress test needed to prove your system won't collapse under a retry storm.
What it does
- Experiment Design: Drafts specific chaos experiments with measurable hypotheses, single-variable perturbations, and defined blast radii.
- Resilience Auditing: Identifies hidden architectural amplifiers like thundering herds, gray failures, and synchronized backoffs.
- Operational Rigor: Defines the human roles (Lead, Observer, Abort Authority) and readiness flags required to run experiments safely in production.
- Post-Mortem Conversion: Analyzes past incidents to create "never again" experiments that verify fixes.
Why use this skill?
Standard AI prompting often results in "best practice" lists that are difficult to action. This skill enforces a rigorous four-phase procedure (Hypothesize, Perturb, Minimize, Learn) that treats infrastructure as a laboratory. It focuses on tail-risk (P99/P99.9) rather than averages, ensuring your systems are hardened against the worst-case scenarios that actually cause outages.
Use cases
- Design controlled fault-injection experiments for production environments.
- Identify single points of failure in distributed microservices architectures.
- Plan high-stakes 'Game Day' simulations for engineering teams.
- Audit architecture for 'gray failures' and hidden system-coupling amplifiers.
- Specify measurable safety bounds and abort conditions for reliability tests.
Example
Prompt
Output
Hypothesis: P99 latency for /checkout remains <1.2s during payment gateway latency. Perturbation: Inject 300ms latency on the 'payment-v2' service for 5% of traffic for 10 mins. Abort Condition: Error rate > 2% for 120s. Targeted Amplifier: Retry storm and thread-pool exhaustion.
Known limitations
- Planner only: the skill designs experiments but does not execute them. You run the experiments using your own tools (Gremlin, Litmus, Chaos Mesh, AWS FIS, custom tooling). - Garbage in, garbage out on system context: the agent does not know your specific architecture. You describe the system and dependencies; the agent designs experiments against what you describe. Undocumented dependencies will not be caught. - Best for systems with observable telemetry. Architectures lacking dashboards, P99 latency tracking, or error-rate alerting will hit a wall at the steady-state hypothesis phase. - Not a substitute for post-mortem culture. The skill plans experiments and learns from outcomes; it does not run retrospectives or write incident reports. - Single-experiment focus: the skill designs one experiment at a time. Continuous chaos automation strategy (Chaos Monkey-style ongoing fleet experiments) requires additional tooling and program design beyond what the skill teaches. - Vocabulary assumes mainstream distributed-systems patterns (Kubernetes, cloud, microservices, retries, circuit breakers). Less directly applicable to highly proprietary or unusual architectures without translation.