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