task-management

用途

Task Management 用于把软件工作拆解为结构清晰、可跟踪的任务单元，使意图可见、进度可衡量、交接顺畅。其目标是产出一份工作分解，其中每个任务都无歧义、范围适当、排序合理，不会出现不必要的阻塞。该技能强调沟通与反馈：小任务带来短反馈循环，能尽早发现问题。

主要能力

自上而下分解，自下而上执行

将大目标逐步拆分为更小的任务，直到每个任务代表单一可交付成果，然后从叶子任务向上执行。

• 从目标（史诗或特性）开始
• 识别 3-7 个共同达成目标的子任务
• 对每个子任务提问：一个代理能否在一次会话中完成？若不能，继续分解
• 叶子任务应耗时数分钟到数小时，而非数天

示例：

Epic: User Authentication
  Story: Registration flow
    Task: Create registration command handler
    Task: Build registration form component
    Task: Add email verification automation
  Story: Login flow
    Task: Create login command handler
    Task: Build login form component

应做：用动词加结果命名任务（如 "Create registration handler"）；叶子任务小到可在一个专注会话内完成；每个叶子任务都包含验收标准。

不应做：创建大到数小时都看不到进展的任务；分解过细导致任务管理开销超过任务本身；把任务留作模糊名词（如 "Authentication"）。

编写可验证的验收标准

每个叶子任务都需要二元标准：满足或不满足。行为使用 Given/When/Then，交付物使用清单。

• 说明任务完成时必须为真的事项
• 每条标准可独立测试
• 包含重要的边界情况

示例：

Task: Create registration command handler

Acceptance Criteria:
- [ ] Given valid registration data, when command is processed,
      then UserRegistered event is stored
- [ ] Given a duplicate email, when command is processed,
      then command is rejected with a clear error
- [ ] Given a password under 12 characters, when command is processed,
      then validation fails before reaching the handler

不应做：编写需要主观判断的标准（如 "works well"）；省略错误情况；在不相关任务间复制粘贴通用标准。

显式声明依赖

当任务 B 在任务 A 完成前无法开始时，声明该依赖。使用依赖图查找未被阻塞的工作。

• 创建任务前先问：这是否依赖另一个任务的输出？
• 在所用工具中记录依赖
• 始终查询未阻塞/就绪任务，而非扫描完整列表

依赖模式：

• 顺序：Schema -> Repository -> Service -> API endpoint
• 扇出：一个设计任务解除多个实现任务的阻塞
• 扇入：多个任务必须完成后才能进行集成测试

应做：保持依赖链尽可能短；优先采用可并行安全的分解。

不应做：创建循环依赖；假设隐式顺序；不必要地阻塞任务（B 真的需要 A，还是只需要 A 的接口？）。

切片到任务分解

当从垂直切片配合 GWT（Given-When-Then）场景（例如来自事件建模）工作时，将切片分解为每个任务代表一个可测试行为增量，并经过完整的 RED-GREEN-COMMIT 循环：

• 每个 GWT 场景至少成为一个任务
• 每个任务 = 一个 TDD 循环：一个失败测试 + 其实现 + 提交
• 任务排序：先处理行走骨架依赖（多个场景需要的基础设施或管道，各自作为独立 TDD 循环），再处理验收场景任务（每个场景是一个任务，从最外层失败测试开始，通过下钻循环完成）

每个任务包含：

• 描述：动词 + 结果（如 "Implement deposit scenario end-to-end via TDD"）
• 验收标准：直接来自 GWT 场景
• 预估范围：可能受影响的文件（有助于变异测试范围界定）

示例：

Slice: "Customer deposits funds"
  Task 1: Walking skeleton — wire request-to-response path (RED: acceptance
    test hits endpoint and gets 404 → GREEN: route exists, returns stub →
    COMMIT)
  Task 2: Deposit scenario — deposit $100 into verified account (RED:
    acceptance test asserts balance increases → drill-down into command
    handler, event persistence, projection — each inner cycle is
    RED-GREEN-COMMIT within this task → outer acceptance test passes → COMMIT)

反模式：不要创建把多种类型或行为批量放入一个 RED 阶段、再单独一个 GREEN 阶段的任务——这是伪装成 TDD 的瀑布模型。例如 "Create all domain types" 后接 "Implement all handlers" 的任务，把阶段拆分到不同任务，而非让每个任务保持完整 TDD 循环。

流水线跟踪元数据

在流水线模式下运行时，任务获得额外跟踪字段：

• slice_id：将任务链接到其来源垂直切片
• gate_status：pending、passed 或 failed（反映质量门结果）
• rework_count：任务因质量门失败而返回的次数

这些字段在独立模式下仅供参考。在流水线模式下，编排器用它们跟踪切片进度，并检测反复返工的任务。

通过一致生命周期跟踪状态

任务经过固定状态集，转换是显式的。

生命周期：Open -> Active -> Closed

• Open：任务已定义并等待，可能被依赖阻塞
• Active：工作正在进行。每个代理同一时间只应有一个活动任务，以保持专注
• Closed：工作完成且验收标准满足。始终记录原因

规则：

• 开始工作前先激活任务
• 仅当所有验收标准满足时才关闭任务
• 提供关闭原因以供审计
• 若任务被放弃，以原因关闭（如 "Superseded by X" 或 "No longer needed"）

适配可用工具

该技能可与任何可用的任务跟踪方式配合。检测并使用最佳选项：

• 代理原生任务工具（Claude Code TodoWrite、Codex tasks）：直接使用，它们与代理工作流集成
• dot CLI（.dots/ 目录）：基于文件、受版本控制。使用 dot ready 查找未阻塞工作。在创建 PR 前于特性分支关闭任务
• GitHub Issues：用于跨团队可见性。将 PR 链接到 issue
• 基于文件的回退：在仓库根目录创建 TASKS.md，使用 markdown 清单，随变更提交

无论工具如何，方法论（分解、指定标准、跟踪依赖、管理生命周期）相同。工具可互换，纪律不可。

使用方式

该技能为建议性，在所有模式下任务结构与依赖跟踪均为自我执行。硬约束：关闭任务时必须提供关闭原因 [RC]。

约束说明：

• "每个代理一个活动任务"：每个代理指每个执行上下文。在流水线模式下使用并行工作树时，每个工作树是独立上下文。单个操作者管理多个工作树不违反此规则；单个代理上下文有多个 "活动" 任务则违反。
• 二元验收标准："二元" 指外部观察者无需主观判断即可验证满足/不满足。"Code is clean" 不是二元；"All functions are under 50 lines" 是二元；"Tests pass" 是二元；"Code follows best practices" 不是。若需争论标准是否满足，则不是二元。

流水线并行化规则参见模板目录中的 CONSTRAINT-RESOLUTION.md。

适用场景

适用于需要将软件工作结构化拆解、明确依赖关系并跟踪进度的场景，尤其适合采用测试驱动开发、垂直切片或事件建模的工作流。可与 tdd 技能集成：每个任务映射到一个或多个 TDD 循环，任务验收标准成为红阶段编写的测试；在自动化模式下，任务依赖决定工作如何在代理间委派。也可与 architecture-decisions 集成：重大结构性任务应引用相关 ADR。

验证

完成由该技能指导的工作后，验证：

• 每个工作单元都有对应任务及验收标准
• 没有任务在其依赖仍开放时被处理
• 每个代理的活动任务限制为一个
• 已关闭任务有记录原因
• 任务层级可导航（父子关系清晰）
• 剩余开放任务准确反映未完成工作

若任一标准未满足，在继续前重新审视相关实践。

限制

该技能为建议性，任务结构与依赖跟踪为自我执行，不提供强制机制。缺失依赖时可安装：

npx skills add jwilger/agent-skills --skill tdd

关于收费、价格、平台支持范围等具体信息，资料中暂未提供。