| name | hf-tasks-review |
| description | 适用于任务计划草稿需正式 review verdict、任务计划被退回需复审、或用户显式要求评审任务计划的场景。不适用于写/修任务计划（→ hf-tasks）、阶段不清（→ hf-workflow-router）。 |
HF Tasks Review
评审任务计划，判断任务是否可执行、可验证、正确排序、忠实覆盖已批准规格/设计。确保计划能支撑 router 稳定重选下一任务。
关键区别：通过时设 needs_human_confirmation=true（"任务真人确认" approval step），任务计划获批后才能进入实现。
Methodology
本 skill 融合以下已验证方法。每个方法在 Workflow 中有对应的落地步骤。
| 方法 | 核心原则 | 来源 | 落地步骤 |
|---|
| INVEST Validation | 检查每个任务是否满足 Independent/Negotiable/Valuable/Estimable/Small/Testable | Bill Wake, 2003；敏捷用户故事实践 | 步骤 2 — 多维评分；步骤 3.1 — 可执行性 |
| Dependency Graph Validation | 校验任务间依赖关系的正确性和无环性 | 项目化实践（任务计划评审通用方法） | 步骤 2 — 多维评分；步骤 3.3 — 依赖/顺序 |
| Traceability Matrix | 检查任务是否忠实覆盖规格/设计的每一项关键决策 | ISO/IEC/IEEE 29148 需求追溯实践 | 步骤 2 — 多维评分；步骤 3.4 — 追溯覆盖 |
| Structured Walkthrough | 多维度评分量化判断，任一关键维度低于阈值不得通过 | 项目化实践（评审通用方法） | 步骤 2 — 多维评分；步骤 4 — verdict |
When to Use
适用：
- 任务计划草稿需正式 review verdict
hf-tasks 返回 需修改 或 阻塞，需复审修订后的计划- 用户显式要求 review tasks plan
不适用 → 改用：
- 写/修任务计划 →
hf-tasks
- 阶段不清 →
hf-workflow-router
- 评审规格/设计 → 对应 review skill
Direct invoke 信号："review 任务计划"、"tasks review"、"帮我审一下这个计划"。
Hard Gates
- tasks review 通过并完成 approval step 前，不得进入
hf-test-driven-dev
- 输入工件不足不得开始
- reviewer 不替用户决定优先级或拆分方案
Workflow
1. 建立证据基线
读任务计划、已批准规格、已批准设计（默认 features/<active>/tasks.md / spec.md / design.md）、项目级约定、feature progress.md（默认 features/<active>/progress.md）。
1.5 Precheck：能否合法进入 review
检查：是否存在稳定可定位的任务计划、上游规格 / 设计 approval evidence 是否可回读、route/stage/profile 是否一致。
- route/stage/证据冲突 → 写最小 blocked precheck record，
reroute_via_router=true
- route 明确但缺稳定任务计划 → 写最小 blocked record，下一步
hf-tasks
- precheck 通过 → 继续正式审查
2. 多维评分与挑战式审查
双层评分（v0.6 起）：
(a) 既有 6 维 0-10 评分（保留向后兼容）：任务可执行性、任务合同完整性（含 UI Implementation Contract 承接）、验证与测试设计种子（含 runtime / UI conformance evidence tier）、依赖/顺序正确性、追溯覆盖度、router 重选就绪度。任一关键维度 < 6 不得通过。
(b) Momus 4 维 boolean cliff（v0.6 新增，与 N=3 rewrite loop 配套）：按 references/momus-rubric.md 跑 4 维（Clarity 100% / Verification 90% / Context 80% / Big Picture 100%）+ 1 个 Zero-tolerance 行（0% critical red flag）。任一维不达阈值即 verdict: rejected-rewrite。
按 references/review-checklist.md 做正式 6 维审查；按 references/momus-rubric.md 做 4 维 boolean cliff 评分。两层均通过才算 通过。
每条 finding 必须带：
severity（critical / important / minor）classification（USER-INPUT / LLM-FIXABLE）rule_id（如 TR2、TR5、TA3）
默认分类：
USER-INPUT：优先级冲突、上游规格/设计裁决仍未稳定、任务边界一旦重排就会改变已确认范围或发布顺序LLM-FIXABLE：缺少 Acceptance / Files / Verify / test seed、任务过大、依赖链缺口、queue projection 表达不清
3. 正式 checklist 审查
3.1 可执行性：每个任务是否冷启动可执行？是否有"实现某模块"式模糊任务？
3.2 任务合同完整性：关键任务是否显式具备 Acceptance、Files、Verify、完成条件？
3.3 验证与测试设计种子：测试设计种子是否足够支持后续 fail-first 实现？是否只写了“补测试”这类空话？UI / API / full-stack 任务是否声明了应收集的 runtime evidence tier（API contract、browser runtime、full-stack smoke 等）、启动/健康检查入口和允许降级条件？UI 任务是否声明了 UI conformance evidence（截图路由/viewport、DOM anchors、console/network、token/visual drift checks）？
3.4 依赖/顺序：依赖关系是否正确？关键路径是否合理？是否有循环依赖？
3.5 追溯覆盖：任务是否忠实覆盖规格/设计？是否有任务无法追溯到上游依据？
3.6 Router 重选就绪度：Current Active Task 选择规则是否唯一？queue projection 是否稳定？
4. 形成 verdict
verdict 取值（v0.6 起，与 N=3 rewrite loop 配套）：
通过：6 维 0-10 全 ≥ 6 + 4 维 boolean cliff（Clarity 100 / Verification 90 / Context 80 / Big Picture 100）全过 + 0 Zero-tolerance hit；可进入 approval step → next_action_or_recommended_skill=任务真人确认，needs_human_confirmation=truerejected-rewrite（v0.6 新名，旧名 需修改 仍兼容）：findings 可定向修订（包括 4 维 boolean cliff 任一不达标）→ next_action_or_recommended_skill=hf-tasks，needs_human_confirmation=false；标注当前 round 号到 review record阻塞：核心任务结构有问题 / findings 无法定向回修 / 第 4 次 rejected-rewrite 仍未通过（N=3 上限触发，与 hf-ultrawork fast lane escape #5 对齐）→ next_action_or_recommended_skill=hf-tasks，needs_human_confirmation=false；若问题本质是 route/stage/profile/上游证据冲突 → next_action_or_recommended_skill=hf-workflow-router，reroute_via_router=true
N=3 Rewrite Loop（references/momus-rubric.md "N=3 Rewrite Loop" 段详）：Round 1/2/3 都允许 rejected-rewrite；第 4 次仍未通过自动转 阻塞 升级架构师，让架构师在 (a) 接受 Round 3 / (b) 重写 design / (c) 降级 Acceptance / (d) deferred backlog 之间拍板。
5. 写 review 记录
保存到 项目声明的 review record 路径；若无项目覆写，默认使用 features/<active>/reviews/tasks-review-YYYY-MM-DD.md。若项目无专用格式，默认使用 references/review-record-template.md。
回传结构化摘要时遵循当前 skill pack 中 hf-workflow-router/references/reviewer-return-contract.md：next_action_or_recommended_skill 只写一个 canonical 值；通过 时设 needs_human_confirmation=true；workflow blocker 必须显式写 reroute_via_router=true。
Output Contract
完成时产出：
- Review 记录（保存到 项目声明的 review record 路径；若无项目覆写，默认使用
features/<active>/reviews/tasks-review-YYYY-MM-DD.md）
- 结构化摘要含
record_path、next_action_or_recommended_skill、needs_human_confirmation（通过时 = true）
- workflow blocker 时显式写明
reroute_via_router=true
Reference Guide
| 文件 | 用途 |
|---|
references/review-checklist.md | 正式 tasks review 6 维 0-10 checklist 与 rule IDs（既有） |
references/momus-rubric.md | v0.6 新增 4 维 boolean cliff rubric（Clarity 100 / Verification 90 / Context 80 / Big Picture 100 / 0 Zero-tolerance）+ N=3 rewrite loop + fast lane escape #5 对齐 |
references/review-record-template.md | tasks review 记录模板与结构化返回契约（含 v0.6 起 rejected-rewrite verdict + round 号字段） |
hf-workflow-router/references/reviewer-return-contract.md | 当前 skill pack 共享的 reviewer 返回契约 |
Red Flags
- 不读规格/设计就审任务
- "看起来差不多"就通过
- 忽略任务间依赖错误
- 返回多个候选下一步
Common Rationalizations
| 借口 | 反驳 / Hard rule |
|---|
| "INVEST 大体满足就 pass。" | Hard Gates: rubric 中 INVEST 6 维必须逐项判定，"大体满足"非合规结论。 |
| "DoD 没写但任务粒度小，我给过。" | Hard Gates: DoD 缺位 → finding；不可由 reviewer 默认 DoD。 |
| "依赖图缺 1-2 条边没关系。" | Workflow stop rule: 依赖图缺边会让 hf-test-driven-dev 在错误任务上启动；任何缺失都必须落 finding。 |
| "momus 阈值太严，第 3 轮还差 1% 就通过吧。" | Workflow stop rule（v0.6 momus）: 阈值是 boolean cliff，差 1% 也是不达标；自动转 阻塞 升级架构师，由架构师按 4 选项（接受 Round 3 / 重写 design / 降级 Acceptance / deferred backlog）拍板，reviewer 不替架构师做这个取舍。 |
| "Clarity 100% 太理想化，99 个 task 缺 1 字段也算过吧。" | Workflow stop rule（v0.6 momus）: Clarity 是任务字段齐全度，缺字段的 task 直接让 hf-test-driven-dev 启动错误；"99/100" 不是合格结论。落 finding [important][LLM-FIXABLE][momus-Clarity] 让 author 补齐。 |
Verification
