用户明确要求编码任务计划时…

当用户明确要求为编码任务制定计划时，快速理解上下文并输出简洁、可执行的实施计划。

适用场景

解决思路

1. 将用户提示转化为单一、可执行的计划，并只在最终助手消息中交付。
2. 全程以只读模式操作，不写入或更新任何文件。
3. 快速扫描上下文：阅读 README.md 以及明显文档（docs/、CONTRIBUTING.md、ARCHITECTURE.md）。
4. 略读最可能被改动的相关文件。
5. 识别约束：语言、框架、CI/测试命令、部署形态。
6. 仅在阻塞时追问：最多问 1–2 个问题。
7. 只在无法负责任地制定计划时追问；优先使用多选题。
8. 如果不确定但未被阻塞，做出合理假设并继续。
9. 使用下方模板创建计划：先写 1 段简短文字说明意图和方法。
10. 清楚、简短地列出范围内与范围外。
11. 然后提供小型行动项清单，默认 6–10 项。
12. 每个清单项应是具体行动，并在有帮助时提及文件/命令。
13. 让条目原子化且有序：发现 → 变更 → 测试 → 发布。
14. 以动词开头：添加…、重构…、验证…、发布…。
15. 适用时至少包含一项测试/验证，以及一项边界情况/风险。
16. 如有未知项，包含小型的 Open questions 部分，最多 3 个问题。
17. 不要在计划前加元解释；只按模板输出计划。
18. 严格按 Plan template 输出：以 # Plan 开头，接 1–3 句话说明要做什么、为什么、高层方法；然后是 ## Scope，含 - In: 与 - Out:；再是 ## Action items，含 [ ] <Step 1> 到 [ ] <Step 6>；最后是 ## Open questions，含最多 3 个问题。
19. 编写清单项时，用好的做法：指向可能文件/模块，如 src/...、app/...、services/...。
20. 命名具体验证：如运行 npm test、为 X 添加单元测试。
21. 相关时包含安全发布：功能开关、迁移计划、回滚说明。
22. 避免模糊步骤，如处理后端、做认证。
23. 避免过多微步骤。
24. 避免写代码片段，保持计划与实现无关。

适用边界 · 注意事项

• 用户没有明确要求计划时不要使用。
• 任务不是编码任务时不要使用。
• 需要直接修改/写入文件或执行实现时不要使用，因为流程全程只读。