Back to Details

task-management

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Task Management

任务管理

Value: Communication and feedback. Breaking work into explicit, trackable units makes intent visible, progress measurable, and handoffs clean. Small tasks create short feedback loops that catch problems early.
价值： 沟通与反馈。将工作拆分为明确、可跟踪的单元，能让意图可视化、进度可衡量，且工作交接清晰。小型任务可创建短反馈循环，尽早发现问题。

Purpose

目标

Teaches how to decompose work into well-structured tasks with clear acceptance criteria, manage dependencies between tasks, and track status through a consistent lifecycle. The outcome is a work breakdown where every task is unambiguous, appropriately scoped, and sequenced so nothing is blocked unnecessarily.
教授如何将工作分解为结构清晰、验收标准明确的任务，管理任务间的依赖关系，并通过统一的生命周期跟踪状态。最终产出的工作分解结构中，每个任务都清晰明确、范围恰当，且排序合理，避免不必要的阻塞。

Practices

实践方法

Decompose Top-Down, Execute Bottom-Up

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

Break large goals into progressively smaller tasks until each task represents a single deliverable outcome. Execute from the leaves up.
  1. Start with the goal (epic or feature)
  2. Identify 3-7 child tasks that together achieve the goal
  3. For each child, ask: can one agent complete this in one session? If no, decompose further
  4. Leaf tasks should take minutes to hours, not days
Example:
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
Do:
  • Name tasks with a verb and an outcome ("Create registration handler")
  • Keep leaf tasks small enough for one focused session
  • Include acceptance criteria on every leaf task
Do not:
  • Create tasks so large that progress is invisible for hours
  • Decompose so finely that task overhead exceeds task work
  • Leave tasks as vague nouns ("Authentication" tells no one what to do)
将大型目标逐步拆分为更小的任务，直到每个任务代表单一可交付成果。从最底层任务开始执行。
  1. 从目标（Epic或Feature）入手
  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
注意事项：
  • 任务名称需包含动词和成果（例如“创建注册命令处理器”）
  • 最底层任务的规模需适合集中完成一个工作时段
  • 每个最底层任务都要包含验收标准
禁止行为：
  • 创建规模过大的任务，导致数小时内无法看到进度
  • 过度分解任务，导致任务管理的开销超过任务本身的工作量
  • 将任务命名为模糊的名词（例如“身份验证”无法明确指示具体工作）

Write Acceptance Criteria as Verifiable Statements

将验收标准编写为可验证的陈述

Every leaf task needs criteria that are binary: met or not met. Use Given/When/Then for behavior, checklists for deliverables.
  1. State what must be true when the task is done
  2. Each criterion is independently testable
  3. Include edge cases that matter
Example:
markdown
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
Do not:
  • Write criteria that require subjective judgment ("works well")
  • Omit error cases -- they are where bugs live
  • Copy-paste generic criteria across unrelated tasks
每个最底层任务都需要二元化的验收标准：达标或未达标。针对行为使用Given/When/Then格式，针对交付物使用清单形式。
  1. 明确任务完成后必须满足的条件
  2. 每个标准都应可独立测试
  3. 纳入重要的边缘场景
示例：
markdown
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
禁止行为：
  • 编写需要主观判断的标准（例如“运行良好”）
  • 遗漏错误场景——这是漏洞的高发区
  • 在不相关的任务间复制粘贴通用标准

Declare Dependencies Explicitly

明确声明依赖关系

When task B cannot start until task A completes, declare the dependency. Use the dependency graph to find unblocked work.
  1. Before creating a task, ask: does this depend on another task's output?
  2. Record the dependency in whatever tool you are using
  3. Always query for unblocked/ready tasks rather than scanning the full list
Dependency patterns:
  • Sequential: Schema -> Repository -> Service -> API endpoint
  • Fan-out: One design task unblocks multiple implementation tasks
  • Fan-in: Multiple tasks must complete before integration testing
Do:
  • Keep dependency chains as short as possible -- long chains serialize work
  • Prefer parallel-safe decomposition (tasks that can run simultaneously)
Do not:
  • Create circular dependencies
  • Assume an implicit ordering -- make every dependency explicit
  • Block tasks unnecessarily (does B really need A, or just A's interface?)
当任务B必须在任务A完成后才能启动时，需声明该依赖关系。利用依赖图查找未被阻塞的工作。
  1. 创建任务前，思考：该任务是否依赖其他任务的输出？
  2. 在你使用的工具中记录依赖关系
  3. 始终查询未被阻塞/就绪的任务，而非扫描完整任务列表
依赖模式：
  • 顺序依赖： Schema -> Repository -> Service -> API端点
  • 扇出依赖： 一个设计任务可解锁多个实现任务
  • 扇入依赖： 多个任务必须完成后才能进行集成测试
注意事项：
  • 尽量缩短依赖链——长依赖链会导致工作串行化
  • 优先选择支持并行的分解方式（可同时执行的任务）
禁止行为：
  • 创建循环依赖
  • 假设存在隐含的排序——所有依赖关系都必须明确声明
  • 不必要地阻塞任务（任务B真的需要等待任务A完成，还是只需要任务A的接口？）

Track Status Through a Consistent Lifecycle

通过统一的生命周期跟踪状态

Tasks move through a fixed set of states. Transitions are explicit.
Lifecycle: Open -> Active -> Closed
  1. Open: Task is defined and waiting. May be blocked by dependencies.
  2. Active: Work is in progress. Only one task should be active per agent at a time to maintain focus.
  3. Closed: Work is done and acceptance criteria are met. Always record why.
Rules:
  • Activate a task before starting work on it
  • Close a task only when all acceptance criteria are met
  • Provide a close reason for audit trail
  • If a task is abandoned, close it with the reason ("Superseded by X" or "No longer needed")
任务会在一组固定的状态间流转，状态转换需明确。
生命周期： 待处理（Open）-> 进行中（Active）-> 已完成（Closed）
  1. 待处理： 任务已定义并等待执行，可能被依赖关系阻塞。
  2. 进行中： 工作正在开展。为保持专注，每个Agent同一时间应仅激活一个任务。
  3. 已完成： 工作已完成且满足所有验收标准。需始终记录完成原因。
规则：
  • 开始工作前需激活任务
  • 仅当所有验收标准都满足时才能关闭任务
  • 提供关闭原因以形成审计轨迹
  • 如果任务被放弃，需注明原因后关闭（例如“被X替代”或“不再需要”）

Adapt to Available Tools

适配可用工具

This skill works with whatever task tracking is available. Detect and use the best option:
  1. Harness-native task tools (Claude Code TodoWrite, Codex tasks): Use them directly. They integrate with the agent's workflow.
  2. dot CLI (.dots/ directory): File-based, version-controlled. Use 
    dot ready
    to find unblocked work. Close tasks on the feature branch before creating PRs.
  3. GitHub Issues: Use for cross-team visibility. Link PRs to issues.
  4. File-based fallback: Create a 
    TASKS.md
    in the repo root. Use markdown checklists. Commit with changes.
The methodology (decompose, specify criteria, track dependencies, manage lifecycle) is the same regardless of tool. The tool is interchangeable; the discipline is not.
该Skill可适配任何现有的任务跟踪工具。选择并使用最优选项：
  1. Harness原生任务工具（Claude Code TodoWrite、Codex tasks）：直接使用，它们与Agent的工作流深度集成。
  2. dot CLI（.dots/目录）：基于文件且受版本控制。使用
    dot ready
    命令查找未被阻塞的工作。在创建PR前，需在功能分支上关闭任务。
  3. GitHub Issues：用于跨团队可见性管理。将PR链接到对应Issue。
  4. 基于文件的备选方案：在仓库根目录创建
    TASKS.md
    文件，使用Markdown清单。随代码变更一起提交。
无论使用哪种工具，方法论（分解任务、明确标准、跟踪依赖、管理生命周期）都是一致的。工具可以替换，但纪律不能缺失。

Enforcement Note

实施说明

This skill provides advisory guidance on task decomposition and tracking. It cannot mechanically prevent an agent from skipping task creation or working on blocked items. On harnesses with plugin support, enforcement plugins can require task activation before code changes and block work on tasks with unresolved dependencies. On harnesses without enforcement, the agent follows these practices by convention. For available enforcement plugins, see the Harness Plugin Availability table.
该Skill提供关于任务分解与跟踪的指导性建议，无法机械地阻止Agent跳过任务创建或处理被阻塞的任务。在支持插件的Harness上，实施插件可要求在代码变更前激活任务，并阻止处理存在未解决依赖的任务。在不支持实施插件的Harness上，Agent需通过遵循惯例来执行这些实践方法。如需了解可用的实施插件，请查看Harness插件可用性表格。

Verification

验证

After completing work guided by this skill, verify:
  • Every unit of work has a corresponding task with acceptance criteria
  • No task was worked on while its dependencies were still open
  • Active tasks were limited to one at a time per agent
  • Closed tasks have a recorded reason
  • The task hierarchy is navigable (parent-child relationships are clear)
  • Remaining open tasks accurately reflect outstanding work
If any criterion is not met, revisit the relevant practice before proceeding.
在遵循该Skill完成工作后，需验证以下内容：
  • 每一项工作都有对应的任务及验收标准
  • 没有任务在其依赖项仍处于待处理状态时就被执行
  • 每个Agent同一时间仅激活一个任务
  • 已完成的任务都记录了完成原因
  • 任务层级结构可导航（父子关系清晰）
  • 剩余的待处理任务准确反映了未完成的工作
如果任何一项标准未达标，需重新审视相关实践方法后再继续推进。

Dependencies

依赖关系

This skill works standalone. For enhanced workflows, it integrates with:
  • tdd-cycle: Each task maps to one or more TDD cycles. Task acceptance criteria become the tests you write in the red phase.
  • orchestration: Task dependencies inform how work is delegated across agents.
  • architecture-decisions: Major structural tasks should reference relevant ADRs.
Missing a dependency? Install with:
npx skills add jwilger/agent-skills --skill tdd-cycle
该Skill可独立使用。如需增强工作流，可与以下Skill集成：
  • tdd-cycle： 每个任务对应一个或多个TDD循环。任务的验收标准将成为你在红阶段编写的测试用例。
  • orchestration： 任务依赖关系可指导如何在多个Agent间分配工作。
  • architecture-decisions： 重要的结构性任务应引用相关的ADR（架构决策记录）。
缺少依赖项？使用以下命令安装：
npx skills add jwilger/agent-skills --skill tdd-cycle