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 agentmods add skills/borhen68/skillengine/chaos-engineeringnpx skills add borhen68/SkillEngine --skill chaos-engineeringgit clone --depth 1 https://github.com/borhen68/SkillEngineWhat 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 | $0.00059 | $0.02572 |
| Opus 5 | $0.00030 | $0.01286 |
| Sonnet 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 2d 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.
- 2d 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 2mo ago), licensed MIT. It adds 59 tokens to every session and 2,572 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
doubt-driven-development
在每个非平凡决策成立前，用全新上下文进行对抗式审查。当正确性比速度更重要、处理不熟悉代码、风险较高（生产、安全敏感逻辑、不可逆操作），或任何自信输出现在验证比之后调试更便宜时使用。.
test-driven-development
用测试驱动开发。用于实现任何逻辑、修复任何 bug，或改变任何行为。用于需要证明代码能工作、收到 bug 报告，或即将修改现有功能时。.
ci-cd-and-automation
自动化 CI/CD pipeline 设置。用于设置或修改构建和部署 pipeline 时；用于需要自动化质量门禁、在 CI 中配置 test runners，或建立部署策略时。.
code-review-and-quality
执行多维度代码审查。用于合并任何变更之前；用于审查自己、其他 agent 或人类编写的代码；用于在代码进入主分支前从多个维度评估代码质量。.
code-simplification
为清晰度简化代码。用于在不改变行为的前提下重构代码以提升清晰度；用于代码能运行但比应有状态更难阅读、维护或扩展时；用于审查已累积不必要复杂度的代码时。.
context-engineering
优化 agent 上下文设置。当开始新会话、agent 输出质量下降、在任务之间切换，或需要为项目配置规则文件和上下文时使用。.