القائمة
适用于实现完成后判断测试质量、code review 前的测试评审、用户显式要求评审测试的场景。可吸收已有缺陷模式记录或项目级风险清单作为风险输入，但不以其存在为前置。不适用于写/修测试（→ hf-test-driven-dev）、评审代码（→ hf-code-review）、阶段不清（→ hf-workflow-router）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when starting an existing-code bug audit on a repository or large directory tree. First detects project language + architecture (e.g. C/C++ embedded SOA, Python web service, frontend SPA), proposes a tailored review checklist (scenario-specific bug categories) for user confirmation, then slices the codebase into modules within a per-module token budget. Produces plan.json with profile + review_checklist + modules that downstream audit-reviewer consumes module-by-module. Not for PR diff review (use hf-code-review) or for actually finding bugs (use audit-reviewer).
Use as the FINAL stage of the code-audit pipeline. Reads confirmed.json (output of audit-verifier) and renders a self-contained single-file HTML report (always) and optionally an Excel workbook. The HTML contains summary stats by severity/category/module, filterable finding cards with code snippets and audit trails (reviewer + verifier). Not for emitting findings (use audit-reviewer) or verifying findings (use audit-verifier).
Use when scanning an existing-code module for bugs and emitting finding drafts. Reads source files within one module from the plan.json produced by audit-planner, walks files line-by-line, emits findings/<module>.json with file path, line numbers, category, severity, confidence, code snippet evidence, and reasoning. The set of allowed finding categories is sourced from plan.json's review_checklist (scenario preset such as c-cpp-embedded-soa / python-web-service / frontend-spa / generic) rather than a fixed taxonomy — keep findings scoped to the user-confirmed checklist. This is the PRIMARY (first-stage) reviewer in the two-agent confirmation pipeline; downstream audit-verifier independently confirms each finding. Not for PR diff review (use hf-code-review) or for verifying findings (use audit-verifier).
Use as the SECOND-STAGE independent confirmer in the two-agent code-audit pipeline. Reads finding drafts produced by audit-reviewer and independently re-examines each one against the actual source code, writes verifications/<module>.json with status (confirmed/rejected/upgrade/downgrade/needs_more_evidence), reason, and evidence_check. Operates with FRESH context — does not see reviewer's internal reasoning beyond what is recorded in the finding's description+evidence fields, to enable independent judgement. Not for emitting new findings (use audit-reviewer) or rendering the report (use audit-reporter).
Use when hf-test-driven-dev finishes GREEN on a frontend-touching active task whose spec declares a UI surface, and fresh browser runtime evidence (screenshot / console log / network trace) is required for downstream gates. Not for issuing verdicts (gates do that), not for replacing hf-test-review's test-quality review, not for backend-only tasks.
适用于 test review 通过后评审代码质量、用户要求 code review 的场景。不适用于评审测试（→ hf-test-review）、写/修代码（→ hf-test-driven-dev）、阶段不清（→ hf-workflow-router）。
| name | hf-test-review |
| description | 适用于实现完成后判断测试质量、code review 前的测试评审、用户显式要求评审测试的场景。可吸收已有缺陷模式记录或项目级风险清单作为风险输入，但不以其存在为前置。不适用于写/修测试（→ hf-test-driven-dev）、评审代码（→ hf-code-review）、阶段不清（→ hf-workflow-router）。 |
评审测试资产，判断 fail-first、行为覆盖和风险覆盖是否足以支持 hf-code-review。可吸收项目已有的缺陷模式记录或风险清单作为风险输入，但不以其存在为前置。
本 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 |
适用：
不适用 → 改用：
hf-test-driven-devhf-code-reviewhf-workflow-routerDirect invoke 信号："review 测试"、"test review"、"帮我审一下测试质量"。
读实现交接块、新增/修改测试、项目已声明的缺陷模式记录或风险清单（若项目有维护，按项目约定路径读取，不存在则跳过）、项目级测试约定、规格/设计片段（默认 features/<active>/spec.md / design.md）、feature progress.md（默认 features/<active>/progress.md）。
检查：是否存在稳定实现交接块、可定位测试资产、route/stage/profile 与上游 evidence 是否一致。
reroute_via_router=truehf-test-driven-dev6 个维度 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.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 做可信判断？
通过：所有维度 >= 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=trueFindings 带 severity（critical/important/minor）和分类（USER-INPUT/LLM-FIXABLE）。
保存到 项目声明的 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。
完成时产出：
features/<active>/reviews/test-review-task-NNN.md）record_path、next_action_or_recommended_skillreroute_via_router=true| 文件 | 用途 |
|---|---|
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 返回契约 |
| 借口 | 反驳 / 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。 |