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 borhen68/SkillEngine --skill chaos-engineeringgit clone --depth 1 https://github.com/borhen68/SkillEngineWrote 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/borhen68/skillengine/chaos-engineering)<a href="https://agentmods.dev/skills/borhen68/skillengine/chaos-engineering"><img src="https://agentmods.dev/badge/skills/borhen68/skillengine/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/borhen68/skillengine/chaos-engineering"><img src="https://agentmods.dev/badge/skills/borhen68/skillengine/chaos-engineering.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00059 | $0.02572 |
| Opus 5.5 | $0.00024 | $0.01029 |
| Sonnet 5.5 | $0.00012 | $0.00514 |
| Haiku 4.5 | $0.00006 | $0.00257 |
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 1mo 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 — 284 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Chaos Engineering
Overview
Chaos engineering is the discipline of experimenting on a system to build confidence in its capability to withstand turbulent conditions. Instead of hoping nothing breaks, you intentionally break things in controlled ways to discover weaknesses before they discover you in production.
The core insight: Systems fail in ways you didn't anticipate. You can't test for every failure mode, but you can systematically surface unknown dependencies, hidden single points of failure, and misconfigured timeouts. Chaos engineering turns "it probably works" into "we've proven it works under these failure conditions."
When to Use
- Building or operating distributed systems (microservices, serverless, multi-region)
- Before a major launch or traffic event where failure is expensive
- After architectural changes that affect data flow or service dependencies
- When incident post-mortems reveal "we didn't know X could fail"
- Setting SLOs/SLAs and need empirical data on actual failure behavior
- Migrating to new infrastructure (cloud provider, database, message queue)
NOT for:
- Systems without basic monitoring and observability (you can't chaos test what you can't observe)
- Production environments without on-call coverage and rollback procedures
- Systems handling life-critical or financial transactions without explicit authorization
The Chaos Engineering Process
Step 1: Define Steady State
Before you break anything, define what "working" looks like:
STEADY STATE HYPOTHESIS:
- Metric: [quantifiable metric, e.g. p99 latency < 200ms]
- Baseline: [current observed value, e.g. 145ms]
- Threshold: [failure threshold, e.g. > 300ms]
- Duration: [how long the system must maintain this, e.g. 5 minutes]
Good steady state metrics:
- Request success rate (should be > 99.9% for most services)
- p50/p99 latency (measured from the client perspective)
- Error rate by endpoint (catch localized failures)
- Queue depth / backlog (for async systems)
- Business metrics (checkouts completed, messages processed)
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.
- 1mo ago First seen · 284 lines · 59 tokens per session scan A c7ebcd1dbaa4
chaos-engineering is a skill published in the GitHub repository borhen68/SkillEngine (17 stars, last pushed 4mo ago), licensed MIT. It adds 59 tokens to every session and 2,572 once invoked, about $0.0002 per session on Opus 5.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-08-30.
Other skills, from other repositories
constraint-driven-development
A development method for writing a project's quality standards as a lasting, checkable contract. It can cover areas such as test coverage, security, performance, accessibility, and architecture.
test-driven-development
Instructions for test-driven development, or TDD: writing a failing test first, then the smallest code that makes it pass, followed by cleanup.
browser-testing-with-devtools
A guide for testing web pages and browser-based applications in a real Chrome browser through Chrome DevTools. It checks what is actually rendered and how the page behaves at runtime.
test-driven-development
Drives development with tests using the red-green-refactor loop. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Use when asked to add tests to a function, fix a bug…
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be…
test-driven-development
Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.