CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/chaos-experiment-author

Build-an-X workflow for a chaos experiment per the Principles of Chaos Engineering - defines steady-state hypothesis, picks the variables (real-world events: network latency, node failure, region outage), sets the blast radius (which percentage / namespace / user cohort), automates execution, and emits the verdict (steady-state held / didn't hold). Includes the five-check pre-flight validation of the steady-state hypothesis (measurable, baselined, SLI-backed tolerance, defined measurement window, metric moves under the fault) with hard-reject rules, and routes the tool choice: Chaos Mesh has its own standalone skill, while LitmusChaos and Gremlin setup live in this skill's references. Use to scope and pre-flight-validate a chaos experiment before running it via Chaos Mesh / Litmus / Gremlin / Toxiproxy.

77

Quality

97%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

92%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, action-oriented skill body with a clear 7-step workflow, explicit pre-flight validation and hard-reject gating, copy-paste YAML/CI examples, and one-level-deep references that all resolve to real bundle files. Only minor conciseness trims would tighten it further.

Suggestions

Trim or compress the 'Bad hypotheses'/'Good hypotheses' lists in Step 1, since the measurable/non-measurable distinction is already conveyed by the hypothesis YAML and the validation checks.

Avoid restating Principle 1 ('Focus on the measurable output...') in both Step 1 and the steady-state validation section; cite it once to save tokens.

Consider tightening the Limitations section, whose bullets partly restate ideas already covered in the steps above.

DimensionReasoningScore

Conciseness

The body is largely lean with tight YAML examples and detail deferred to references, but the 'Bad hypotheses'/'Good hypotheses' lists and the Principle 1 restatement in the validation section restate what measurable means and could be trimmed.

4 / 5

Actionability

Provides copy-paste-ready artifacts throughout: a hypothesis YAML, blast-radius/abort YAML, a complete GitHub Actions workflow with kubectl apply/wait/get commands, and a pre-flight verdict format template with named pass/fail criteria.

5 / 5

Workflow Clarity

A clear 7-step sequence (Define -> Pick event -> Blast radius -> Tool -> Automate -> Run in prod? -> Verdict) with explicit pre-flight validation, hard-reject conditions, and feedback-loop actions (revise probe / replace metric / add baseline) gating a risky production operation.

5 / 5

Progressive Disclosure

Body is an overview that defers detail to five real, one-level-deep, clearly-signaled reference files (all confirmed present in the bundle) covering the event catalog, anti-patterns, report template, tolerance forms, and per-tool deep dives, with a summary References section.

5 / 5

Total

19

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with concrete enumerated actions, a natural explicit trigger phrase, and a clear scope that distinguishes authoring/pre-flight validation from sibling run-protocol skills. All four dimensions land at the top anchor; no changes needed.

DimensionReasoningScore

Specificity

Names multiple concrete actions - 'defines steady-state hypothesis, picks the variables...sets the blast radius...automates execution, and emits the verdict' - plus the five named pre-flight checks, giving comprehensive coverage of concrete capabilities.

5 / 5

Completeness

Explicitly answers both what (hypothesis, variables, blast radius, automation, verdict, five-check validation) and when ('Use to scope and pre-flight-validate a chaos experiment before running it via Chaos Mesh / Litmus / Gremlin / Toxiproxy').

5 / 5

Trigger Term Quality

Covers natural user terms including 'chaos experiment', 'steady-state hypothesis', concrete fault types (network latency, node failure, region outage), 'blast radius', and tool names (Chaos Mesh / Litmus / Gremlin / Toxiproxy) with an explicit 'Use to...' trigger.

5 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (chaos experiment authoring + pre-flight validation) and explicitly notes Chaos Mesh has its own standalone skill, drawing a boundary that minimizes conflict with sibling skills.

5 / 5

Total

20

/

20

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents