CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/chaos-mesh

Use when a system runs on Kubernetes and fault experiments should be declared as CRDs next to the workloads. Configures Chaos Mesh pod, network, stress, IO, time, DNS, kernel and HTTP faults, label selectors, namespace limits on blast radius, schedules and the dashboard.

Quality

84%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

75%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, highly actionable tool skill: it sequences install through verdict across nine steps with concrete commands and near-complete YAML for the main chaos types, includes verification and a useful anti-patterns table. The main gaps are marketing-quote padding, placeholder selectors in the Workflow example, a referenced verdict script that does not exist in the bundle, and no error-recovery guidance.

Suggestions

Remove the quoted homepage passages ("enormous capability to orchestrate fault scenarios", "no special dependencies required", etc.) and state the facts directly — Claude does not need the marketing framing, and this would lift conciseness to 5.

Complete the Workflow example by replacing the "selector: { ... }" placeholders with real selectors, and either inline the steady-state verdict check in the CI step or ship the referenced ./scripts/datadog-verdict.sh, since the file does not exist in this bundle.

Add an error-recovery checkpoint after Step 7 (e.g., what to do when an experiment never transitions from Created to Running, and how to clean up on abort) to close the workflow feedback-loop gap for these destructive operations.

DimensionReasoningScore

Conciseness

The body is mostly lean (commands, YAML manifests, compact tables), but quoted homepage passages like "enormous capability to orchestrate fault scenarios" and "no special dependencies required" are marketing filler, and the pinned "--version 2.6.3" is time-sensitive detail not placed in a deprecated/old-patterns section — efficient with minor trimming possible, so 4 rather than 5.

4 / 5

Actionability

Guidance is mostly executable and copy-paste ready (helm install with pinned version, kubectl port-forward/apply/get/describe, three near-complete YAML manifests), but the Workflow example uses "selector: { ... }" pseudocode placeholders and the CI step references "./scripts/datadog-verdict.sh", which does not exist in this bundle — minor gaps, so 4 rather than 5.

4 / 5

Workflow Clarity

Steps 1-9 give a clear install → author → orchestrate → run/verdict sequence with explicit verification ("kubectl get networkchaos -w", "verify the steady-state hypothesis held", CI Datadog check), so the destructive-operation cap does not apply; however there is no error-recovery feedback loop (e.g., what to do if an experiment stays in Created, or cleanup on abort), matching 4 rather than 5.

4 / 5

Progressive Disclosure

The 255-line body is well-sectioned with clear headers and a References section, but all detail is inline — no local bundle files exist, and the only references are external URLs plus pointers into a sibling skill's files; content like the full Workflow and PhysicalMachineChaos manifests could be offloaded to reference files. Good structure with minor organization gaps, so 4 rather than 5 (the under-50-lines exception does not apply).

4 / 5

Total

16

/

20

Passed

Description

88%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: it names the tool, comprehensively lists concrete capabilities across all fault types plus selectors, scheduling, and the dashboard, and opens with an explicit condition-based "Use when" trigger. The only weaknesses are missing common synonyms (chaos engineering, fault injection, resilience testing) and slight overlap risk with sibling Kubernetes chaos skills whose experiments are also CRDs.

DimensionReasoningScore

Specificity

"Configures Chaos Mesh pod, network, stress, IO, time, DNS, kernel and HTTP faults, label selectors, namespace limits on blast radius, schedules and the dashboard" enumerates the full fault-type surface plus selectors, blast-radius control, schedules, and the dashboard — comprehensive concrete actions with no coverage gaps, matching the 5 anchor rather than 4.

5 / 5

Completeness

It explicitly answers both: "Use when a system runs on Kubernetes and fault experiments should be declared as CRDs next to the workloads" gives a concrete when-clause with trigger conditions, and the configuration enumeration gives a clear what — matching the 5 anchor; 4 would require the when to be less explicit.

5 / 5

Trigger Term Quality

Natural terms users would say are present ("Kubernetes", "Chaos Mesh", "fault experiments", "CRDs", "blast radius", "dashboard"), but common synonyms like "chaos engineering", "fault injection", or "resilience testing" are missing, so it fits 4 (good coverage, a few natural terms missing) rather than 5.

4 / 5

Distinctiveness Conflict Risk

Naming "Chaos Mesh" establishes a clear niche, but the when-clause (Kubernetes + CRD-declared fault experiments) would equally match a closely related sibling chaos tool such as LitmusChaos, giving minor overlap risk — anchor 4 rather than 5.

4 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

referenced_paths_exist

Referenced path issues: 2 missing

Warning

Total

15

/

16

Passed

Reviewed

On this page