name: 创建计划 description: 创建一个简洁的计划。当用户明确要求与编码任务相关的计划时使用。 metadata: short-description: 创建计划
创建计划
目标
将用户提示转化为一个单一、可操作的计划，并在最终助手消息中交付。
最小工作流程
在整个工作流程中，以只读模式操作。不要写入或更新文件。
-
快速扫描上下文
- 阅读
README.md和任何明显文档（docs/,CONTRIBUTING.md,ARCHITECTURE.md）。 - 浏览相关文件（最可能被触及的文件）。
- 识别约束（语言、框架、CI/测试命令、部署形状）。
- 阅读
-
仅在阻止时询问后续问题
- 最多问1-2个问题。
- 仅在无法在没有答案的情况下负责任地计划时询问；首选多项选择。
- 如果不确定但不阻止，做出合理假设并继续。
-
使用以下模板创建计划
- 以1个短段落开始，描述意图和方法。
- 清楚地标出在范围内和不在范围内的内容。
- 然后提供一个小检查清单的行动项（默认6-10项）。
- 每个检查清单项应该是一个具体的行动，并在有帮助时提及文件/命令。
- 使项原子化并有序：发现 → 更改 → 测试 → 推出。
- 动词优先：“添加…”, “重构…”, “验证…”, “发布…”。
- 当适用时，包括至少一个用于测试/验证的项和一个用于边缘情况/风险的项。
- 如果有未知数，包括一个小的开放问题部分（最多3个）。
-
不要用元解释来介绍计划；仅根据模板输出计划
计划模板（精确遵循）
# 计划
<1-3个句子：我们在做什么，为什么，以及高级方法。>
## 范围
- 在：
- 出：
## 行动项
[ ] <步骤1>
[ ] <步骤2>
[ ] <步骤3>
[ ] <步骤4>
[ ] <步骤5>
[ ] <步骤6>
## 开放问题
- <问题1>
- <问题2>
- <问题3>
检查清单项指南
好的检查清单项：
- 指向可能的文件/模块：src/…, app/…, services/…
- 命名具体验证：“运行 npm 测试”, “为 X 添加单元测试”
- 包括安全推出当相关时：特征标志、迁移计划、回滚说明
避免：
- 模糊步骤（“处理后端”, “做认证”）
- 太多微步骤
- 编写代码片段（保持计划实现无关）