القائمة
适用于规格与设计都已批准、需要在编码前产出可评审任务计划的场景。不适用于规格/设计未稳定（→ hf-specify / hf-design）、任务计划已批准需进入实现（→ hf-test-driven-dev）、或阶段不清（→ 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-tasks |
| description | 适用于规格与设计都已批准、需要在编码前产出可评审任务计划的场景。不适用于规格/设计未稳定（→ hf-specify / hf-design）、任务计划已批准需进入实现（→ hf-test-driven-dev）、或阶段不清（→ hf-workflow-router）。 |
创建任务计划，把已批准设计转化为可执行、可追溯、可验证的工作单元，准备到可交给 hf-tasks-review 的状态。
本 skill 融合以下已验证方法。每个方法在 Workflow 中有对应的落地步骤。
| 方法 | 核心原则 | 来源 | 落地步骤 |
|---|---|---|---|
| WBS (Work Breakdown Structure) | 自顶向下将设计拆解为可管理的任务层级，每个任务有明确范围、不重叠、可分配 | PMBOK, PMI | 步骤 3 — 定义里程碑；步骤 4 — 拆解任务单元 |
| INVEST Criteria | 任务粒度检查遵循 Independent/Negotiable/Valuable/Estimable/Small/Testable 六维度 | Bill Wake, 2003；敏捷用户故事实践 | 步骤 4 — 拆解粒度；步骤 7 — 自检 |
| Dependency Graph + Critical Path | 显式建模任务间依赖关系，识别关键路径，确保执行顺序可验证 | 项目化实践（项目计划通用方法） | 步骤 5 — 依赖与活跃任务规则 |
| Definition of Done (Scrum) | 每个任务具备可判断的完成条件 | Scrum Guide, Schwaber & Sutherland | 步骤 4 — 完成条件；步骤 7 — 自检 |
适用：
hf-tasks-review 返回 需修改 或 阻塞，需按 findings 修订hf-test-driven-dev 准备任务输入和测试设计种子不适用 → 改用：
hf-specify / hf-spec-reviewhf-design / hf-design-reviewhf-test-driven-devhf-workflow-routerDirect invoke 信号："把设计拆成任务"、"先别写代码，先梳理任务顺序"、"tasks plan 被 review 打回了"。
hf-tasks-review 给出"通过"前，不进入 hf-test-driven-devhf-workflow-router阅读：已批准规格、已批准设计（默认 features/<active>/spec.md / design.md）、项目上下文、项目级路径约定（若项目已声明）、feature progress.md（默认 features/<active>/progress.md）。
若 UI surface 被激活（存在 hf-ui-design 的已批准文档）：除技术设计外，也需读取 UI 设计文档，提取组件粒度、关键页面 wireframe、交互状态矩阵、Design Token 映射和 UI Implementation Contract；前端任务拆解必须承接 Atomic 分层、状态矩阵与页面/组件 visual invariants，避免把"实现某页面"当作单任务。
至少提取：主要工作流、依赖与顺序、测试影响、风险区域、关键需求/设计锚点（含 UI 设计锚点，若存在）。
若因 review findings 重新进入：先读 findings，优先修复粒度过大、缺少完成条件、依赖遗漏等问题，不重做未受影响的任务。
列任务前，先明确本轮涉及哪些工件：会创建/修改哪些文件、配置、文档、状态工件、测试/验证入口。锁定任务边界，避免"实现某模块"式脱离工件现实的任务。
分组为能产生阶段性成果的里程碑。每个里程碑含：目标、包含的任务、退出标准、对应的需求/设计依据。对关键需求和设计决策建立显式追溯。
任务必须小到能被单任务推进和验证。
优先使用：为单一行为/接口补齐可验证闭环、为高风险路径补齐实现与验证、为依赖切换/数据迁移/状态更新完成收口。
避免：实现某模块、完成功能、后面再优化。
对每个关键任务，至少明确：
不是把设计拆成几个“大任务标题”就结束。对每个会触碰代码、配置、数据或状态工件的关键任务，必须把任务级合同写实：
Acceptance 写任务完成后什么行为/接口/状态必须为真；不要写“实现某模块”“完成某功能”Acceptance 必须锚定 UI Implementation Contract：写明需满足的 visual invariants、token mapping、forbidden drift、interaction states 和 screenshot/DOM evidence；不得只写“有 Hero / 有卡片 / 有按钮”Verify 优先继承项目级约定中的真实命令、顺序与强制验证步骤；不要用泛化默认值覆盖项目规则Verify / DoD 必须声明 runtime evidence tier：mocked unit、component integration、API contract、browser runtime、full-stack smoke 中哪些是强制，哪些允许 N/A；不能只写“单测通过”Verify / DoD 必须声明 UI conformance evidence：截图路由 / viewport、DOM anchors、console/network 断言、token/visual drift 检查；若项目暂不要求截图，必须引用明确降级许可测试设计种子 至少覆盖：主行为、1 个关键边界、1 个适合 fail-first 的点hf-test-driven-dev 的最小闭环：fail-first test -> 确认失败 -> 最小实现 -> verify greenVerify 外还要写明回滚 / 恢复说明，或显式引用项目中的等价字段若项目规则里只差 1 个关键事实就能写实任务合同，例如：
处理规则：
interactive：先问 1 个最小判别问题，再继续写计划auto：明确把缺口写进计划 / handoff，不自行假设默认规则为每个任务给出：依赖的前置任务/工件、推荐验证命令或入口、预期结果/新鲜证据、ready/pending 判断依据。
至少补一条规则：
Current Active Task按 references/task-plan-template.md 的默认结构起草。若 项目声明了模板覆盖，优先遵循。
任务队列投影和 board 操作详见 references/task-board-guide.md。
交 hf-tasks-review 前确认：
hf-test-driven-dev 进入测试设计按 references/reviewer-handoff.md 派发独立 reviewer subagent 执行 hf-tasks-review。
完成时产出：
features/<active>/tasks.md；若 项目声明的覆盖路径，优先遵循）features/<active>/task-board.md），并在 progress 中通过 Task Board Path 引用README.md 中 Artifacts 表的 Tasks 行已更新hf-tasks-review状态同步：feature progress.md（默认 features/<active>/progress.md） Current Stage → hf-tasks，Next Action Or Recommended Skill → hf-tasks-review。
若计划未达评审门槛，不伪造 handoff；明确写出缺口。
注意：只有 review 通过且 approval step 完成后，才进入 hf-test-driven-dev。
| 文件 | 用途 |
|---|---|
references/task-plan-template.md | 默认计划模板结构与保存路径 |
references/task-board-guide.md | Task Board 示例、队列投影、活跃任务选择规则 |
references/reviewer-handoff.md | reviewer 派发协议与结果处理 |
| 借口 | 反驳 / Hard rule |
|---|---|
| "design 还没批，但任务已经能拆，先动手。" | Hard Gates: design / design-review 未通过前 hf-tasks 不应启动（Workflow step 1 precondition）。 |
| "INVEST 太理想化，做大任务一次性搞定更快。" | Workflow stop rule: 任务必须满足 INVEST（独立 / 可协商 / 有价值 / 可估算 / 小 / 可测）；大任务无法 fit 进单 active task TDD 节奏。 |
| "依赖图 / 关键路径以后想到再加。" | Hard Gates: 依赖图 + critical path 是 tasks 必需输出，缺位会被 hf-tasks-review 判 fail。 |
| "DoD 我写在心里。" | Verification: 每个 task 必须有可读 Definition of Done 落盘，hf-completion-gate 会按 DoD 评估。 |
progress.md 已按 canonical schema 同步，下一步为 hf-tasks-review