Claude Skill

shenli/distributed-system-testing

探索用于分布式系统测试的AI代理技能,结合混沌工程与自动化,验证复杂系统的弹性和正确性。

概览

Stars205
Forks11
语言未知
最后更新2026-05-22
最近同步2026-06-21
前往 GitHub

仓库信息

拥有者shenli
仓库distributed-system-testing
完整名称shenli/distributed-system-testing
Repo ID1,241,000,028

安装这个 Skill

git clone https://github.com/shenli/distributed-system-testing.git \

Registry 信息

类型cursor_rule
质量分70/100
验证状态readme_parsed
最近验证2026-06-21
平台
ClaudeCodexCursor
能力
memoryterminalworkflowagent-skillsai-agentschaos-engineeringdistributed-systemstesting
识别文件
README.md

项目简介

一套专为分布式系统测试设计的AI代理技能集合,利用混沌工程和基于代理的自动化来验证系统的弹性和正确性。

英文描述

AI-agent skills for distributed-systems testing

要点

  • 专为分布式系统测试定制的AI代理技能
  • 集成混沌工程原则
  • 自动化弹性和正确性验证
  • 模块化技能设计,适应灵活测试场景
  • 开源且社区驱动开发

使用场景

  • 分布式数据库的弹性测试
  • 微服务中的故障注入与恢复验证
  • 云原生系统的自动化混沌实验
  • 网络分区下的正确性验证
  • 训练AI代理检测系统异常

README 摘要

# Distributed Systems Testing Skills **Two skills for AI coding agents that design and run claim-driven tests for distributed and stateful systems.** Together they produce a structured Markdown test plan and a findings report with 10-state verdicts and an explicit SUT / harness / checker / environment blame classification. A reviewer reads the two artifacts and decides whether to ship; nothing else has to be re-run. Works with Claude Code, Codex, Copilot CLI, Cursor, Gemini, or any agent that reads Markdown and runs shell. The skills are plain SKILL.md files. The agent executes them; the plan and findings report are the output. One skill designs the plan. The other runs it. A plan starts from the product's claims, generates hypotheses tied to those claims, and writes scenarios named after the claim each tries to falsify. For consistency-critical scenarios, each scenario also binds an abstract model (`register | queue | log | lock | lease | ledger | …`) to an operation-history schema, a named checker, and a nemesis with observable landing evidence. The plan ends with a coverage adequacy argument and a conservative confidence statement. ## Why 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: partial network partitions, non-deterministic concurrency, crash-recovery, upgrade/rollback, idempotency under replay, timing-sensitive ordering. These skills enforce an opinionated workflow that pulls from the field's hard-won knowledge: - **Claim-driven, not test-driven.** Start from what the product promises. Every scenario falsifies one claim under one fault. A test named after its claim is harder to weaken than one named after

话题

探索更多

数据来自 GitHub,同步时间:2026-06-21