Use when designing a test plan for a distributed or stateful system — anything with persistence, replication, consensus, retries, idempotency, async messaging, multi-tenancy, or partial failure. Plans are claim-driven: investigate the product's claimed guarantees first, then design hypotheses and scenarios that try to falsify those claims under fault. Handles change-scoped plans (a commit / PR / feature) and project-wide plans (holistic, with existing-test inventory and gap analysis). Also use w
SkillScore65Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/28/2026
What it changes
Passed 14 of 21 test cases with the skill, and 7 of 21 without it.
Without skill35%
With skill65%
Checks it passed that the model alone missed
Encodes targeted property claims directly into scenario names.
Uses an auto/ subdirectory path for generated test file targets.
Defines the oracle using a quantitative per-group fairness formula.
and 6 more in the full report
9 fixed6 passed either way6 still failing2 broke
Pass-rate lift
+30 pp
Tokens
+236%
Agent turns
0%
Response time
+38%
Model gemini-3.6-flashMeasured 8/28/2026v115 of 23 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 9
Prompt
We modified our multi-tenant API gateway to prevent Tenant A from reading Tenant B's data across gRPC, REST, and WebSocket interfaces. Design a change-scoped test plan focusing on tenant isolation.
What was checked, without and with the skill
Checked
Without skill
With skill
Includes §7.M.S sub-blocks specifying negative controls across multiple API surfaces.
Missed
Passed
case-09 · gemini-3.6-flash · 8/28/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md554 lines14 files
Designing Distributed-System Tests
The default for testing distributed and stateful systems — write a few
integration tests and call it done — finds a small fraction of the bugs
that actually break these systems in production. This skill enforces an
opinionated workflow: scope the change, generate failure-mode hypotheses
that cover the categories the literature says matter most, pick
techniques from a curated catalog, and emit a structured plan file that
the executing-distributed-system-tests skill (or a human) can run.
Plan modes
This skill produces two shapes of plan. Decide which one applies before
you start; the steps below branch on it.
Change-scoped — the default. Use when the caller names a commit,
PR, branch-diff, or feature. The plan covers what this change could
regress, scoped by its blast radius.
Project-wide — use when the caller asks for a "release-validation
plan", "stability plan for the whole system", "test plan to enough
coverage", "what should we be testing", or otherwise frames the
request without a specific change. The plan covers what the system
should be tested for, with an explicit inventory of existing tests
and a gap analysis driving the new-scenario list.
If the framing is ambiguous, ask once before starting — the modes
diverge enough that retrofitting one into the other wastes work.
Process
Follow these steps in order. Do not skip; the order matters because
later steps depend on artifacts the earlier steps produce.
1. Scope the system
Read the project's entry points: README, AGENTS.md or CLAUDE.md,
top-level docs/, any existing test-plan or runbook files. Note:
Tenancy / isolation model
Persistence model (what is durable, fsync contract)