mcpField
T
task-management

task-management

github.com/jwilgerAgent 工作流5166 次安装17 周前更新
代码仓库

关于 task-management

task-management 是用于组织和跟踪工作的独立 Agent 技能，指导 Agent 将工作拆成小型、可验证的任务，明确依赖并按统一生命周期跟踪状态，同时适配现有任务工具。

主要功能

  1. 01自上而下拆分任务
  2. 02编写可验证的验收标准
  3. 03明确跟踪任务依赖
  4. 04Open–Active–Closed 生命周期
  5. 05适配现有任务工具

适用场景

  1. 01将功能拆分为具体交付项
  2. 02查找已解除阻塞的任务
  3. 03跟踪依赖任务的进度

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/jwilger/agent-skills --skill task-management

安装后在 Claude Code 中输入/task-management确认已加载。

详细介绍

任务管理

价值： 沟通与反馈。将工作拆分为明确、可跟踪的单元，可以清晰表达意图、衡量进度，并顺畅地交接。小任务能形成快速反馈循环，及早发现问题。

目的

学习如何将工作拆解为结构清晰、验收标准明确的任务，管理任务间的依赖关系，并通过一致的生命周期跟踪状态。最终形成工作分解结构，其中每项任务都明确无歧义、范围适当，且顺序合理，避免不必要的阻塞。

实践

自顶向下分解，自底向上执行

将大型目标逐步拆分为更小的任务，直到每项任务都对应一个单独的交付成果。自叶节点向上执行。

  1. 从目标（史诗或功能）开始
  2. 确定 3-7 项子任务，共同实现该目标
  3. 对每项子任务，询问：一个 Agent 能否在一个会话中完成？如果不能，就继续分解
  4. 叶节点任务应耗时数分钟到数小时，而不是数天

示例：

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

应该：

  • 用动词和成果命名任务（“创建注册处理程序”）
  • 将叶节点任务控制在一次专注会话可完成的范围内
  • 为每项叶节点任务添加验收标准

不应该：

  • 创建大到数小时内都无法看出进展的任务
  • 过度细分，导致任务管理开销超过实际工作量
  • 将任务写成含糊的名词（“身份验证”无法说明要做什么）
将验收标准写成可验证的陈述

每项叶节点任务都需要二元标准：满足或不满足。行为要求使用 Given/When/Then，交付成果使用清单。

  1. 说明任务完成后必须满足什么条件
  2. 每项标准都可独立测试
  3. 包含重要的边界情况

示例：

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

不应该：

  • 编写需要主观判断的标准（“运行良好”）
  • 省略错误情况——它们正是漏洞藏身之处
  • 在无关任务间复制粘贴通用标准
明确声明依赖关系

如果任务 B 必须等任务 A 完成后才能开始，就声明这项依赖。利用依赖关系图查找未受阻的工作。

  1. 创建任务前，先询问：这项任务是否依赖另一项任务的输出？
  2. 在所用工具中记录依赖关系
  3. 始终查询未受阻／已就绪的任务，而不是扫描完整列表

依赖模式：

  • 顺序执行： Schema -> Repository -> Service -> API 端点
  • 分支： 一项设计任务解除多项实现任务的阻塞
  • 汇聚： 集成测试前必须完成多项任务

应该：

  • 尽可能缩短依赖链——过长的依赖链会使工作串行化
  • 优先采用可并行执行的分解方式（可同时开展的任务）

不应该：

  • 创建循环依赖
  • 假设存在隐式顺序——明确声明每项依赖
  • 不必要地阻塞任务（B 是否真的需要 A，还是只需要 A 的接口？）
将切片分解为任务

使用 GWT（Given-When-Then，给定-当-则）场景（例如，来自事件建模）处理垂直切片时，应对切片进行分解，使每个任务代表一个可测试的行为增量，并完整经历一个 RED-GREEN-COMMIT 循环：

  1. 每个 GWT 场景至少对应一个任务
  2. 每个任务 = 一个 TDD 循环：一个失败的测试 + 对应的实现 + 提交
  3. 按以下顺序排列任务：
    • 优先处理步行骨架依赖项——多个场景都需要的基础设施或连接逻辑（各自作为独立的 TDD 循环）
    • 验收场景任务——每个场景对应一个任务，从最外层的失败测试开始，通过逐层深入的循环完成
  4. 每个任务包括：
    • 描述： 动词 + 结果（例如，“通过 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 的瀑布流程。像“创建所有领域类型”再接着“实现所有处理器”这样的任务，会将各阶段拆分到不同任务中，而不是让每个任务都完整经历一个 TDD 循环。

流水线跟踪元数据

在流水线模式下运行时，任务会增加以下跟踪字段：

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

这些字段在独立模式下仅供参考。在流水线模式下，协调器会使用这些字段跟踪切片进度，并检测任务是否反复进入返工流程。

按一致的生命周期跟踪状态

任务会在一组固定状态之间流转。状态转换均需明确。

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

  1. Open： 任务已定义，正在等待处理。可能受依赖项阻塞。
  2. Active： 工作正在进行中。为保持专注，每个 Agent 同一时间应只有一个处于活动状态的任务。
  3. Closed： 工作已完成，且已满足验收标准。务必记录关闭原因。

规则：

  • 开始任务前，先将其设为活动状态
  • 只有满足所有验收标准后，才能关闭任务
  • 提供关闭原因以留作审计记录
  • 如果放弃某项任务，应关闭它并注明原因（“已被 X 取代”或“不再需要”）
根据可用工具进行调整

此技能适用于任何可用的任务跟踪工具。请检测并使用最佳选项：

  1. Harness 原生任务工具（Claude Code TodoWrite、Codex tasks）：直接使用。它们与 Agent 的工作流集成。
  2. dot CLI（.dots/ 目录）：基于文件并进行版本控制。使用 dot ready 查找未被阻塞的工作。在创建 PR 前，先在功能分支上关闭任务。
  3. GitHub Issues：用于跨团队协作。将 PR 关联到 Issue。
  4. 基于文件的备用方案：在仓库根目录创建 TASKS.md。使用 Markdown 复选清单，并与更改一同提交。

无论使用什么工具，方法论（分解、明确标准、跟踪依赖项、管理生命周期）都相同。工具可以互换，纪律不可替代。

执行说明

所有模式下均为建议性要求。任务结构和依赖项跟踪由使用者自行执行。

硬性约束：

  • 关闭任务时必须提供关闭原因：[RC]

约束

  • “每个 Agent 同时只能有一个活动任务”：每个 Agent 指的是每个执行上下文。在具有并行工作树的流水线模式中，每个工作树都是一个独立的上下文。由同一位人类操作员管理多个工作树不违反此规则。单个 Agent 上下文同时有多个“活动”任务则违反此规则。
  • 二元验收标准：“二元”是指外部观察者无需主观判断即可验证是否满足。“代码整洁”不是二元标准。“所有函数都少于 50 行”是二元标准。“测试通过”是二元标准。“代码遵循最佳实践”不是。如果需要争论某项标准是否满足，那它就不是二元标准。

有关流水线并行化规则，请参阅模板目录中的 CONSTRAINT-RESOLUTION.md。

验证

完成此技能指导的工作后，请验证：

  • 每项工作都有对应的任务和验收标准
  • 没有在依赖项仍未完成时处理任何任务
  • 每个 Agent 同一时间最多只有一个活动任务
  • 已关闭的任务都记录了关闭原因
  • 任务层级清晰易于浏览（父子关系明确）
  • 剩余的未完成任务准确反映了尚未完成的工作

如果任何一项标准未满足，请在继续之前重新审视相关实践。

依赖项

此技能可独立使用。如需增强工作流，可与以下内容集成：

  • tdd： 每项任务对应一个或多个 TDD 循环。任务的验收标准会成为红阶段编写的测试。在自动化模式下，任务依赖关系有助于确定如何在多个 Agent 之间分配工作。
  • architecture-decisions： 重要的结构性任务应引用相关的 ADR。

缺少依赖项？请安装：

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

评论

支持 Markdown