需要把功能或缺陷落地成实现计划时，产出分 sprint…

当用户要求「make a plan / create a plan / 拆解任务」或显式调用 /planner、/plan 时，用分阶段流程做调研、澄清需求、查文档，产出一份分 sprint 的实现计划文件。

适用场景

解决思路

1. Phase 0 调研代码库：查看架构与模式（architecture and patterns）、已有的类似实现、依赖与框架（dependencies and frameworks）、相关组件。
2. Phase 0 分析需求：梳理核心需求、挑战与边界情况（edge cases）、以及安全/性能/UX 方面的考量。
3. Phase 1 澄清需求：在做任何文档检索之前，先和用户澄清需求，以便缩小范围、帮助找到正确的文档。
4. 先想好 5-10 个能帮你生成最佳计划的问题，再向用户提问。
5. 提问可参考以下类别（示例，不严格也不穷尽，可问任何有帮助的问题，用最佳判断并优先解决歧义与风险）：1) 目标与成功标准；2) 范围与非目标；3) 用户与核心工作流；4) 平台与环境；5) 技术约束；6) 数据与集成；7) 认证与权限；8) 性能与可靠性；9) 测试与验证；10) 任何有帮助的问题。
6. Phase 2 检索文档：当计划涉及任何外部库、API、框架或服务时，用 Context7 skill 拉取最新官方文档，确保步骤版本准确、参数正确、符合当前最佳实践；若没有外部依赖，跳过此阶段。
7. Phase 3 创建计划，按三层结构组织：Overview（简要总结与方法）、Sprints（相互构建的逻辑阶段）、Tasks（sprint 内具体可执行的任务）。
8. 每个 sprint 必须满足：产出可演示、可运行、可测试的增量；建立在之前 sprint 的工作之上；包含 demo/验证清单。
9. 每个 task 必须满足：原子化且可提交（小且独立）；具体且输入/输出清晰；可独立测试；相关时写出文件路径；为并行执行标注依赖；包含测试或验证方法。
10. 按此粒度拆分任务：Bad 例「Implement Google OAuth」；Good 例「Add Google OAuth config to env variables」「Install passport-google-oauth20 package」「Create OAuth callback route in src/routes/auth.ts」「Add Google sign-in button to login UI」。
11. 保存计划文件，文件名从需求生成：提取关键词 → 转成 kebab-case → 加 `-plan.md` 后缀，例如 "fix xyz bug" → `xyz-bug-plan.md`。
12. Phase 4 保存之后再找 gotchas：识别计划中潜在的问题与边界情况并主动处理——哪里可能出错？计划哪里还含糊？是否缺少步骤、依赖或存在坑？
13. 若发现 gotchas，停下来再问最多 3 个问题（用 request_user_input 或直接问）；如果用户补充了有用信息，据此修订计划。
14. 按 Plan Template 生成文档：`# Plan: [Task Name]`，含 Generated（日期）、Estimated Complexity（Low/Medium/High）、Overview、Prerequisites（依赖或前置要求、所需工具/库/权限）；每个 Sprint 含 Goal、Demo/Validation；每个 Task 含 Location（文件路径）、Description、Dependencies、Acceptance Criteria、Validation；最后含 Testing Strategy、Potential Risks & Gotchas、Rollback Plan。
15. 规划时考虑完整生命周期：实现、测试、部署，并考虑非功能性需求。
16. 完成后向用户展示摘要和文件路径。
17. 只创建计划，不要实现（Do NOT implement）。

适用边界 · 注意事项

• 用户要的是直接改代码/落地实现，而不是计划。
• 需求极其琐碎（单文件小改动）时，不必走完整五阶段流程。
• 无法与用户交互澄清需求、也无法追问 gotchas 的全自动场景，Phase 1 与 Phase 4 的提问环节无法执行。