Executing Distributed System Tests

Uruchamia zaprojektowany plan testów systemów rozproszonych, oceniając każde uruchomienie w 10-stanowej taksonomii werdyktów

Autor: shenli · shenli/distributed-system-testing

Działa po konfiguracji ★ 8.0/10

Executing Distributed System Tests — Uruchamia zaprojektowany plan testów systemów rozproszonych, oceniając każde uruchomienie w 10-stanowej taksonomii werdyktów

Co robi ten skill

Wykonuje wcześniej zaprojektowany plan testów systemów rozproszonych na rzeczywistym lub symulowanym klastrze: odkrywa istniejący zestaw narzędzi testowych SUT, steruje obciążeniem i wstrzykiwaniem błędów, przechwytuje dowody nemesis-landing dla każdego scenariusza i przypisuje jeden z dziesięciu stanów werdyktu z audytami green-but-broken i weak-oracle przed jakimkolwiek PASS. Uruchamia się na "execute the plan", "reproduce a distributed bug", "run stability/chaos tests", "validate a release end-to-end" lub gdy plik planu istnieje pod docs/testing-plans/. Dla scenariuszy boundary i fairness ocenia każdą powierzchnię oddzielnie i stosuje regułę obniżania, aby nieprzetestowana powierzchnia nie mogła zostać włączona do pomyślnego scenariusza.

Raport z testu

Pobrano SKILL.md via GitHub API; frontmatter parsował (name+description), a 3 referencyjne pliki zwróciły HTTP 200 (verdict-taxonomy.md, green-but-broken-red-flags.md, findings-report-template.md). Brak hardcoded paths lub security smells; dostarcza prawidłowe plugin.json/marketplace.json. Pełna ścieżka wykonania (driving fault injection against a live cluster) wymaga Docker + distributed SUT + zaprojektowanego pliku planu, którego nie mogłem dostarczyć, więc zmierzyłem charakterystyczny wycinek werdyktu/dyscypliny raportowania umiejętności: biorąc pod uwagę scenariusz boundary z 4 powierzchniami, gdzie 2 przeszły, a 2 nigdy nie zostały osiągnięte, mój baseline nazwał to "PASS (with caveats), nothing blocks shipping", podczas gdy przestrzeganie reguły obniżania dla każdej powierzchni z treści wymusiło "PARTIAL-surface, NOT a pass, should NOT ship" plus tabelę surface-coverage — dokładnie taką awarię złożonej powierzchni, której umiejętność twierdzi, że zapobiega (exec_baseline.md vs exec_skill.md).

Testowano: 2026-07-31 · Claude Code 2.x (agent harness)

Instalacja

git clone --depth 1 https://github.com/shenli/distributed-system-testing.git /tmp/executing-distributed-system-tests-src
mkdir -p ~/.claude/skills
cp -R /tmp/executing-distributed-system-tests-src/skills/executing-distributed-system-tests ~/.claude/skills/executing-distributed-system-tests
# Plugin-marketplace alternative: /plugin marketplace add shenli/distributed-system-testing  then install the 'distributed-testing-skills' plugin (installs both design + execute skills)
# To ACTUALLY RUN a plan end-to-end you additionally need, none of which the skill bundles:
#   - a plan file produced by the paired 'designing-distributed-system-tests' skill (the skill halts if oracles/budget tiers are missing)
#   - a distributed system-under-test repo to run against
#   - container + fault-injection tooling: docker/podman + compose, iptables/tc/netem, optionally toxiproxy/libfaketime

Komendy i przykładowe prompty

/executing-distributed-system-testsUruchamia zaprojektowany plan testów systemów rozproszonych, oceniając każde uruchomienie w 10-stanowej taksonomii werdyktów

Skille uruchamiają się na zwykłe polecenia — bez komend do zapamiętania. Po instalacji aktywują go prompty takie jak te (po angielsku):

Execute the test plan against the staging cluster
Reproduce this distributed bug with chaos testing
Run tenant isolation tests before this release

Pełny raport →