当用户明确要求 'plan harder' 时，用于为…

在用户明确说 'plan harder' 时，生成包含研究、需求澄清、sprint、原子任务、验证、风险与回滚的详细实施计划。

适用场景

解决思路

1. 阶段 0 研究：调查代码库，包括架构与模式、相似的现有实现、依赖与框架、相关组件。
2. 阶段 0 研究：分析请求，包括核心需求、挑战与边界情况、安全/性能/UX 考虑。
3. 阶段 1 澄清需求：使用 request_user_input 解决歧义，最多询问 10 个针对性问题。
4. 阶段 1 澄清需求：询问范围边界（in/out of scope）。
5. 阶段 1 澄清需求：询问技术/架构约束。
6. 阶段 1 澄清需求：询问优先级（关键 vs nice-to-have）。
7. 阶段 1 澄清需求：询问边界情况处理。
8. 阶段 1 澄清需求：询问成功标准。
9. 阶段 2 创建计划：结构包含 Overview（简要总结与方法）、Sprints（基于彼此构建的逻辑阶段）、Tasks（sprint 内具体可执行事项）。
10. 阶段 2 Sprint 要求：每个 sprint 必须产出可演示、可运行、可测试的增量。
11. 阶段 2 Sprint 要求：每个 sprint 必须基于前一个 sprint 的工作构建。
12. 阶段 2 Sprint 要求：每个 sprint 必须包含演示/验证 checklist。
13. 阶段 2 Task 要求：每个任务必须原子且可提交（small, independent）。
14. 阶段 2 Task 要求：每个任务必须具体，并明确输入/输出。
15. 阶段 2 Task 要求：每个任务必须可独立测试。
16. 阶段 2 Task 要求：相关时包含文件路径。
17. 阶段 2 Task 要求：包含依赖，以支持并行执行。
18. 阶段 2 Task 要求：包含测试或验证方法。
19. 阶段 2 任务拆分示例：坏例子是「Implement Google OAuth」；好例子拆分为「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」。
20. 阶段 3 保存：保存文件。
21. 阶段 3 保存：从请求生成文件名：提取关键词。
22. 阶段 3 保存：从请求生成文件名：转换为 kebab-case。
23. 阶段 3 保存：从请求生成文件名：添加 `-plan.md` 后缀。
24. 阶段 3 保存：文件名示例：'fix xyz bug' → `xyz-bug-plan.md`；'implement google auth' → `google-auth-plan.md`。
25. 阶段 4 Gotchas：在保存之后，识别计划中的潜在问题与边界情况，并主动处理。
26. 阶段 4 Gotchas：检查可能哪里出错、计划中哪里含糊、是否缺少步骤/依赖/陷阱。
27. 阶段 4 Gotchas：现在有可读计划后，如发现问题，再次使用 request_user_input 工具。
28. 阶段 4 Gotchas：如果有改进，更新计划。
29. 阶段 5 Review：将计划文件位置提供给 subagent 进行评审，并要求其提供反馈。
30. 阶段 5 Review：提供有用上下文，使其能做出合理判断。
31. 阶段 5 Review：明确告诉它不要问任何问题。
32. 阶段 5 Review：如果它提供有用反馈，将有用建议纳入计划。
33. 使用计划模板组织计划文件，模板包含：标题 `# Plan: [Task Name]`、`**Generated**: [Date]`、`**Estimated Complexity**: [Low/Medium/High]`、`## Overview`、`## Prerequisites`。
34. 计划模板的 Overview 下包含：任务与方法的总结。
35. 计划模板的 Prerequisites 下包含：依赖或要求；需要的工具、库、访问权限。
36. 计划模板的 Sprint 部分包含：`## Sprint 1: [Name]`、`**Goal**`、`**Demo/Validation**`。
37. 计划模板的 Demo/Validation 下包含：如何运行/演示；要验证什么。
38. 计划模板的任务部分包含：`### Task 1.1: [Name]`、`**Location**`、`**Description**`、`**Complexity**: [1-10]`、`**Dependencies**`、`**Acceptance Criteria**`、`**Validation**`。
39. 计划模板的 Acceptance Criteria 下包含：具体标准。
40. 计划模板的 Validation 下包含：测试或验证。
41. 计划模板还包含：`## Sprint 2`、`## Testing Strategy`、`## Potential Risks & Gotchas`、`## Rollback Plan`。
42. 计划模板的 Testing Strategy 下包含：如何测试；每个 sprint 要验证什么。
43. 计划模板的 Potential Risks & Gotchas 下包含：可能出什么问题；缓解策略。
44. 计划模板的 Rollback Plan 下包含：如需要如何撤销。
45. 重要：思考完整生命周期：implementation、testing、deployment。
46. 重要：考虑非功能需求。
47. 重要：完成后向用户展示 summary 和文件路径。
48. 重要：不要实现——只创建计划。

适用边界 · 注意事项

• 用户没有明确说 'plan harder' 时不要主动使用。
• 只需简单问答、微小改动或直接实现，不需要分阶段计划时不要使用。
• 环境缺少 request_user_input 或 subagent 工具时，无法按原流程执行澄清与独立评审。