Back to Details

task-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Task Plan

任务计划

Turn any input source into a structured backlog that an agent can execute one task at a time in an automated loop. Each task is self-contained, verifiable, and completable in a single iteration.
将任意输入源转换为结构化待办列表，可供Agent在自动化循环中逐个执行任务。每个任务都是独立自包含、可验证的，并且可以在单次迭代中完成。

When to use

适用场景

Invoke when the user has an input source (PRD, design feedback, issue list, requirements doc, or verbal description) and wants it decomposed into executable tasks. The output is a 
backlog.md
file — a flat task list with dependency graph and priority ordering.
当用户拥有输入源（PRD、设计反馈、issue列表、需求文档或口头描述）并希望将其拆解为可执行任务时调用。输出为
backlog.md
文件——一个附带依赖关系图和优先级排序的扁平化任务列表。

Process

执行流程

1. Understand the input

1. 理解输入

Accept input as a file path, URL, pasted text, or verbal description. If none provided, interview the user:
  • What are you trying to build or change?
  • What does the end state look like?
  • What exists today?
  • What constraints matter (timeline, tech stack, compatibility)?
Interview deeply — understand intent, not just surface requirements. The quality of the backlog depends on understanding the why.
接受的输入形式包括文件路径、URL、粘贴的文本或口头描述。如果没有提供输入，向用户询问以下信息：
  • 你想要构建或修改什么内容？
  • 最终的交付形态是什么样的？
  • 当前已有哪些现成的内容？
  • 有哪些重要的约束条件（时间线、技术栈、兼容性要求）？
深入沟通确认——要理解背后的意图，而不仅仅是表面需求。待办列表的质量取决于对「为什么做」的理解程度。

2. Explore the codebase

2. 探索代码库

Before decomposing, explore the codebase to understand:
  • Existing patterns and conventions
  • Architecture and integration layers
  • What already exists that tasks can build on
  • Testing patterns and verification infrastructure
Tasks that ignore existing code lead to rework. An agent executing a task should extend the codebase, not fight it.
在拆解任务之前，先探索代码库以了解：
  • 现有编码模式和规范
  • 架构和集成层级
  • 已有哪些可复用的内容可供任务开发使用
  • 测试模式和验证基础设施
忽略现有代码的任务会导致返工。执行任务的Agent应该对代码库做扩展，而不是和现有逻辑冲突。

3. Surface durable decisions

3. 明确长期决策

Identify decisions that span multiple tasks and are unlikely to change:
  • Route structures / URL patterns
  • Schema shapes and data models
  • Key architectural boundaries
  • Third-party service interfaces
  • Shared component patterns
These go in a 
## Decisions
section at the top of the backlog so every task can reference them without repeating context.
识别跨多个任务、几乎不会变更的决策：
  • 路由结构/URL pattern
  • Schema结构和数据模型
  • 核心架构边界
  • 第三方服务接口
  • 共享组件规范
这些内容会放在待办列表顶部的
## Decisions
部分，这样所有任务都可以直接引用，不需要重复上下文。

4. Ask about reference material

4. 询问参考资料

Ask the user: "Are there docs, skills, or reference material that will help an agent execute these tasks?"
Examples:
  • A Figma workflow doc for design tasks
  • API documentation for integration tasks
  • A testing guide for the project
  • An existing skill relevant to the tech stack
These go in the backlog's reference table so the executing agent knows where to look.
向用户确认：「是否有文档、skill或参考资料可以帮助Agent执行这些任务？」
示例包括：
  • 面向设计任务的Figma工作流文档
  • 面向集成任务的API文档
  • 项目的测试指南
  • 和技术栈相关的现有skill
这些内容会放在待办列表的参考资料表中，方便执行任务的Agent查阅。

5. Decompose into vertical slices

5. 拆解为垂直切片

Break the input into tasks. Each task is a thin vertical slice through all relevant layers (model, logic, API, UI, tests), not a horizontal layer.
Apply these heuristics — read references/task-quality.md for details:
The one-iteration test: Can a fresh agent session complete this task in one loop iteration (~30 min)? If not, split it.
The one-commit test: Does this task produce exactly one coherent commit? If it would need multiple commits, split. If it's too small to commit alone, merge with a sibling.
The cold-start test: Does the task contain enough context (file paths, current state, what to change, how to verify) that an agent with no session memory can execute it? If not, add more detail.
The revert test: Could this commit be reverted cleanly, removing exactly one meaningful thing? If reverting would orphan code or break something unrelated, the task isn't self-contained.
将输入拆分为任务。每个任务都是覆盖所有相关层级（模型、逻辑、API、UI、测试）的细粒度垂直切片，而不是水平分层的模块。
遵循以下判断规则，可阅读 references/task-quality.md 了解详情：
单次迭代校验： 一个全新的Agent会话能否在一次循环迭代（约30分钟）内完成该任务？如果不能，就拆分它。
单次提交校验： 这个任务是否刚好对应一个逻辑自洽的commit？如果需要多次提交，就拆分。如果太小不足以单独提交，就和相邻任务合并。
冷启动校验： 任务是否包含足够的上下文（文件路径、当前状态、修改内容、验证方式），没有会话记忆的Agent也能执行？如果没有，补充更多细节。
回滚校验： 这个commit能否被干净地回滚，恰好移除一项完整功能？如果回滚会产生孤儿代码或者破坏不相关的内容，说明任务不是独立自包含的。

6. Structure each task

6. 结构化每个任务

Each task needs all of these fields:
  • ID — short prefix + number (e.g. AU-1, DB-3). Prefix groups related tasks (CC = cross-cutting, AU = auth, UI = interface, etc.)
  • Title — what changes, not how
  • Size — XS (< 10 min), S (10-20 min), M (20-40 min), L (40+ min). If L, strongly consider splitting
  • Deps — task IDs this depends on, or "none"
  • Problem — what's wrong or missing (the why)
  • What to do — concrete steps with file paths and current state
  • Acceptance criteria — observable outcomes, not implementation details
  • Verification — exact commands to run and what to check. Can reference global verification rules or be task-specific
  • Files — paths that will be touched
Read references/backlog-format.md for the full template.
每个任务都需要包含以下字段：
  • ID — 短前缀+数字（例如 AU-1, DB-3）。前缀用于分组相关任务（CC = 跨领域, AU = 鉴权, UI = 界面等）
  • 标题 — 描述要修改什么，而不是怎么修改
  • 规模 — XS (< 10 分钟), S (10-20 分钟), M (20-40 分钟), L (40+ 分钟)。如果是L级，强烈建议拆分
  • 依赖 — 该任务依赖的任务ID，或者填「none」
  • 问题 — 当前存在什么问题或缺失什么能力（即为什么要做这个任务）
  • 执行步骤 — 附带文件路径和当前状态的具体操作步骤
  • 验收标准 — 可观测的产出结果，不是实现细节
  • 验证方式 — 要运行的具体命令和校验项。可以引用全局验证规则，也可以是任务特有的规则
  • 涉及文件 — 会被修改的文件路径
阅读 references/backlog-format.md 查看完整模板。

7. Add dependency graph and priority order

7. 添加依赖关系图和优先级排序

Draw the dependency graph as a text diagram showing which tasks unblock others. Group tasks into phases where tasks within a phase can be executed in parallel (no mutual dependencies).
Priority order should generally be:
  1. Cross-cutting / foundation tasks (unblock many others)
  2. Quick wins (XS tasks, batch together)
  3. Feature phases (grouped by domain area)
  4. Polish and documentation
用文本框图绘制依赖关系图，展示哪些任务会解锁后续任务。将任务分组到不同阶段，同一阶段内的任务可以并行执行（没有互相依赖）。
优先级排序通常遵循以下规则：
  1. 跨领域/基础任务（可以解锁大量后续任务）
  2. 快速落地项（XS级任务，批量处理）
  3. 功能阶段（按领域分组）
  4. 优化和文档工作

8. Quiz the user

8. 向用户确认

Present the proposed breakdown as a summary. Ask:
  • Does the granularity feel right? (too coarse / too fine)
  • Should any tasks be merged or split?
  • Are the dependencies correct?
  • Is the priority order right?
  • Anything missing?
Iterate until approved, then write the file.
将初步的拆解结果作为摘要展示给用户，询问：
  • 粒度是否合适？（太粗/太细）
  • 是否有任务需要合并或拆分？
  • 依赖关系是否正确？
  • 优先级排序是否合理？
  • 有没有遗漏的内容？
反复迭代直到确认通过，再编写文件。

9. Write the backlog

9. 编写待办列表

Write to the path specified by the user (default: 
TASKS/<name>/backlog.md
). Create the directory if needed.
If the user plans to use 
/task-loop
next, mention that the backlog is ready for loop scaffolding.
写入用户指定的路径（默认路径：
TASKS/<name>/backlog.md
）。如果目录不存在则创建。
如果用户接下来打算使用
/task-loop
，可以提示待办列表已经准备好，可以用于循环初始化。