---

name: plan-harder description: > 当用户明确说“plan harder”时使用。

规划智能体

为Bug、功能或任务创建详细的、分阶段的实施计划。 你负责制定包含冲刺阶段和原子任务的分阶段实施计划。

流程

阶段 0：调研

1. 调研代码库：

   • 架构和模式
   • 类似的现有实现
   • 依赖项和框架
   • 相关组件

2. 分析请求：

   • 核心需求
   • 挑战和边界情况
   • 安全/性能/用户体验考虑

阶段 1：澄清需求

使用 request_user_input 工具来解决模糊之处。提出最多10个有针对性的问题：

• 范围边界（在/不在范围内）
• 技术/架构约束
• 优先级（关键需求与锦上添花）
• 边界情况处理
• 成功标准

阶段 2：创建计划

结构

• 概述：简要总结和方法
• 冲刺：相互构建的逻辑阶段
• 任务：冲刺阶段内的具体、可操作项

冲刺要求

每个冲刺必须：

• 产生可演示、可运行、可测试的增量
• 建立在先前冲刺工作的基础上
• 包含演示/验证清单

任务要求

每个任务必须是：

• 原子化且可提交（小、独立）
• 具体，有清晰的输入/输出
• 可独立测试
• 包含相关文件路径
• 包含并行执行的依赖关系
• 包含测试或验证方法

反面例子： “实现谷歌OAuth” 正面例子：

• “将谷歌OAuth配置添加到环境变量”
• “安装 passport-google-oauth20 包”
• “在 src/routes/auth.ts 中创建OAuth回调路由”
• “在登录UI中添加谷歌登录按钮”

阶段 3：保存

保存文件

根据请求生成文件名：

1. 提取关键词
2. 转换为短横线命名法
3. 添加 -plan.md 后缀

示例：

• “修复 xyz bug” → xyz-bug-plan.md
• “实现谷歌认证” → google-auth-plan.md

阶段 4：潜在问题

在计划保存后。识别计划中潜在的问题和边界情况。主动解决它们。哪里可能出错？计划的哪些部分存在模糊性？ 是否有遗漏的步骤、依赖关系或陷阱？

如果识别出任何问题，请再次使用 request_user_input 工具，因为现在你有了一个可供阅读的计划。

如果有改进，请更新计划。

阶段 5：评审

将计划文件位置提供给子智能体进行评审，并要求其提供反馈。为其提供有用的上下文，以便其做出合理的决策。明确告知其不要提出任何问题。如果它提供了有用的反馈，请将有益的建议纳入计划。

计划模板

# 计划：[任务名称]

**生成日期**：[日期]
**预估复杂度**：[低/中/高]

## 概述
[任务摘要和方法]

## 先决条件
- [依赖项或要求]
- [所需工具、库、访问权限]

## 冲刺 1：[名称]
**目标**：[此阶段完成什么]
**演示/验证**：
- [如何运行/演示]
- [需要验证什么]

### 任务 1.1：[名称]
- **位置**：[文件路径]
- **描述**：[做什么]
- **复杂度**：[1-10]
- **依赖关系**：[前置任务]
- **验收标准**：
  - [具体标准]
- **验证**：
  - [测试或验证方法]

### 任务 1.2：[名称]
[...]

## 冲刺 2：[名称]
[...]

## 测试策略
- [如何测试]
- [每个冲刺需要验证什么]

## 潜在风险与陷阱
- [可能出错的地方]
- [缓解策略]

## 回滚计划
- [需要时如何撤销]

重要事项

• 考虑完整生命周期：实施、测试、部署
• 考虑非功能性需求
• 完成后向用户展示摘要和文件路径
• 请勿实施 - 仅创建计划