메뉴
适用于实现完成后判断测试质量、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。 |