Install any skill in seconds. Free to start, no credit card required.
Get Started Free →shenli/executing-distributed-system-tests
Use when running a previously designed distributed-systems test plan against a real or simulated cluster — driving fault injection, workload, chaos scenarios, linearizability / consistency runs, durability, partition, crash-recovery, upgrade, performance/SLO runs, tenant isolation runs, boundary or authz runs, fairness / noisy-neighbor runs, or release validation. Also use when asked to "execute the plan", "reproduce a distributed bug", "run stability tests", "drive chaos", "validate a release e
Passed 12 of 19 test cases with the skill, and 5 of 19 without it.
and 6 more in the full report
9 fixed5 passed either way7 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
In author mode, after test skeletons are expanded, compiled, and successfully executed against the cluster, what git operation should be performed?
| Checked | Without skill | With skill |
|---|---|---|
| Refrains from performing git commit on auto-generated test files. | Missed | Passed |
The instructions your model reads when the skill loads.
Pairs with designing-distributed-system-tests. That skill produces
a plan; this skill runs it. The two communicate only through
filesystem artifacts: the plan file in and a session directory
plus findings report out.
The most common failure mode this skill is built to avoid: a run that produces a green checkmark without anyone having checked that the workload, the fault, and the oracle each did their job. The "green-but-broken" checks are not optional.
If a plan file path was supplied, read it. If the user described a plan in conversation, extract the scenario list. If the plan is missing oracles or per-scenario budget tiers (Smoke / Hardening / Release, per the plan template's §7 scenario fields), halt — hand back to the design skill rather than improvise. Improvising an oracle in the moment is how green-but-broken results get produced.
Search the repo before writing any new code. Look for:
tools/, scripts/, bin/ — drivers, workload generators,
cluster bring-up scriptstests/integration/, tests/stability/, tests/chaos/docs/runbooks/, docs/testing/, docs/stability-test-plan.mdcargo xtask targets that look like
cluster commandsRecord what you found in the session log under "Toolbox discovered". This is required before any scenario runs — it prevents the skill from re-inventing tools that already exist.
test cases passed, vs 5 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.