hf-tasks

name	hf-tasks
description	适用于规格与设计都已批准、需要在编码前产出可评审任务计划的场景。不适用于规格/设计未稳定（→ hf-specify / hf-design）、任务计划已批准需进入实现（→ hf-test-driven-dev）、或阶段不清（→ hf-workflow-router）。

HF 任务拆解

创建任务计划，把已批准设计转化为可执行、可追溯、可验证的工作单元，准备到可交给 hf-tasks-review 的状态。

Methodology

本 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 — 自检

When to Use

适用：

• 规格与设计都已批准，需要任务计划
• hf-tasks-review 返回 需修改 或 阻塞，需按 findings 修订
• 需要为 hf-test-driven-dev 准备任务输入和测试设计种子

不适用 → 改用：

• 规格未稳定/未批准 → hf-specify / hf-spec-review
• 设计未稳定/未批准 → hf-design / hf-design-review
• 任务计划已批准，需进入实现 → hf-test-driven-dev
• 阶段不清/证据冲突 → hf-workflow-router

Direct invoke 信号："把设计拆成任务"、"先别写代码，先梳理任务顺序"、"tasks plan 被 review 打回了"。

Hard Gates

• 任务计划通过评审并写入批准结论前，不得开始实现
• hf-tasks-review 给出"通过"前，不进入 hf-test-driven-dev
• 若请求未经过入口判断，先回到 hf-workflow-router

Workflow

1. 阅读已批准输入并提取拆解信号

阅读：已批准规格、已批准设计（默认 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，优先修复粒度过大、缺少完成条件、依赖遗漏等问题，不重做未受影响的任务。

2. 文件/工件影响图

列任务前，先明确本轮涉及哪些工件：会创建/修改哪些文件、配置、文档、状态工件、测试/验证入口。锁定任务边界，避免"实现某模块"式脱离工件现实的任务。

3. 定义里程碑与追溯

分组为能产生阶段性成果的里程碑。每个里程碑含：目标、包含的任务、退出标准、对应的需求/设计依据。对关键需求和设计决策建立显式追溯。

4. 拆解为可执行任务单元

任务必须小到能被单任务推进和验证。

优先使用：为单一行为/接口补齐可验证闭环、为高风险路径补齐实现与验证、为依赖切换/数据迁移/状态更新完成收口。

避免：实现某模块、完成功能、后面再优化。

对每个关键任务，至少明确：

• 任务 ID、目标、Acceptance、前置依赖
• Ready When、初始队列状态、Selection Priority
• Files / 触碰工件、Verify、预期证据、完成条件
• 首个活跃任务或高风险任务的测试设计种子（主要行为 + 关键边界 + 适合 fail-first 的点）

4A. 任务单元合同与仓库约束投影

不是把设计拆成几个“大任务标题”就结束。对每个会触碰代码、配置、数据或状态工件的关键任务，必须把任务级合同写实：

• Acceptance 写任务完成后什么行为/接口/状态必须为真；不要写“实现某模块”“完成某功能”
• UI 任务的 Acceptance 必须锚定 UI Implementation Contract：写明需满足的 visual invariants、token mapping、forbidden drift、interaction states 和 screenshot/DOM evidence；不得只写“有 Hero / 有卡片 / 有按钮”
• Verify 优先继承项目级约定中的真实命令、顺序与强制验证步骤；不要用泛化默认值覆盖项目规则
• 若任务触碰 UI surface、前端 API client、后端 HTTP API、dev-server/proxy/env、认证/session、浏览器存储或 full-stack flow，Verify / DoD 必须声明 runtime evidence tier：mocked unit、component integration、API contract、browser runtime、full-stack smoke 中哪些是强制，哪些允许 N/A；不能只写“单测通过”
• 若任务触碰 UI surface，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 green
• 数据库 / 迁移 / 状态切换类任务，除 Verify 外还要写明回滚 / 恢复说明，或显式引用项目中的等价字段
• 如果某任务仍只能写成“后面再细化”“实现审批流模块”这类大块描述，说明粒度还不够，继续拆

若项目规则里只差 1 个关键事实就能写实任务合同，例如：

• 验证命令的强制顺序
• 数据库相关任务是否必须写回滚说明
• 某类工件是否有固定验证入口

处理规则：

• interactive：先问 1 个最小判别问题，再继续写计划
• auto：明确把缺口写进计划 / handoff，不自行假设默认规则

5. 强化依赖与当前活跃任务规则

为每个任务给出：依赖的前置任务/工件、推荐验证命令或入口、预期结果/新鲜证据、ready/pending 判断依据。

至少补一条规则：

• 如何从计划中选定唯一 Current Active Task
• 当前任务完成后，router 如何基于依赖、ready 条件与优先级重选下一任务

6. 编写任务计划

按 references/task-plan-template.md 的默认结构起草。若 项目声明了模板覆盖，优先遵循。

任务队列投影和 board 操作详见 references/task-board-guide.md。

7. 评审前自检

交 hf-tasks-review 前确认：

• 不存在大到无法单任务推进的任务
• 关键任务有 Acceptance、Files、Verify、完成条件
• UI / API / full-stack 任务的 Verify 已写清 runtime evidence tier、启动/健康检查入口、API base URL 或明确引用项目级 runtime-smoke profile
• UI 任务的 Acceptance/Verify 已承接 UI Implementation Contract，包含 visual invariants、token mapping、forbidden drift 和 screenshot/DOM evidence targets
• 关键任务能追溯回规格/设计
• 风险区域已体现在顺序或验证中
• 已给出唯一 Current Active Task 选择规则
• router 可稳定重选下一 task
• 测试设计种子足以帮助 hf-test-driven-dev 进入测试设计

按 references/reviewer-handoff.md 派发独立 reviewer subagent 执行 hf-tasks-review。

Output Contract

完成时产出：

• 可评审任务计划（默认 features/<active>/tasks.md；若 项目声明的覆盖路径，优先遵循）
• 里程碑、追溯、工件影响图、测试设计种子、任务队列投影
• 可选 task board（默认 features/<active>/task-board.md），并在 progress 中通过 Task Board Path 引用
• feature README.md 中 Artifacts 表的 Tasks 行已更新
• canonical handoff：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。

Red Flags

• 把任务计划写成设计文档副本
• 使用大到无法验证的任务
• 漏掉依赖关系或完成条件
• 写了任务却无法追溯到规格或设计
• 把验证拖到整个功能结束时才做
• handoff 缺失却声称"可以直接进入实现"

Reference Guide

文件	用途
references/task-plan-template.md	默认计划模板结构与保存路径
references/task-board-guide.md	Task Board 示例、队列投影、活跃任务选择规则
references/reviewer-handoff.md	reviewer 派发协议与结果处理

Common Rationalizations

借口	反驳 / 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 评估。

Verification

• 任务计划已保存到约定路径
• 关键任务的 Acceptance、Files、Verify、完成条件已写清
• 需求/设计追溯与工件影响图已给出
• 测试设计种子、Current Active Task 规则、queue projection 已提供
• feature progress.md 已按 canonical schema 同步，下一步为 hf-tasks-review