task-management

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Task Management

任务管理

Overview

概述

Task management converts approved plans into bite-sized, trackable tasks and orchestrates their execution with progress reporting and checkpoint reviews. Each task is a single action that takes 2-5 minutes. The skill provides structured progress tracking, regular checkpoints, and integration with code review to maintain quality throughout execution.

Announce at start: "I'm using the task-management skill to break this plan into tracked tasks."

任务管理将已获批的计划转换为小颗粒度、可跟踪的任务，并通过进度汇报和检查点评审协调任务执行。每个任务都是耗时2-5分钟的单一动作。该Skill提供结构化的进度跟踪、定期检查点，以及与代码评审的集成能力，可在整个执行过程中保障质量。

启动时声明： "我正在使用task-management skill将该计划拆分为可跟踪的任务。"

Trigger Conditions

触发条件

An approved plan document needs to be converted into executable tasks
Multi-step implementation needs structured progress tracking
Work needs checkpoint reviews at regular intervals
```
/execute
```
command used with a plan that needs task breakdown
Transition from planning skill with an approved plan

已获批的计划文档需要转换为可执行任务
多步骤实现需要结构化的进度跟踪
工作需要定期开展检查点评审
对需要拆分任务的计划使用
```
/execute
```
命令
从planning skill切换且已有获批计划

Phase 1: Plan Parsing

第一阶段：计划解析

Goal: Extract all tasks from the approved plan with correct ordering and dependencies.

Read the approved plan document from start to finish
Extract every implementation step as a discrete task
Identify dependencies between tasks (what must complete first)
Order tasks by dependency — independent tasks first
Confirm task list with the user before beginning execution

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

从头到尾通读获批计划文档
将每个实现步骤提取为独立任务
识别任务间的依赖关系（哪些任务必须先完成）
按依赖关系排序任务 — 独立任务优先
开始执行前与用户确认任务列表

Task Granularity Rules

任务粒度规则

Granularity	Example	Verdict
Single action, 2-5 min	"Write the failing test for UserService.create"	Correct
Single action, 2-5 min	"Run the test to verify it fails"	Correct
Single action, 2-5 min	"Implement the minimal code to pass the test"	Correct
Multiple actions, 30+ min	"Implement the authentication system"	Too large — decompose
Trivial, < 1 min	"Add a blank line"	Too small — merge with adjacent task

粒度	示例	判定
单一动作，2-5分钟	"Write the failing test for UserService.create"	正确
单一动作，2-5分钟	"Run the test to verify it fails"	正确
单一动作，2-5分钟	"Implement the minimal code to pass the test"	正确
多个动作，30分钟以上	"Implement the authentication system"	粒度过大 — 需要拆分
过于琐碎，耗时<1分钟	"Add a blank line"	粒度过小 — 与相邻任务合并

Task Specification Template

任务规范模板

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]

STOP — Do NOT proceed to Phase 2 until:

Every plan step has been converted to 2-5 minute tasks
Dependencies are mapped (no circular dependencies)
Every task has a verification command
Task list is confirmed with user

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-5分钟的任务
依赖关系已梳理完成（无循环依赖）
每个任务都有验证命令
任务列表已获得用户确认

Phase 2: Task Execution

第二阶段：任务执行

Goal: Execute tasks one at a time with verification after each.

目标： 逐个执行任务，每个任务完成后都进行验证。

Per-Task Workflow

单任务工作流

Announce — Report which task is starting:
```
[N/Total] Starting: <description>
```
Set status — Mark task as
```
in_progress
```
Execute — Perform the task (follow TDD if writing code)
Verify — Run the verification command
Read output — Confirm verification matches success criteria
Report — Show completion:
```
[N/Total] Completed: <description>
```
Set status — Mark task as
```
completed
```

声明 — 报告即将启动的任务：
```
[N/Total] Starting: <description>
```
设置状态 — 将任务标记为
```
in_progress
```
执行 — 完成任务（编写代码时遵循TDD规范）
验证 — 运行验证命令
读取输出 — 确认验证结果符合成功标准
汇报 — 展示完成状态：
```
[N/Total] Completed: <description>
```
设置状态 — 将任务标记为
```
completed
```

Execution Rules

执行规则

Rule	Rationale
One task at a time	Prevents context switching errors
Verify before marking complete	No false completions
Read verification output fully	Do not assume success from partial output
Follow TDD for code tasks	RED-GREEN-REFACTOR cycle
Do not skip ahead	Dependencies may not be satisfied

规则	逻辑
一次仅执行一个任务	避免上下文切换带来的错误
标记完成前先验证	避免虚假完成
完整读取验证输出	不要通过部分输出假设执行成功
代码任务遵循TDD规范	遵循RED-GREEN-REFACTOR周期
不要跳步执行	可能存在未满足的依赖关系

Task Status Flow

任务状态流转

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

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

Status Decision Table

状态判定表

Outcome	New Status	Action
Verification passes	`completed`	Proceed to next task
Verification fails, fixable	`in_progress`	Fix and re-verify
Verification fails, unclear cause	`failed`	Invoke `resilient-execution` skill
Needs user decision	`blocked`	Report blocker, pause task
Task depends on blocked task	`pending`	Skip to next non-blocked task

Do NOT proceed to next task until current task verification passes.

结果	新状态	动作
验证通过	`completed`	继续执行下一个任务
验证失败、可修复	`in_progress`	修复后重新验证
验证失败、原因不明	`failed`	调用 `resilient-execution` skill
需要用户决策	`blocked`	上报阻塞问题，暂停任务
任务依赖的任务处于阻塞状态	`pending`	跳转至下一个未被阻塞的任务

当前任务验证通过前，请勿进入下一个任务。

Phase 3: Checkpoint Review

第三阶段：检查点评审

Goal: Pause every 3 tasks to assess progress and quality.

目标： 每完成3个任务暂停一次，评估进度和质量。

Checkpoint Trigger Table

检查点触发表

Condition	Action
3 tasks completed since last checkpoint	Mandatory checkpoint
Logical batch complete (e.g., one component)	Checkpoint recommended
Test failure encountered	Immediate checkpoint
User requests status	Ad-hoc checkpoint

条件	动作
自上一个检查点起已完成3个任务	强制检查点
逻辑批次完成（例如某一个组件开发完成）	建议检查点
遇到测试失败	立即检查点
用户请求查看状态	临时检查点

Checkpoint Steps

检查点步骤

Show progress summary
Run full test suite (not just new tests)
Run lint, type-check, build as applicable
Dispatch
```
code-review
```
skill if significant code was written
Ask user if direction is still correct

展示进度汇总
运行完整测试套件（不只是新增测试）
根据场景运行lint、类型检查、构建命令
如果编写了大量代码，调用
```
code-review
```
skill
询问用户当前方向是否仍符合预期

Progress Report Format

进度报告格式

After each task:

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

After each checkpoint:

── 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]

STOP — Do NOT proceed to next batch until:

Full test suite passes
Checkpoint report presented to user
User has confirmed to continue

每个任务完成后：

[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]

停止 — 满足以下条件前请勿进入下一批次：

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

Phase 4: Batch Review

第四阶段：批次评审

Goal: After completing a logical group of tasks, perform quality review.

Dispatch
```
code-reviewer
```
agent to review the batch
Fix any Critical or Important issues before proceeding
Commit the batch with a descriptive conventional commit message
Update the plan document with completed status

目标： 完成一组逻辑相关的任务后，开展质量评审。

调度
```
code-reviewer
```
agent评审该批次代码
继续执行前修复所有严重和重要问题
用描述清晰的conventional commit信息提交该批次代码
更新计划文档，标记已完成状态

Review Issue Handling

评审问题处理

Severity	Action	Continue?
Critical	Must fix immediately	No — fix first
Important	Should fix before next batch	Conditional — user decides
Suggestion	Note for future	Yes — proceed

STOP — Do NOT start next batch until:

Review issues at Critical severity are resolved
Batch is committed
Plan document is updated

严重级别	动作	是否继续？
严重	必须立即修复	否 — 先修复
重要	应在下一批次开始前修复	待定 — 由用户决定
建议	记录供后续参考	是 — 继续执行

停止 — 满足以下条件前请勿开始下一批次：

严重级别的评审问题已解决
批次代码已提交
计划文档已更新

Phase 5: Completion

第五阶段：完成

Goal: Verify all tasks are done and report final status.

Confirm all tasks have
```
completed
```
status
Run final full test suite
Run all verification commands
Present final summary to user
Invoke
```
verification-before-completion
```
skill

目标： 验证所有任务已完成，汇报最终状态。

确认所有任务状态均为
```
completed
```
运行最终完整测试套件
运行所有验证命令
向用户展示最终汇总
调用
```
verification-before-completion
```
skill

Final Summary Format

最终汇总格式

── 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

── 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

Anti-Patterns / Common Mistakes

反模式/常见错误

Anti-Pattern	Why It Fails	Correct Approach
Marking complete without verification	False progress, bugs accumulate	Run verification command, read output
Tasks larger than 5 minutes	Hard to track, prone to scope creep	Break into 2-5 minute tasks
Skipping checkpoints	Quality degrades, direction drifts	Checkpoint every 3 tasks
Running only new tests	Regressions go undetected	Full test suite at checkpoints
Parallelizing dependent tasks	Race conditions, merge conflicts	One task at a time unless truly independent
Proceeding past blocked tasks silently	User unaware of skipped work	Report all blockers explicitly
Not committing at batch boundaries	Large, hard-to-review changesets	Commit after each logical batch
"It works, I'll verify later"	Later never comes	Verify NOW

反模式	失效原因	正确做法
未验证就标记完成	进度虚假，bug累积	运行验证命令，读取输出确认
任务耗时超过5分钟	难以跟踪，容易出现范围蔓延	拆分为多个2-5分钟的任务
跳过检查点	质量下降，方向偏离	每3个任务开展一次检查点评审
只运行新增测试	回归问题无法被发现	检查点阶段运行完整测试套件
并行执行有依赖的任务	出现竞态条件、合并冲突	一次仅执行一个任务，除非完全独立
跳过阻塞的任务却不告知	用户不知道有工作被搁置	明确上报所有阻塞问题
批次边界不提交代码	变更集过大，难以评审	每个逻辑批次完成后提交代码
"能用就行，之后再验证"	之后永远不会验证	现在就验证

Anti-Rationalization Guards

反合理化约束

<HARD-GATE> NO TASK MARKED COMPLETE WITHOUT VERIFICATION. Run the verification command. Read the output. Confirm it matches expectations. Only then mark complete. </HARD-GATE>

If you catch yourself thinking:

"The code looks right, I don't need to run it..." — Run it. Always.
"I'll batch the verifications..." — No. Verify each task individually.
"This task is trivial, it obviously works..." — Prove it with verification.

<HARD-GATE> 未验证的任务不得标记为完成。运行验证命令，读取输出，确认符合预期后再标记完成。 </HARD-GATE>

如果你发现自己有以下想法：

"代码看起来没问题，我不需要运行..." — 一定要运行，每次都要。
"我可以批量验证..." — 不行，每个任务都要单独验证。
"这个任务很简单，肯定能跑通..." — 用验证结果证明。

Integration Points

集成点

Skill	Relationship	When
`planning`	Upstream — provides approved plan	Task list source
`executing-plans`	Complementary — handles plan execution flow	Can be used together
`test-driven-development`	Per-task — TDD cycle for code tasks	Every code task
`verification-before-completion`	Per-task — verification gate	Before marking any task complete
`resilient-execution`	On failure — retry with alternatives	When task verification fails
`code-review`	At checkpoints — batch quality review	Every 3 tasks or batch boundary
`subagent-driven-development`	Alternative — parallel execution path (via `Agent` tool)	For independent task batches
`Agent` tool	Dispatch mechanism for all subagent work	When parallelizing independent tasks
`circuit-breaker`	Safety net — detects stagnation	When tasks repeatedly fail

Skill	关系	触发时机
`planning`	上游 — 提供获批计划	任务列表来源
`executing-plans`	互补 — 处理计划执行流程	可搭配使用
`test-driven-development`	单任务层面 — 代码任务的TDD周期	所有代码任务
`verification-before-completion`	单任务层面 — 验证关口	标记任何任务完成前
`resilient-execution`	失败时 — 用备选方案重试	任务验证失败时
`code-review`	检查点层面 — 批次质量评审	每3个任务或批次边界
`subagent-driven-development`	替代方案 — 并行执行路径（通过 `Agent` 工具）	独立任务批次
`Agent` tool	所有子agent工作的调度机制	并行执行独立任务时
`circuit-breaker`	安全网 — 检测停滞	任务反复失败时

Concrete Examples

具体示例

Example: Task Extraction from Plan

示例：从计划中提取任务

Plan step: "Add user registration endpoint with validation"

Extracted tasks:

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

计划步骤："Add user registration endpoint with validation"

提取的任务：

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

Example: Blocked Task Report

示例：阻塞任务报告

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.

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.

Key Principles

核心原则

One task at a time — Do not parallelize unless tasks are truly independent
Verify after each task — Run the verification command before marking complete
Checkpoint regularly — Every 3 tasks, pause and assess
Track everything — No task without a status
Small commits — Commit after each logical batch

一次仅执行一个任务 — 除非任务完全独立，否则不要并行执行
每个任务完成后验证 — 标记完成前运行验证命令
定期设置检查点 — 每3个任务暂停评估一次
所有内容都要跟踪 — 所有任务都要有状态
小粒度提交 — 每个逻辑批次完成后提交代码

Skill Type

Skill类型

RIGID — Follow this process exactly. Every task gets verified. Every 3 tasks get a checkpoint. No exceptions.

刚性 — 严格遵循该流程。每个任务都要验证，每3个任务都要设置检查点，无例外。