chaos
starsforks
How to install chaos?
softspark/ai-toolkit/chaos
$npx -y skills add softspark/ai-toolkit --skill chaosInjects controlled faults for resilience testing on non-prod. Triggers: chaos, fault injection, latency injection, dependency kill, resilience test.
SKILL.md
| 1 | # Chaos Command |
| 2 | |
| 3 | $ARGUMENTS |
| 4 | |
| 5 | Triggers a controlled resilience experiment. |
| 6 | |
| 7 | ## Usage |
| 8 | |
| 9 | ```bash |
| 10 | /chaos <experiment> [target] |
| 11 | # Example: /chaos latency backend-api |
| 12 | # Example: /chaos kill redis |
| 13 | ``` |
| 14 | |
| 15 | ## Protocol |
| 16 | 1. **Safety Check**: Verify env != PROD. |
| 17 | 2. **Baseline**: Check system health is green. |
| 18 | 3. **Inject**: Run the fault injection. |
| 19 | 4. **Observe**: Monitor logs/metrics for 60s. |
| 20 | 5. **Recover**: Restore system health. |
| 21 | 6. **Report**: Did we survive? |
| 22 | |
| 23 | ## Rules |
| 24 | |
| 25 | - **MUST** verify target environment is non-production before injecting |
| 26 | - **NEVER** run against a system without a healthy baseline |
| 27 | - **CRITICAL**: abort immediately if recovery does not complete within the observation window |
| 28 | - **MANDATORY**: log every injected fault with timestamp and scope |
| 29 | |
| 30 | ## Gotchas |
| 31 | |
| 32 | - `NODE_ENV=production` on a developer's machine is common — checking that env var alone is not enough proof of non-prod. Combine with kubeconfig context, cloud account ID, or a project-specific env file check before injecting. |
| 33 | - `docker stats` reports cached values; the first sample immediately after injection is often pre-fault. Wait at least 5 seconds before reading metrics. |
| 34 | - Kubernetes liveness probes may self-heal the faulted pod inside the 60s observation window — the report shows green while the workload is still flapping. Check pod restart counters, not just health endpoints. |
| 35 | - Latency injected with `tc` (Linux traffic control) persists across container restarts on the host and across SIGTERM. Always pair the inject step with an explicit `tc qdisc del dev <iface> root` cleanup in the recover step — the `fork` context will not undo it for you. |
| 36 | |
| 37 | ## When NOT to Use |
| 38 | |
| 39 | - In production without an explicit, written runbook — use `/workflow incident-response` for real incidents |
| 40 | - When the system has no observability (no metrics, no logs) — fix observability first |
| 41 | - For load testing — use dedicated load-test tooling, not chaos injection |
| 42 | - During an active incident — stabilize first with `/panic`, then investigate |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
