plan

用途

plan 用于把已经评审通过的 spec（规格说明）或已确定的 brief（需求简述）转化为一系列有序任务，交给不同的 agent 运行分别执行。它的定位是规划环节：产出的任务应当让一个全新的 agent 无需再做产品或技术决策就能完成。

主要能力

把工作拆成任务，每个任务交付可运行的行为、适合一次 agent 运行、并产出一个聚焦的拉取请求（PR）。
要求每个任务和里程碑都是纵向切片（vertical slice）：一个贯穿所需层级、可运行且有验收检查的可用成果；按“可用的结果”而非文件、层级或团队边界来拆分。
保持共享契约集中在同一个任务中，不让两个任务各自独立回答同一问题。
当重构会掩盖行为变化时，将其单独分出。
按依赖关系排序任务，必要时把任务分组为里程碑；每个里程碑交付一个端到端的可用结果，并带有验收检查和依赖。不使用“database”“backend”“frontend”这类里程碑。
在计划返回前做两遍检查：人类视角（只读标题和前两节，能否说明会改变什么以及为什么）和 agent 视角（新 agent 能否找到来源、识别依赖和固定决策、实现任务并证明，而无需再问产品或架构问题）。

使用方式

流程如下：

阅读来源、仓库说明和相关代码。
如果某个未决选择会改变行为、接口、数据、安全、规模、性能、兼容性、运维或成本，则停止并返回 /spec。
把工作拆成任务，每个任务交付可运行的行为、适合一次 agent 运行、并产出一个聚焦的 PR。
把共享契约放在一个任务中。不要让两个任务独立回答同一问题。
当重构会掩盖行为变化时，单独分出重构。
按依赖排序任务；必要时把任务分组为里程碑。每个里程碑交付可用的端到端结果，带有验收检查和依赖。不要使用“database”“backend”“frontend”这类里程碑。
在对话中返回计划。仅当用户要求时才创建追踪工单。不要写计划文档。
规划完成后停止。不要实现。

示例：一个任务可以包含“添加任务并在重启后看到它”，涵盖 CLI 输入、校验、存储、输出和测试。后续里程碑可以通过添加、列出、完成这几个切片来交付“管理未完成任务”。为里程碑命名其可观察的结果，以及如何证明整个结果有效。

面向两类读者写作

每个任务由人类阅读、由 agent 执行。

前几节必须让人类在一分钟内理解任务：用日常语言说明具体问题、结果以及为什么重要。不要在此使用需求编号、实现细节、未定义的项目术语，或目标读者不熟悉的缩写。
把任务特有的决策、接口、失败规则和安全约束放在 Agent notes。共享架构和完整需求定义链接到 spec 或已确定的来源。使用能从已发布工单解析的仓库路径或 URL，并在后续编辑可能改变契约时固定已确定的版本。若不存在持久来源，把所需的共享决策写进 Agent notes。不要把整个来源复制到每个工单中。
当任务的目的、边界、依赖、不可协商的决策和证明都清晰时，这个任务是自足的，不需要重复链接来源已解释的背景。

任务格式

使用紧凑格式，省略不提供信息的可选小节：

## <Plain action and result>

### What are we building?
用一到三句短句说明哪里有问题或缺失，以及这个任务之后什么将可用。

### Why?
用一两句短句解释对用户、运维人员或开发者的实际价值。

### Done when
- 三到七个可观察结果。

### How to check
确切的命令和必须的人工检查。

### Agent notes
- Depends on: <任务标题，或 None>
- Source: <持久 spec、brief、issue 或请求路径/URL，必要时固定版本>
- 仅列出该任务特有的定义、决策、约束和失败行为。

### Out of scope
- 该任务容易误吸收的相关工作。

写作规则

使用简短标题，命名一个动作和结果。
使用熟悉的词和具体的动词。
必要的技术术语在首次出现处定义，否则用可观察行为替代。
说“发送同一事件两次只会产生一个回复”，而不是说“证明幂等性”。
说“答案由所引文档支持”，而不是说“证明 grounding”。
默认不加用户故事。仅当它澄清前两节未说明的产品行为时才加。
前两节不要写实现机制。
任务特有的实现选择放在 Agent notes。可互换的本地机制留给实现 agent。
在 Done when 或 Agent notes 中保留适用的 AC-n、REQ-n、INV-n 引用，但不要让读者为了理解任务去解码它们。
每个工单目标 250 到 500 词。只有当额外文字是防止不安全或不兼容实现所必需时才超过 700 词，否则拆分任务或链接共享来源。
不要在多节重复同一事实。
不要使用口号、隐喻、填充语或含糊主张，如 robust、seamless、comprehensive、future-proof。

边界

不要把一种可运行行为拆成按文件或技术层划分的多个任务。
不要创建没有可检查成果的脚手架或清理任务。
不要把未决决策藏在实现工单里。
让每个任务足够小，适合一次 agent 运行和一次聚焦评审。
在 Done when 中说明可观察行为以及必须成立的内部规则。
在 How to check 中，当自动化无法覆盖该行为时，包含确切命令和人工证明。
如果来源使用需求编号，让每个编号附着在同一规则上，不要重新编号或复用。

返回内容

返回有序任务、任何有用的里程碑及其验收检查、它们的依赖，以及任何仍然阻塞实现的决策。不要添加重复任务的单独摘要。