plan

计划

创建新 Agent 无需做出产品或技术决策即可完成的任务。每个任务和里程碑都必须是一个纵向切片：贯穿所需层级的可用成果，并附带验收检查。按工作成果拆分，而不是按文件、层级或团队边界拆分。

流程

1. 阅读源文档、仓库说明和相关代码。
2. 如果尚未解决的选择会改变行为、接口、数据、安全性、规模、性能、兼容性、运维、成本或验证方式，请停止并返回 /spec。
3. 将工作拆分为任务，每个任务都交付可运行的行为、适合由一个 Agent 单次完成，并产出一个目标明确的拉取请求。
4. 将共享契约放在一个任务中。不要让两个任务各自独立回答同一个问题。
5. 如果重构会掩盖行为变更，请将重构分开。
6. 按依赖关系排列任务。适用时将任务归入里程碑。每个里程碑都要交付可用的端到端成果，并附带验收检查和依赖项。不要使用“数据库”“后端”或“前端”之类的里程碑名称。
7. 在聊天中返回计划。仅在用户要求时创建跟踪工单。切勿编写计划文档。
8. 规划完成后停止。不要实施。

例如，“添加任务并在重启后仍能看到它”应在一个任务中包含 CLI 输入、验证、存储、输出和测试。后续里程碑可以通过添加、列出和完成等切片，交付“管理未完成任务”的功能。为里程碑命名时，应说明可观察到的成果，以及如何验证整个结果是否正常运行。

为两类读者撰写

每个任务都由人阅读并由 Agent 执行。

开头几节必须让人能在不到一分钟内理解任务。用日常语言说明具体问题、预期成果及其重要性。不要使用需求 ID、实现细节、未定义的项目术语，或目标读者不熟悉的缩略语。

在 Agent 说明中列出任务特有的决策、接口、失败规则和安全约束。对于共享架构和完整需求定义，请链接规范或已确定的来源。使用从已发布工单中可访问的仓库路径或 URL；如果后续编辑可能改变契约，还要固定已确定的版本。如果没有持久来源，请在 Agent 说明中包含必需的共享决策。不要在每张工单中重复粘贴整份源文档。

如果任务的目的、边界、依赖项、不可更改的决策和验证方式都清楚，那么该任务就能独立执行。无需重复链接来源中已经说明的背景。

任务格式

使用以下精简格式。省略不会增加信息的可选部分。

## <Plain action and result>

### What are we building?
In one to three short sentences, say what is wrong or missing and what will work after this task.

### Why?
In one or two short sentences, explain the practical value to a user, operator, or developer.

### Done when
- Three to seven observable results.

### How to check
Exact commands and required manual checks.

### Agent notes
- Depends on: <task titles, or None>
- Source: <durable spec, brief, issue, or request path/URL, pinned when needed>
- Only the definitions, decisions, constraints, and failure behavior specific to this task.

### Out of scope
- Related work this task is likely to absorb by mistake.

写作规则

• 使用简短标题，说明动作和结果。
• 使用常见词语和具体动词。
• 必要的技术术语首次出现时要加以定义。否则，将其替换为可观察到的行为。
• 写“同一事件发送两次只会生成一条回复”，不要写“验证幂等性”。
• 写“答案有引用文档作为依据”，不要写“验证依据充分”。
• 默认不要添加用户故事。只有在用户故事能阐明前两节未说明的产品行为时才添加。
• 前两节不要写实现机制。
• 将任务特有的实现选择放在 Agent 说明中。可互换的本地实现细节交由执行 Agent 决定。
• 在“完成条件”或 Agent 说明中保留适用的 AC-n、REQ-n 和 INV-n 引用，但不要让读者必须解读这些编号才能理解任务。
• 每张工单控制在 250 到 500 字。只有为避免不安全或不兼容的实现确有必要时才超过 700 字。否则应拆分任务或链接共享来源。
• 不要在多个章节中重复同一事实。
• 不要使用口号、比喻、填充语，或“稳健”“无缝”“全面”“面向未来”等含糊说法。

边界

• 不要将一个完整的行为拆分成文件层面或技术层面的多个任务。
• 不要创建没有经过验证的结果作为依据的脚手架或清理任务。
• 不要把尚未解决的决策藏在实现任务中。
• 每项任务都应足够小，能由一个 Agent 在一次运行中完成，并经过一次有针对性的审查。
• 在「完成条件」中说明可观察到的行为，以及必须遵守的内部规则。
• 在「检查方法」中写明准确的命令；如果自动化无法覆盖该行为，则提供手动验证方法。
• 如果源内容使用了需求 ID，请将每个 ID 保留在对应的规则旁。不要重新编号或重复使用 ID。

返回计划之前，请将每项任务读两遍：

1. 人工检查：只阅读标题和前两个部分后，读者能否说明将发生什么变化，以及为什么要做出这些变化？
2. Agent 检查：一个全新的 Agent 能否找到源内容、识别依赖项和已确定的决策、实现任务并验证结果，而无需询问产品或架构方面的问题？

两项检查都通过后，删除重复的背景说明。

返回内容

按顺序列出任务、任何有用的里程碑及其验收检查、任务之间的依赖项，以及仍阻碍实现的任何决策。不要另外添加重复任务内容的摘要。