Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add nimadorostkar/Claude-Skills-collection --skill chaos-engineeringgit clone --depth 1 https://github.com/nimadorostkar/Claude-Skills-collectionWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/chaos-engineering)<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/chaos-engineering"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/chaos-engineering/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/chaos-engineering"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/chaos-engineering.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00036 | $0.01178 |
| Opus 5 | $0.00018 | $0.00589 |
| Sonnet 5 | $0.00007 | $0.00236 |
| Haiku 4.5 | $0.00004 | $0.00118 |
Grade A, and why
chaos-engineering scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Chaos Engineering
Purpose
Find out whether your resilience mechanisms work before an outage tests them for you. Every fallback, retry, and circuit breaker is a hypothesis until it has been exercised under real failure.
When to Use
- Verifying that a documented failover, fallback, or degradation path actually works.
- Before a high-stakes event where the system must hold.
- After adding resilience mechanisms — to confirm they do what you think.
- Building confidence in a system nobody fully understands.
Capabilities
- Hypothesis-driven experiment design.
- Failure injection: latency, errors, resource exhaustion, instance termination, network partition, dependency unavailability.
- Blast-radius control and automatic abort.
- Game-day facilitation.
Inputs
- The steady-state metric that defines "working" (error rate, latency, throughput).
- The resilience mechanism being tested and what it is meant to do.
- The blast radius you are willing to accept and the abort criteria.
Outputs
- A finding: the mechanism works, or it does not, with evidence.
- Fixes for the mechanisms that did not.
- A repeatable experiment that runs regularly.
Workflow
- Define steady state — A measurable metric that says the system is healthy right now. Without it, you cannot tell whether the experiment broke anything.
- Form a hypothesis — "When the pricing service returns 500s, checkout will serve cached prices and the checkout success rate will stay above 99%." Falsifiable, specific, and about a mechanism you believe exists.
- Bound the blast radius — Start with one instance, one percent of traffic, or a staging environment carrying production-shaped load. Never start in production at full scale.
- Define the abort criteria first — And automate the abort. "We'll stop it if it looks bad" is not a control.
- Inject the failure and observe — Watch the steady-state metric and the mechanism you are testing. Does the fallback fire? Does the circuit open? Does the alert page?
- Fix what you found, then widen — Increase the blast radius only after the previous scope passes.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 118 lines · 36 tokens per session scan A 1d8581f3b8e4
chaos-engineering is a skill published in the GitHub repository nimadorostkar/Claude-Skills-collection (26 stars, last pushed 25d ago), licensed MIT. It adds 36 tokens to every session and 1,178 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
offensive-fuzzing
Practical offensive fuzzing methodology covering target identification, fuzzer selection (AFL++, libFuzzer, Honggfuzz, Boofuzz, syzkaller), harness writing, corpus curation, mutation strategies, coverage measurement, and crash triage. Use when setting up or running fuzz campaigns against any target: file parsers…
offensive-business-logic
Business logic vulnerability testing for web/mobile/API engagements. Covers workflow bypass, state machine violations, multi-step process abuse, price/quantity/discount manipulation, currency confusion, coupon stacking, refund/chargeback abuse, race conditions on logic boundaries, parameter tampering for hidden flows…
offensive-race-condition
Race condition (TOCTOU) testing checklist: identifying timing windows, Burp Suite Turbo Intruder, Last-Byte sync technique, rate limit bypass, double-spend attacks, and concurrent request exploitation. Use for web app race condition testing or bug bounty time-of-check-to-time-of-use bugs.
smoke-test
Launch the app and hands-on verify that it works by interacting with it. Falls back to an existing integration test suite when there is no interactive surface in scope. Use when the user asks to "smoke test", "test it manually", "verify it works", "try it out", "run a smoke test", "check it in the browser", or "does…
exploratory-test
Execute multi-level exploratory testing of the app covering basic functionality, complex operations, adversarial testing, and cross-cutting scenarios, plus usability observations through a UX lens reported separately from defects. Deeper than /smoke-test. Use when the user asks to "exploratory test", "test…
create-test-plan
Analyze what changed and generate a structured test plan at .turbo/test-plans/ .md covering four escalating levels: basic functionality, complex operations, adversarial testing, and cross-cutting scenarios. Use when the user asks to "create a test plan", "plan tests", "what should I test", "generate test scenarios"…