test-review

测试审查

先加载项目测试标准，再执行审计工作流，以审查测试质量并查找覆盖缺口。该流程会生成一份按优先级排列的缺口报告，而不是测试代码。

适用场景

• “审查模块 X 的测试”
• “审计这个组件的测试覆盖率”
• “这些测试质量如何？”
• “缺少哪些测试？”
• 编写新测试之前（先审计，再编写）
• 重大重构之后（验证测试是否仍覆盖契约）
• 准备将模块投入生产时

流程

此技能分为三个阶段。按顺序执行，不要跳过阶段 1——必须先加载标准，再审查任何测试代码。

共享审查基础设施。 测试标准和审计工作流参考文件位于 skills/agent-loops/references/，由使用相同契约执行逐提交测试覆盖率检查的 agent-loops 技能共享。两种技能都引用同一信息源，以避免标准发生偏差。

阶段 1：加载标准

阅读项目测试标准，以了解“良好”的测试应是什么样：

cat skills/agent-loops/references/testing-standards.md

此文件定义了：

• 需要标记的反模式（镜像测试、仅覆盖成功路径、过度使用模拟、断言过于简单）
• 必需的测试类别（契约、边界、失败模式、状态转换、集成）
• 单个测试的自检清单
• 特定语言的标准（Rust、TypeScript/React）
• 不同组件类型的覆盖率预期
• 命名约定

在阅读任何测试代码之前，请先熟记这些标准。 审计中的每项发现都必须引用此文件中的具体标准。不要自行杜撰标准，只使用此文件中定义的标准。

阶段 2：发现（Haiku Agent）

启动 Haiku 子 Agent 执行机械式发现工作——审计工作流中的步骤 1 和步骤 2。这样可以让主上下文专注于分析。

先阅读审计工作流，了解 Agent 需要执行的任务：

cat skills/agent-loops/references/audit-workflow.md

步骤 2a：确定工作范围

启动 Agent 之前，确定涉及多少个文件：

Glob tool: **/*.{py,rs,ts,tsx,js,jsx,go,rb} under [MODULE_PATH]
Glob tool: **/*.{test,spec}.* or **/test_*.* or **/tests/**  under [TEST_PATH]

统计源文件和测试文件。这将决定任务分配策略。

步骤 2b：选择任务分配策略

源文件数	策略	Agent 数量
≤ 15	单个 Agent — 由一个 Haiku 处理全部工作	1
16–60	按目录分配 — 每个顶层子目录（或逻辑分组）分配一个 Agent	2–4
60+	按文件分块分配 — 将文件列表拆分成大致相等的区块，每块约 15 个文件	最多 6 个

分配规则：

• 每个 Agent 获取一部分源文件进行清点（步骤 1）
• 每个 Agent 还会获取完整的测试文件列表（测试可能跨越源文件的边界）
• 每个 Agent 仅为分配给自己的源文件生成清单
• 尽可能遵循目录边界进行分组（将相关文件放在一起）

步骤 2c：并行启动 Agent

在同一条消息中启动所有 Haiku Agent，让它们并行运行。每个 Agent 接收相同的说明，但分配到不同的文件分区。

不要要求 Haiku Agent 进行分析、确定优先级或作出判断。 它们的任务是阅读代码并生成客观清单。分析将在阶段 3 中进行。

单个 Agent（≤ 15 个源文件）：

Task tool:
  subagent_type: Explore
  model: haiku
  prompt: |
    Read the audit workflow at skills/agent-loops/references/audit-workflow.md.
    Then execute Steps 1 and 2 for the module at [MODULE_PATH].

    Step 1 - Map the Public Contract:
    Read every source file in the module. List every public behavior it promises
    as plain-English statements (see audit-workflow.md for format and examples).

    Step 2 - Map Existing Test Coverage:
    Read every test file that covers this module. For each test, record what
    behavior it exercises and whether assertions are meaningful. Mark each
    behavior from Step 1 as:
    - Covered: at least one test verifies this with meaningful assertions
    - Shallow: a test touches this but doesn't properly verify it
    - Missing: no test exercises this behavior

    Return:
    1. Source files read (paths)
    2. Test files read (paths)
    3. Complete behavior list with coverage status markers
    4. For each Shallow entry, note what the test does and why it's insufficient

    Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.

多个 Agent（16 个或更多源文件）：

在同一条消息中启动所有 Agent。每个 Agent 获取一部分源文件，但会获取完整的测试文件列表。

# Agent 1 of N — launched in parallel with all other agents
Task tool:
  subagent_type: Explore
  model: haiku
  prompt: |
    Read the audit workflow at skills/agent-loops/references/audit-workflow.md.
    Then execute Steps 1 and 2 for the following SOURCE FILES ONLY:
    [LIST OF FILES IN THIS PARTITION]

    The test files that may cover these sources are at:
    [FULL TEST FILE LIST OR TEST DIRECTORY PATH]

    Step 1 - Map the Public Contract:
    Read ONLY the source files listed above. List every public behavior each
    promises as plain-English statements (see audit-workflow.md for format).

    Step 2 - Map Existing Test Coverage:
    Read the test files and identify which tests exercise behaviors from YOUR
    source files. Mark each behavior as:
    - Covered: at least one test verifies this with meaningful assertions
    - Shallow: a test touches this but doesn't properly verify it
    - Missing: no test exercises this behavior

    Return:
    1. Source files you read (paths)
    2. Test files you read (paths)
    3. Complete behavior list with coverage status markers
    4. For each Shallow entry, note what the test does and why it's insufficient

    Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.

# Agent 2 of N — same structure, different file partition
# ...
# Agent N of N

Step 2d：合并清单

所有 Agent 返回结果后，将其合并为一份统一清单：

1. 拼接所有行为列表（每个 Agent 负责不同的源文件，因此重叠应当很少）
2. 去重多个 Agent 的结果中重复出现的行为（不同分区中的源文件共享接口时可能会发生这种情况）
3. 合并重复项时优先采用更具体的状态：如果某个 Agent 将同一行为标为 Covered，而另一个标为 Shallow，则保留 Shallow（在 Phase 3 中调查差异）
4. 汇总所有 Agent 读取过的源文件和测试文件的完整列表

合并后的清单将直接用于 Phase 3，效果与由单个 Agent 生成完全相同。

Phase 3：分析与报告

使用合并后的 Haiku 清单，由你（主 Agent）执行更深入的分析工作——即审计工作流的 Step 3 和 Step 4：

• Step 3：对抗性分析——探查输入边界、错误处理、状态和集成接缝。根据审计工作流中的问题审视行为清单。你可能需要读取特定源文件来回答这些问题。
• Step 4：生成差距报告——根据 audit-workflow.md 中定义的标准分配 P0/P1/P2 优先级，引用 testing-standards.md 规则，并按指定格式生成完整报告。

对抗性分析和优先级分配需要判断力，因此只能由主 Agent 执行。不要将这些工作委派给子 Agent。

操作规则

1. 始终优先遵循标准。 打开任何测试文件之前，先阅读 testing-standards.md。如果上下文经过压缩，标准已不再载入，则重新阅读。

2. 报告问题，不要修复。 输出应为差距报告。除非用户明确要求实现已批准报告中的特定差距，否则不要编写测试代码。

3. 引用标准。 每项发现都必须指出其违反的 testing-standards.md 规则，或未满足的 audit-workflow.md 标准。没有引用的发现只是意见，而非审计结果。

4. 读取源代码，而不只是测试。 审计需要读取模块源代码，以梳理公共契约（audit-workflow.md 的 Step 1）。不要孤立地审计测试——审计的关键是找出代码行为与测试验证内容之间的差距。

5. 不要凭空捏造差距。 如果模块的测试覆盖充分，就如实说明。差距报告中设有“测试充分”部分，正是为此而设。

模式

完整审计（默认）

执行全部三个阶段，生成完整的差距报告。

适用于：“审计模块 X 的测试”“审查测试覆盖率”或准备投入生产。

快速审查

加载 testing-standards.md，然后仅依据反模式和自检清单审查指定的测试文件。跳过 Phase 2（Haiku 探查）和对抗性分析。

适用于：审查 PR 中的测试变更、抽查单个测试文件，或询问“这些测试可以吗？”

编写模式

先执行完整审计并提交差距报告，然后——仅在获得批准后——遵循 testing-standards.md 中的标准，为已批准的差距编写测试实现。

适用于：“审计并修复模块 X 的测试”或“编写缺失的测试”。

常见错误

• 跳过 testing-standards.md——未加载标准就审查测试，只会得到泛泛的反馈。标准针对具体项目制定，并明确表达了特定取向。
• 报告之前先编写测试——审计负责给出发现，由用户决定要实现哪些发现。不要抢先动手。
• 未读取源代码就审计测试——不了解代码行为，就无法发现覆盖缺失。
• 未经说明就判断严重程度——P0/P1/P2 的分配标准在 audit-workflow.md 中有明确定义。请使用这些标准，而不是凭直觉判断。