| name | hf-test-review |
| description | 适用于实现完成后判断测试质量、code review 前的测试评审、用户显式要求评审测试的场景。可吸收已有缺陷模式记录或项目级风险清单作为风险输入，但不以其存在为前置。不适用于写/修测试（→ hf-test-driven-dev）、评审代码（→ hf-code-review）、阶段不清（→ hf-workflow-router）。 |
HF Test Review
评审测试资产，判断 fail-first、行为覆盖和风险覆盖是否足以支持 hf-code-review。可吸收项目已有的缺陷模式记录或风险清单作为风险输入，但不以其存在为前置。
Methodology
本 skill 融合以下已验证方法。每个方法在 Workflow 中有对应的落地步骤。
| 方法 | 核心原则 | 来源 | 落地步骤 |
|---|
| Fail-First Validation (TDD Quality Gate) | 验证测试确实先失败再通过，防止"天生绿色"的无效测试 | 项目化实践（TDD 质量门禁） | 步骤 2 — 评分；步骤 3.1 — fail-first 审查 |
| Coverage Categories (Crispin/Gregory) | 从行为覆盖、风险覆盖、边界覆盖等多维度评估测试质量 | Crispin & Gregory, "Agile Testing", 2009 | 步骤 2 — 评分；步骤 3.2/3.3 — 行为/风险覆盖 |
| Risk-Based Testing | 测试覆盖应回应项目缺陷模式记录、风险清单或上游 review/hotfix 历史中识别出的风险 | 项目化实践（HF 质量链约定） | 步骤 3.3 — 风险覆盖 |
| Structured Walkthrough | 多维度评分量化判断，防止印象式评审 | 项目化实践（评审通用方法） | 步骤 2 — 多维评分；步骤 4 — verdict |
When to Use
适用：
- 实现完成后判断测试质量
- code review 前的测试评审
- 用户显式要求 test review
不适用 → 改用：
- 写/修测试 →
hf-test-driven-dev
- 评审代码 →
hf-code-review
- 阶段不清 →
hf-workflow-router
Direct invoke 信号："review 测试"、"test review"、"帮我审一下测试质量"。
Hard Gates
- test review 通过前不得进入 code review
- 输入工件不足不得开始评审
- reviewer 不修测试、不继续实现
Workflow
1. 建立证据基线
读实现交接块、新增/修改测试、项目已声明的缺陷模式记录或风险清单（若项目有维护，按项目约定路径读取，不存在则跳过）、项目级测试约定、规格/设计片段（默认 features/<active>/spec.md / design.md）、feature progress.md（默认 features/<active>/progress.md）。
1.5 Precheck：能否合法进入 review
检查：是否存在稳定实现交接块、可定位测试资产、route/stage/profile 与上游 evidence 是否一致。
- route/stage/证据冲突 → 写最小 blocked precheck record，
reroute_via_router=true
- route 明确但缺稳定交接块或关键测试资产 → 写最小 blocked record，下一步
hf-test-driven-dev
- precheck 通过 → 继续正式审查
2. 多维评分与挑战式审查
6 个维度 0-10 评分：fail-first 有效性、行为/验收映射、风险覆盖、测试设计质量、新鲜证据完整性、下游就绪度。任一关键维度 < 6 不得通过。
按 references/review-checklist.md 做正式审查。
每条 finding 必须带：
severity（critical / important / minor）classification（USER-INPUT / LLM-FIXABLE）rule_id（如 TT1、TT5、TA2）
默认分类：
USER-INPUT：验收阈值本身未定、外部质量门尚未拍板、风险优先级冲突仍需真人裁决LLM-FIXABLE：缺少有效 RED/GREEN 证据、未覆盖关键边界、Acceptance 映射缺失、mock 误用、test seed 过弱
3. 正式 checklist 审查
3.1 Fail-first & RED/GREEN：RED 是否对应当前行为缺口？GREEN 是否来自本次实现？
3.2 行为价值与验收映射：测试是否覆盖任务关键行为？是否映射回验收标准？
3.3 风险覆盖与边界：是否覆盖已识别的风险（来自项目缺陷模式记录、风险清单或上游 review/hotfix 历史）？边界/null/错误路径？
3.4 测试设计质量：mock 是否限定在真正边界？测试是否独立可重复？是否存在 provider mock、child component overmock、mock fetch、fixture contract drift 等掩盖真实 App 装配 / API 契约 / browser runtime 的风险？
3.5 下游就绪度：测试质量是否足以让 code-review 做可信判断？
4. 形成 verdict
通过：所有维度 >= 6，测试足以支持 code review → next_action_or_recommended_skill=hf-code-review，needs_human_confirmation=false需修改：findings 可 1-2 轮定向修订 → next_action_or_recommended_skill=hf-test-driven-dev，needs_human_confirmation=false阻塞：测试过于薄弱/核心行为未覆盖/findings 无法定向回修 → next_action_or_recommended_skill=hf-test-driven-dev，needs_human_confirmation=false；若问题本质是 stage/route/profile/上游证据冲突 → next_action_or_recommended_skill=hf-workflow-router，reroute_via_router=true
Findings 带 severity（critical/important/minor）和分类（USER-INPUT/LLM-FIXABLE）。
5. 写 review 记录
保存到 项目声明的 review record 路径；若无项目覆写，默认使用 features/<active>/reviews/test-review-task-NNN.md。若项目无专用格式，默认使用 references/review-record-template.md。
回传结构化摘要给父会话时，遵循当前 skill pack 中 hf-workflow-router/references/reviewer-return-contract.md：next_action_or_recommended_skill 只写一个 canonical 值；workflow blocker 必须显式写 reroute_via_router=true。
Output Contract
完成时产出：
- Review 记录（保存到 项目声明的 review record 路径；若无项目覆写，默认使用
features/<active>/reviews/test-review-task-NNN.md）
- 结构化摘要含
record_path、next_action_or_recommended_skill
- workflow blocker 时显式写明
reroute_via_router=true
Reference Guide
| 文件 | 用途 |
|---|
references/review-checklist.md | test review checklist 与 rule IDs |
references/review-record-template.md | test review 记录模板与结构化返回契约 |
hf-workflow-router/references/reviewer-return-contract.md | 当前 skill pack 共享的 reviewer 返回契约 |
Red Flags
- 不读 handoff 就审测试
- "测试文件存在"等同于"测试充分"
- 忽略无效 RED/GREEN
- 忽略已识别的风险（项目缺陷模式 / 风险清单 / hotfix 历史）
- 评审中修测试
- 返回多个候选下一步
Common Rationalizations
| 借口 | 反驳 / Hard rule |
|---|
| "测试设计写得简单但跑通了，pass。" | Hard Gates: 测试设计必须显式声明 SUT Form（naive / pattern: / emergent）；缺位 → finding。 |
| "缺反向 / 边界 case 但正向跑过即可。" | Hard Gates: 反向 / 边界 / "看似正确实则错"覆盖是 rubric 必查项；缺位 → finding。 |
| "我读 SKILL.md 时没看 testing-anti-patterns，直接评。" | Workflow stop rule: 必须先读 references/testing-anti-patterns.md 再下 verdict。 |
| "mock 范围有点大但能跑。" | Hard Gates: mock 必须限定在真正边界（外部 IO / 时间 / 随机源），跨边界 mock → finding。 |
| "UI provider / fetch 都 mock 了，所以页面测试更稳定。" | Hard Gates: provider / HTTP client mock 只能作为 lower-tier evidence；若当前任务触碰 App 装配、API client 或浏览器运行面，必须另有真实 provider / contract / browser runtime 证据。 |
| "happy-dom 下过了，等同于 Chrome / Edge 没问题。" | Hard Gates: simulated DOM 不能写成真实浏览器证据；真实浏览器结论必须来自 hf-browser-testing 或项目声明的等价 runtime evidence。 |
Verification
