メニュー
适用于规格草稿已完成需正式 review verdict、reviewer subagent 被派发执行规格评审的场景。不适用于缺规格草稿或只需继续写（→ hf-specify）、阶段不清或证据冲突（→ hf-workflow-router）、已有已批准规格需设计评审（→ hf-design-review）。
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-spec-review |
| description | 适用于规格草稿已完成需正式 review verdict、reviewer subagent 被派发执行规格评审的场景。不适用于缺规格草稿或只需继续写（→ hf-specify）、阶段不清或证据冲突（→ hf-workflow-router）、已有已批准规格需设计评审（→ hf-design-review）。 |
评审需求规格，判断范围清晰度、需求可测性、验收标准、success criteria、assumptions 与开放问题闭合度，以及进入 approval step 的准备度。本 skill 是需求规格冻结门禁，目标是把规格准备到可交给 approval step 作为 hf-design 候选已批准输入的状态。不替代 hf-specify（写规格）或 hf-design（做设计）。
本 skill 融合以下已验证方法：
适用：
hf-specify 已完成规格草稿，需正式 review verdict不适用：缺规格草稿或只需继续写 → hf-specify；阶段不清/证据冲突 → hf-workflow-router；已有已批准规格、当前需要设计评审 → hf-design-review。
前提确认：存在稳定规格草稿（默认 features/<active>/spec.md）、能读取 项目约定和 feature progress.md（默认 features/<active>/progress.md）、请求确实是评审。若 route/stage/profile/证据冲突 → 优先回 router。
hf-design读取并固定：当前规格（默认 features/<active>/spec.md）、deferred backlog（若存在，默认 features/<active>/spec-deferred.md）、项目约定、feature progress.md（默认 features/<active>/progress.md）、少量上下文用于确认状态和锚点。不只根据聊天记忆判断。
检查：是否存在稳定可定位的规格草稿、route/stage/profile 是否已明确、上游证据是否一致。
reroute_via_router=truehf-specify先判断项目是否通过 项目声明了骨架/字段/优先级体系，当前规格是否遵循。只要语义可回读，不强迫文档长得和默认模板一模一样。
详细规则：references/spec-review-rubric.md
核心需求可回指来源？模糊词已量化？验收标准可判断？需求无冲突/重复？无缺失 Priority/Source？
模糊词、复合需求、设计泄漏、无主体被动表达、关键需求中待确认/占位值、缺少负路径/边界/权限差异。
核心 FR/NFR 具备 ID/Statement/Acceptance/Priority/Source？当前轮目标与 success criteria 是否具体可判断？范围内外闭合？阻塞性开放问题为空？assumptions 是否显式且失效影响可回读？deferred requirements 已显式处理？
命中 GS1-GS6 的 oversized requirements？当前轮和后续增量混写？findings 足够具体可支持定向回修？
每条 finding 带 severity（critical/important/minor）、classification（USER-INPUT/LLM-FIXABLE）、rule_id（如 Q2、A3、C1、GS1）。
分类：缺业务事实/外部决策/性能阈值/优先级冲突 → USER-INPUT；缺 wording/拆分/章节/重复整理/设计泄漏改写 → LLM-FIXABLE。无法在不新增事实前提下修复的不能标 LLM-FIXABLE。
severity：critical（阻塞设计）→ important（应批准前修复）→ minor（建议改进）。
| 条件 | verdict | 下一步 |
|---|---|---|
| 范围清晰、核心需求可验收、无阻塞 USER-INPUT、足以成为设计稳定输入 | 通过 | 规格真人确认 |
| 有用但不完整，findings 可 1-2 轮定向修订 | 需修改 | hf-specify |
| 过于模糊/核心范围未定/findings 无法定向回修 | 阻塞(内容) | hf-specify |
| route/stage/证据冲突 | 阻塞(workflow) | hf-workflow-router |
按 references/review-record-template.md 的结构写记录并回传父会话。
交互约束：
reroute_via_router=true 时只说明 workflow blockerhf-design（跳过 approval step）| 文件 | 用途 |
|---|---|
references/spec-review-rubric.md | 正式审查 rubric（Q/A/C/G 四组） |
references/review-record-template.md | 记录结构、JSON 格式、返回规则、状态同步 |
| 借口 | 反驳 / Hard rule |
|---|---|
| "EARS / BDD 写得不漂亮但意思到了，pass。" | Hard Gates: rubric 上 acceptance criteria 必须以 EARS / BDD 形式落地，"意思到了"不是合规结论。 |
| "我顺便修一下 spec 里的笔误。" | Hard Gates (soul.md): 评审者不能编辑被审对象；笔误回写为 finding。 |
| "ISO 25010 / QAS 不是每个 feature 都需要。" | Workflow stop rule: NFR 缺位 → finding；可由作者声明"无 NFR 影响"并落到 spec，但不能省略评估。 |
| "verdict 我写 pass with comments。" | Hard Gates: verdict 唯一（pass / fail / fail-with-blocking-finding）；混合表述需重写。 |
通过 时已明确要求进入 规格真人确认