conducting-chaos-engineering
This skill enables Claude to design and execute chaos engineering experiments to test system resilience. It is used when the user requests help with failure injection, latency simulation, resource exhaustion testing, or resilience validation. The skill is triggered by discussions of chaos experiments (GameDays), failure injection strategies, resilience testing, and validation of recovery mechanisms like circuit breakers and retry logic. It leverages tools like Chaos Mesh, Gremlin, Toxiproxy, and AWS FIS to simulate real-world failures and assess system behavior.
63
53%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./backups/skills-migration-20251108-070147/plugins/testing/chaos-engineering-toolkit/skills/chaos-engineering-toolkit/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly defines a specific domain (chaos engineering), lists concrete actions and tools, and provides explicit trigger conditions. The description covers both what the skill does and when it should be used, with rich natural trigger terms that users in this domain would naturally use. Minor improvement could be made by tightening the prose slightly, as it's somewhat verbose, but the content quality is high.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'design and execute chaos engineering experiments', 'failure injection', 'latency simulation', 'resource exhaustion testing', 'resilience validation', and names specific tools like Chaos Mesh, Gremlin, Toxiproxy, and AWS FIS. | 3 / 3 |
Completeness | Clearly answers both 'what' (design and execute chaos engineering experiments, simulate failures, assess system behavior) and 'when' ('used when the user requests help with failure injection, latency simulation...', 'triggered by discussions of chaos experiments'). Explicit trigger guidance is provided. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'chaos engineering', 'failure injection', 'latency simulation', 'resource exhaustion', 'resilience testing', 'GameDays', 'circuit breakers', 'retry logic', plus specific tool names like 'Chaos Mesh', 'Gremlin', 'Toxiproxy', 'AWS FIS'. | 3 / 3 |
Distinctiveness Conflict Risk | Chaos engineering is a very specific niche domain with distinct terminology (GameDays, failure injection, circuit breakers, Chaos Mesh, Gremlin). This is unlikely to conflict with other skills due to the highly specialized vocabulary and tooling. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
7%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads like a marketing description of chaos engineering capabilities rather than an actionable guide. It lacks any concrete code examples, tool configurations, CLI commands, or validation steps that would enable Claude to actually help users execute chaos experiments. The content explains concepts Claude already knows while failing to provide the specific, executable guidance that would make this skill useful.
Suggestions
Add concrete, executable examples: include actual Chaos Mesh YAML manifests, Toxiproxy configuration snippets, AWS FIS experiment JSON templates, and CLI commands for each tool.
Add explicit validation and safety workflows: include pre-experiment checklists (blast radius confirmation, rollback plan), monitoring verification steps during execution, and post-experiment validation procedures.
Remove the 'How It Works,' 'When to Use This Skill,' and 'Integration' sections—these describe Claude's behavior rather than instructing it, wasting tokens on meta-description.
Replace the high-level 'Examples' section with fully worked examples showing input configurations, expected outputs, and specific commands to run.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is verbose and padded with unnecessary explanations. Sections like 'How It Works,' 'When to Use This Skill,' and 'Integration' describe Claude's own behavior rather than providing actionable instructions. Much of the content restates what Claude already knows about chaos engineering concepts. | 1 / 3 |
Actionability | There is no executable code, no concrete commands, no configuration snippets, and no copy-paste ready examples. The examples describe what 'the skill will' do at a high level rather than providing actual Chaos Mesh YAML manifests, Toxiproxy configurations, or AWS FIS experiment templates. Everything remains at the level of vague description. | 1 / 3 |
Workflow Clarity | The four-step 'How It Works' workflow is abstract and lacks any validation checkpoints, feedback loops, or concrete sequencing. For chaos engineering—which involves destructive operations—there are no safety gates, rollback procedures, or verification steps mentioned. | 1 / 3 |
Progressive Disclosure | The content is organized into logical sections with clear headings, which provides some structure. However, there are no references to external files, no bundle files to support deeper content, and the inline content is shallow rather than appropriately split between overview and detail. | 2 / 3 |
Total | 5 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Commit
13d35b8
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.