Designing Distributed System Tests

Takes the claim-driven approach to distributed system testing and turns it into a structured plan. You feed it a PR, feature, or whole system, and it mines your docs and code for guarantees (linearizability, durability, tenant isolation, idempotency), then generates hypotheses that try to falsify those claims under faults. It knows the techniques that matter (Jepsen, deterministic simulation, chaos injection, property testing) and organizes scenarios by what could actually break in production: partition tolerance, crash recovery, noisy neighbors, upgrade safety. For project-wide plans it inventories existing tests and does gap analysis. The output is a Markdown file with hypothesis-driven scenarios you can hand off to the executing skill or run yourself. Honest take: this encodes the kind of paranoid, literature-informed testing discipline most teams skip because they don't know where to start.

GitHub stars: 217
last updated: May 22, 2026

View on GitHub

Install

$ npx -y skills add shenli/distributed-system-testing --skill designing-distributed-system-tests --agent claude-code

Installs into .claude/skills of the current project.

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.