القائمة
适用于规格草稿已完成需正式 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）；混合表述需重写。 |
通过 时已明确要求进入 规格真人确认