1. 基本信息
| 项目 | 内容 |
|---|---|
| 名称 | test-guard（amElnagdy/guard-skills 仓库内子技能，该仓库共含 5 个“guard”系列质量闸技能） |
| 作者/维护者 | Ahmed Nagdy（GitHub 用户 amElnagdy，任职 OnTheGoSystems，GitHub 账号自 2014 年活跃，561 位关注者） |
| 来源链接 | https://github.com/amElnagdy/guard-skills/tree/master/skills/test-guard |
| 许可证 | MIT（GitHub API 确认） |
| GitHub Stars / Forks | 1,120 / 132（GitHub API，截至 2026-07-30；数字为整个仓库层面，非本子技能单独统计——见第 7 章） |
| 最新版本 | v1.0.0（仓库级标签，2026-06-07 首次发布；本子技能另有 2026-07-04 独立维护提交） |
| 安装方式 | Skills CLI 一条命令安装（见第 10 章） |
2. 功能介绍与亮点
test-guard 是一个针对“AI 编写测试代码”场景的第二轮质量闸——不负责写测试，而是在测试代码写完、提交或合并之前，对照九条通用规则逐条审查。核心问题意识：编码 agent 常常过度生成测试——mock 滥用、断言实现细节而非行为、几乎相同只改一个数值的重复测试、以及重新验证框架本身而非项目逻辑的测试——每一条在 diff 里都显得“很努力”，实际只增加维护负担、不增加真实缺陷捕获力。
九条规则覆盖：测行为不测实现、每个 mock 要有系统边界依据、同结构测试合并为参数化测试、每个测试要能回答“单独捕获了什么 bug”、生产事故复现测试永久保留、测试命名要读起来像需求、不为框架自身特性写测试、状态/值对象用真实实例不 mock、持久化逻辑测试要接真实测试库。每条附反例/正例，并按“必须修/应该修/绝不删/建议关注”分级。
主要亮点：
- 语言覆盖广：内置 pytest、PHPUnit/Pest、Jest/Vitest 三套语言专属参考，外加一份 LLM 应用测试专属规则（prompt 契约、可观测性埋点、agent 流程转换）
- 零依赖、零配置：纯 Markdown 规则文件，不调用外部工具、不需要 API Key，复制即用
- 同一系列还有 4 个姊妹质量闸技能（通用代码审查、文档审查、WordPress/WooCommerce 专项审查），风格与规则密度一致，出自同一作者
- 2026-07-04 有专门修复“规则编号错标、模式误计数”的维护提交，说明作者会真实回看修正规则文本
3. 适用场景
固定分类：工程效率与代码质量。
适合频繁“叫 agent 写测试”的开发者——尤其是发现 agent 生成的测试套件里全是 mock、断言内部调用参数、或测试数量很多但改一行代码照样全部通过的团队。典型受益人群：没有专职测试架构师把关 agent 产出的独立开发者与小团队，以及希望在合并前有一道自动化“测试质量闸”的团队。适用于 Python/pytest、PHP/PHPUnit/Pest（含 WordPress）、JavaScript/TypeScript/Jest/Vitest，以及调用 LLM API 的应用测试场景。
4. 跨 Agent 兼容性
- Claude Code：✅ 原生支持。仓库 README 明确给出
--agent claude-code安装示例，纯 Markdown 规则可直接复制进技能目录使用。 - Codex：✅ 原生支持。README 给出
--agent codex安装示例；test-guard 目录下另带agents/openai.yaml专属显示配置（展示名称、简介、默认调用提示词），表明作者针对该 agent 格式做过专门适配。 - OpenClaw / Hermes Agent：❓ 未验证——已抓取材料（README、SKILL.md、Skills CLI 文档）均未提及；SKILL.md 本身遵循通用 Agent Skills 规范，理论上可手动复制使用，但无直接证据。
5. 推荐理由
AI 编码 agent 写测试有一个几乎所有使用者都会撞上的通病：测试数量看着很多，深挖进去却发现大半是 mock 断言实现细节、或互相高度重复。test-guard 把这种模糊的“感觉不对劲”变成九条可操作、可判定的具体规则，每条都配反例/正例和判定问句（“这个测试单独捕获了什么其它测试捕获不到的 bug”），审查后直接给出按文件分组、按严重程度分级的结构化报告。零依赖、零配置，装上就能用，特别适合已经在高强度用 agent 写代码、但苦于测试质量无人把关的独立开发者与小团队。
6. 评分
| 维度 | 分数 | 说明 |
|---|---|---|
| 受欢迎程度 | 6 | 所属 amElnagdy/guard-skills 是合集仓库（5 个子技能共享），仓库整体 1,120 stars/132 forks 不能直接记给本子技能；本子技能有独立提交历史（2026-06-07 首次发布、2026-07-04 专项修复），且已在 Skills CLI 官方市场（skills.sh）登记，作者本人在 GitHub 上有 561 位关注者、账号自 2014 年活跃 |
| 可用性 | 9 | 一条 npx skills add 命令即可安装，支持按技能名或按 agent 单独安装；规则文档结构完整，每条规则都有违规模式与修复示例；额外附带 pytest/PHPUnit/Jest 三套语言专属参考与 LLM 应用测试专属规则；2026-07-04 有维护提交，零外部依赖、无需任何 API Key |
| 安全性 | 9 | 纯 Markdown 指令文件，不执行任何 shell 命令、不联网外发数据、不要求任何凭据；全文精读未见可疑指令或混淆内容；作者系 OnTheGoSystems 在职工程师，GitHub 账号自 2014 年活跃、561 位关注者，身份可查证；License（MIT）明确 |
综合评分：8.0（三项均值）
安全检查清单： ① shell 命令：否，全程仅输出审查建议文本 ② 联网外发：否 ③ API key/凭据：不需要 ④ 可疑指令迹象：全文精读未发现 ⑤ 作者/组织信誉：Ahmed Nagdy，OnTheGoSystems 在职工程师，GitHub 账号自 2014 年活跃 ⑥ License：MIT，明确 ⑦ 最近维护：2026-07-04（子技能专属修复提交）
7. 跟同类 Skills 相比的优势
| 对比对象 | 定位 | 与本技能的差异 |
|---|---|---|
| carson-sweet/sweetclaude（code-tdd 子技能） | SweetClaude 全生命周期开发框架内置的 TDD 流程组件，user-invocable: false，需要项目预先跑通该框架的完整状态机（.sweetclaude/state/phase.yaml）才能触发，由上层技能间接调用 |
仅 6 stars，是大型 opinionated 框架的内部零件而非独立可调用技能，无法脱离 SweetClaude 体系单独使用；test-guard 是独立、可直接对着任意项目现有测试 diff 调用的轻量审查通道，不需要接入任何外部状态系统 |
| bjgreenberg/senior-engineering-partner | 单体技能，把严格代码审查者、结对编程、调试、导师角色合一，覆盖 Python/Bash/Apps Script/JS，走 spec→plan→TDD→verify 全流程 | 定位是“全程陪练”的综合工程伙伴，测试只是其 TDD 阶段的一部分而非专项深挖；test-guard 只做一件事——测试代码质量审查，九条规则聚焦 mock 边界、断言粒度、命名规范等测试特有失败模式，审查颗粒度明显更细 |
8. 用户评价
该技能目前在第三方平台尚无具名用户评价。
9. 其他补充
test-guard 是 amElnagdy/guard-skills 仓库内 5 个“guard”系列质量闸技能之一，同仓库还含 clean-code-guard（通用代码审查）、docs-guard（文档准确性审查）、wp-guard/woo-guard（WordPress/WooCommerce 专项审查），可按需单独安装或整包安装。
10. 安装使用方式
Skills CLI（推荐，支持 Claude Code / Codex / Cursor / OpenCode 等）：
npx skills add amElnagdy/guard-skills --skill test-guard指定 agent 安装：
npx skills add amElnagdy/guard-skills --skill test-guard --agent claude-code
npx skills add amElnagdy/guard-skills --skill test-guard --agent codex安装后无需重启，在对话中直接说“审查一下刚写的测试”或显式调用 $test-guard 即可触发。
手动安装：把仓库 skills/test-guard/ 目录（含 SKILL.md 及 references/ 下三份语言参考）复制进所用 agent 的技能目录。
更新：npx skills update test-guard
11. 注意事项
- 不负责运行测试，只做静态审查——执行测试仍需项目自身的测试运行器。
- 不检查代码风格（那是 linter 的职责），也不负责决定“该测什么”，只负责审查“怎么测的”。
- 默认不翻查未改动文件里的既有测试问题，除非用户明确要求做全量审计。
- 目前仅 Claude Code、Codex 有明确验证的适配证据，其余 Agent 生态需自行验证。