task-management

任务管理

概述

任务管理会将已批准的计划转化为细小、可跟踪的任务，并通过进度报告和检查点审查来协调任务执行。每项任务都是一个需要 2-5 分钟完成的单一操作。此技能提供结构化的进度跟踪、定期检查点，以及与代码审查的集成，以在整个执行过程中保持质量。

开始时宣布：“我正在使用任务管理技能，将此计划拆分为可跟踪的任务。”

触发条件

• 需要将已批准的计划文档转换为可执行任务
• 多步骤实施需要结构化的进度跟踪
• 工作需要定期进行检查点审查
• 使用 /execute 命令执行需要拆分任务的计划
• 从规划技能切换到已批准计划的执行阶段

---

阶段 1：解析计划

目标： 按正确顺序和依赖关系，从已批准的计划中提取所有任务。

1. 从头到尾阅读已批准的计划文档
2. 将每个实施步骤提取为独立任务
3. 确定任务之间的依赖关系（哪些任务必须先完成）
4. 按依赖关系排序任务——优先安排相互独立的任务
5. 开始执行前，向用户确认任务列表

任务粒度规则

粒度	示例	评定
单一操作，2-5 分钟	“为 UserService.create 编写失败测试”	正确
单一操作，2-5 分钟	“运行测试以确认其失败”	正确
单一操作，2-5 分钟	“编写通过测试所需的最少代码”	正确
多个操作，30+ 分钟	“实现身份验证系统”	太大——拆分
琐碎操作，< 1 分钟	“添加一个空行”	太小——与相邻任务合并

任务规范模板

Task N: [Clear, specific description]
Files: [Exact paths to create/modify/test]
Depends on: [Task numbers that must complete first, or "none"]
Verification: [Exact command to confirm completion]

停止——在进入阶段 2 之前，必须确保：

• 计划中的每个步骤都已转换为 2-5 分钟的任务
• 已梳理依赖关系（不存在循环依赖）
• 每项任务都有验证命令
• 用户已确认任务列表

---

阶段 2：执行任务

目标： 一次执行一项任务，并在每项任务完成后进行验证。

单项任务工作流

1. 宣布 — 报告即将开始的任务：[N/Total] Starting: <description>
2. 设置状态 — 将任务标记为 in_progress
3. 执行 — 执行任务（编写代码时遵循 TDD）
4. 验证 — 运行验证命令
5. 阅读输出 — 确认验证结果符合成功标准
6. 报告 — 显示完成情况：[N/Total] Completed: <description>
7. 设置状态 — 将任务标记为 completed

执行规则

规则	原因
一次只执行一项任务	避免上下文切换错误
标记完成前先验证	避免误报完成
完整阅读验证输出	不要根据部分输出就假定成功
编写代码的任务遵循 TDD	RED-GREEN-REFACTOR 循环
不要跳过任务	依赖项可能尚未满足

任务状态流转

pending → in_progress → completed
                     → blocked (needs user input)
                     → failed (invoke resilient-execution)

状态决策表

结果	新状态	操作
验证通过	completed	继续下一项任务
验证失败，且可修复	in_progress	修复并重新验证
验证失败，原因不明	failed	调用 resilient-execution 技能
需要用户决定	blocked	报告阻塞事项，暂停任务
任务依赖于已阻塞的任务	pending	跳过此任务，继续下一项未阻塞的任务

当前任务的验证通过前，不要继续下一项任务。

---

阶段 3：检查点审查

目标： 每完成 3 项任务后暂停，以评估进度和质量。

检查点触发表

条件	操作
自上次检查点以来已完成 3 项任务	必须进行检查点审查
一个逻辑批次已完成（例如，一个组件）	建议进行检查点审查
遇到测试失败	立即进行检查点审查
用户询问状态	临时进行检查点审查

检查点步骤

1. 显示进度摘要
2. 运行完整测试套件（不只是新测试）
3. 根据情况运行 lint、类型检查和构建
4. 如果编写了重要代码，则调用 code-review 技能
5. 询问用户当前方向是否仍然正确

进度报告格式

每项任务完成后：

[3/15] Task completed: Write failing test for UserService.create
       Files: tests/services/user.test.ts
       Verification: npm test -- --grep "UserService.create" — PASS

每个检查点完成后：

── Checkpoint [6/15] ──
Completed: 6 | Remaining: 9 | Blocked: 0
Tests: 12 passing, 0 failing
Lint: clean | Build: passing
Next batch: Tasks 7-9 (API endpoint implementation)
Continue? [yes / adjust plan / stop here]

停止 — 在以下条件满足前，不要继续下一批任务：

• 完整测试套件通过
• 已向用户提交检查点报告
• 用户已确认继续

---

第 4 阶段：批次审查

目标： 完成一组逻辑相关的任务后，进行质量审查。

1. 调用 code-reviewer Agent 审查该批次
2. 在继续之前修复所有严重或重要问题
3. 使用描述清晰的 Conventional Commit 消息提交该批次
4. 将计划文档更新为已完成状态

审查问题处理

严重程度	操作	是否继续？
严重	必须立即修复	否 — 先修复
重要	应在下一批任务开始前修复	有条件 — 由用户决定
建议	记录以供后续处理	是 — 继续

停止 — 在以下条件满足前，不要开始下一批任务：

• 已解决严重级别的审查问题
• 已提交该批次
• 已更新计划文档

---

第 5 阶段：完成

目标： 确认所有任务均已完成，并报告最终状态。

1. 确认所有任务状态均为 completed
2. 运行最终完整测试套件
3. 运行所有验证命令
4. 向用户提交最终摘要
5. 调用 verification-before-completion 技能

最终摘要格式

── FINAL SUMMARY ──
Total tasks: 15 | Completed: 15 | Failed: 0
Tests: 42 passing, 0 failing
Build: passing | Lint: clean
Commits: 5 (conventional format)

All tasks from plan docs/plans/2026-03-15-feature.md are complete.
Verification-before-completion: PASS

---

反模式 / 常见错误

反模式	失败原因	正确做法
未经验证就标记为已完成	进度虚报，错误不断累积	运行验证命令并阅读输出
任务耗时超过 5 分钟	难以跟踪，容易偏离范围	将任务拆分为耗时 2–5 分钟的小任务
跳过检查点	质量下降，方向偏移	每 3 项任务设置一个检查点
只运行新测试	无法发现回归问题	在检查点运行完整测试套件
并行执行存在依赖关系的任务	竞态条件、合并冲突	一次执行一项任务，除非任务确实相互独立
遇到阻塞任务却默默继续	用户不知道哪些工作被跳过	明确报告所有阻塞因素
未在批次边界提交	变更集过大，难以审查	每个逻辑批次完成后提交
“能用，我稍后再验证”	“稍后”永远不会到来	现在就验证

---

防止自我合理化的守则

未经验证，不得将任何任务标记为已完成。运行验证命令，阅读输出，并确认结果符合预期。只有完成这些步骤后，才能标记任务为已完成。

如果你发现自己在想：

• “代码看起来没问题，不用运行……” — 运行它。务必运行。
• “我把验证合并起来做……” — 不行。每项任务都要单独验证。
• “这项任务很简单，肯定没问题……” — 用验证证明这一点。

---

集成点

技能	关系	时机
planning	上游 — 提供已批准的计划	任务列表来源
executing-plans	互补 — 处理计划执行流程	可配合使用
test-driven-development	每项任务适用 — 代码任务的 TDD 循环	每项代码任务
verification-before-completion	每项任务适用 — 验证关卡	将任何任务标记为已完成之前
resilient-execution	失败时适用 — 使用替代方案重试	任务验证失败时
code-review	检查点适用 — 批次质量审查	每 3 项任务或批次边界
subagent-driven-development	替代方案 — 并行执行路径（通过 Agent 工具）	执行相互独立的任务批次时
Agent 工具	所有子 Agent 工作的调用机制	并行执行相互独立的任务时
circuit-breaker	安全网 — 检测停滞	任务反复失败时

---

具体示例

示例：从计划中提取任务

计划步骤："添加带验证的用户注册端点"

提取出的任务：

Task 1: Write failing test for POST /api/users input validation
  Files: tests/api/users.test.ts
  Depends on: none
  Verification: npm test -- --grep "POST /api/users validation" → FAIL (expected)

Task 2: Implement input validation schema
  Files: src/schemas/user.ts
  Depends on: Task 1
  Verification: npm test -- --grep "POST /api/users validation" → PASS

Task 3: Write failing test for POST /api/users success case
  Files: tests/api/users.test.ts
  Depends on: Task 2
  Verification: npm test -- --grep "POST /api/users creates user" → FAIL (expected)

Task 4: Implement registration endpoint handler
  Files: src/routes/users.ts
  Depends on: Task 3
  Verification: npm test -- --grep "POST /api/users" → ALL PASS

Task 5: Commit registration endpoint
  Files: none (git operation)
  Depends on: Task 4
  Verification: git log --oneline -1 → shows conventional commit

示例：受阻任务报告

BLOCKED: Task 7 — Write integration test for payment webhook
Reason: Stripe test API key not configured in .env.test
Impact: Tasks 7-9 (payment flow) cannot proceed
Non-blocked tasks: Tasks 10-12 (profile page) can continue

Options:
A. User provides Stripe test key → unblocks Tasks 7-9
B. Skip payment tasks, continue with profile → revisit later
C. Mock Stripe entirely → reduces test fidelity

Awaiting direction.

---

核心原则

• 一次处理一个任务 — 除非任务确实相互独立，否则不要并行处理
• 每个任务完成后都要验证 — 标记为完成前，先运行验证命令
• 定期设置检查点 — 每 3 个任务后暂停并评估
• 跟踪所有事项 — 每个任务都必须有状态
• 小步提交 — 每个逻辑批次后提交

---

技能类型

RIGID — 严格遵循此流程。每个任务都要验证。每 3 个任务设置一个检查点。无一例外。