القائمة
适用于设计草稿已完成需要正式 review verdict、或被指定为 reviewer subagent 执行设计评审的场景。不适用于需继续写或修设计（→ hf-design）、需拆任务或编码（→ hf-tasks）、阶段不清或证据冲突（→ 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-design-review |
| description | 适用于设计草稿已完成需要正式 review verdict、或被指定为 reviewer subagent 执行设计评审的场景。不适用于需继续写或修设计（→ hf-design）、需拆任务或编码（→ hf-tasks）、阶段不清或证据冲突（→ hf-workflow-router）。 |
评审设计文档，判断它是否可以提交给 approval step。核心职责是防止过早拆解任务——确保设计真正锚定规格、决策站得住、接口边界清楚到足以进入任务规划。
职责边界：本 skill 只评审 架构 / 模块 / API 契约 / 数据模型 / 后端 NFR。若规格声明 UI surface 且 hf-ui-design 被激活，hf-ui-review 会作为 design stage 的并行 review peer 独立评审 IA / 交互 / 视觉 / 前端 a11y 等 UI 维度。两条 review 均通过后，父会话才发起联合 设计真人确认；任一未过，对应起草 skill 回修，另一条可继续其稳定部分。不得跨权评审 hf-ui-design 的职责范围；发现 peer 交接块不一致时，只在 findings 中标注，不代位评审。
本 skill 融合以下已验证方法：
使用：
hf-design 已完成设计草稿，需要正式 review verdict不使用：
hf-designhf-workflow-router直接调用信号："review 这份设计"、"设计评审"、"帮我看一下这个设计"。
前提条件：存在当前设计草稿、已批准规格、项目相关约定（若项目已声明）。缺设计草稿 → hf-design；缺已批准规格或阶段不清 → hf-workflow-router。
读取：已批准规格（默认 features/<active>/spec.md）、被评审设计文档（默认 features/<active>/design.md）、项目级评审约定（若项目已声明）、feature progress.md（默认 features/<active>/progress.md）当前状态、最少必要技术上下文。
产出：review 记录正文 + 结构化 reviewer 返回摘要。
评审记录落盘由 reviewer 负责；approval step 和主链推进由父会话负责。
hf-tasks读取并固定证据来源：已批准规格（默认 features/<active>/spec.md）、当前设计文档（默认 features/<active>/design.md）、项目约定、feature progress.md（默认 features/<active>/progress.md）状态、必要技术上下文。
不要只根据会话记忆或零散聊天内容判断"已批准"或"设计已经讲清楚"。
检查：是否存在稳定可定位的设计草稿、已批准规格是否可回读、route/stage/profile 与 approval evidence 是否一致。
reroute_via_router=truehf-design对 6 个维度做内部评分（0-10）：需求覆盖与追溯、架构一致性、决策质量、约束与 NFR 适配、接口与任务规划准备度、测试准备度与隐藏假设。
评分辅助区分：轻微缺口 vs 需修改 vs 阻塞。按 references/review-checklist.md 逐项审查。
每条 finding 必须带：
severity（critical / important / minor）classification（USER-INPUT / LLM-FIXABLE）rule_id（如 D3、D5、A2）默认分类：
USER-INPUT：缺失外部阈值、未确认业务裁决、规格未批准却引入关键新增能力、核心 trade-off 仍需真人拍板LLM-FIXABLE：缺少方案对比、接口边界说明不足、任务规划准备度表达不清、测试策略未显式写出、隐藏假设未整理成文判定规则（详见 references/review-record-template.md）：
severity：critical（阻塞任务规划）> important（应修复）> minor（建议改进）。
按 references/review-record-template.md 写评审记录，并返回结构化 JSON 给父会话。
下一步映射：
通过 → 设计真人确认（needs_human_confirmation=true）需修改 → hf-design阻塞（设计内容） → hf-design阻塞（需求漂移/规格冲突） → hf-workflow-router（reroute_via_router=true）按需加载详细参考内容：
| 主题 | Reference | 加载时机 |
|---|---|---|
| 评审检查清单 | references/review-checklist.md | 执行 Step 2 多维审查时 |
| 评审记录模板 | references/review-record-template.md | 执行 Step 4 写评审记录时 |
hf-tasks（跳过 approval step）| 借口 | 反驳 / Hard rule |
|---|---|
| "Bounded Context 边界稍模糊但不影响实现。" | Hard Gates: DDD 战略边界含糊会在实现时反弹为模块边界争议；缺位 → finding。 |
| "ADR 我可以替作者补。" | Hard Gates (soul.md): 评审者不能补作者的工件；缺 ADR → finding，由作者回修。 |
| "STRIDE 没做但风险不大。" | Hard Gates: 缺 STRIDE → finding；不能由 reviewer 替评估为"风险不大"。 |
| "verdict pass，回头实现时再发现问题再说。" | Verification: design verdict 是后续 hf-tasks / hf-test-driven-dev 的 precondition；草率 pass 会回流大量返工。 |
完成条件：
next_action_or_recommended_skill通过，已明确要求进入 设计真人确认