create-plan

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