/plan
模板分类: Path Resolution
为复杂任务创建详细实施计划。
输入
- •
$1(task_id): 任务追踪 ID - •
$2(task_description): 任务详细描述
指令
- •分析任务: 理解需求和范围
- •研究代码库:
- •使用搜索工具查找相关实现、模式和示例
- •了解模块关系和影响范围
- •发现问题关系:
- •检查依赖和相关工作
- •识别前置工作、相关上下文、下游影响
- •识别受影响组件: 确定需要更改的系统部分
- •设计解决方案: 考虑架构、模式和最佳实践
- •创建计划文档: 按以下结构
计划文档结构
markdown
# 实施计划: {任务标题}
**任务 ID**: {task_id}
**创建时间**: {ISO 时间戳}
## 目标
简要说明需要完成什么(2-3 句)。
## 问题关系
- **依赖**: #{issue_number} ({简短标题}) - {简要理由}
- **相关**: #{issue_number} ({简短标题}) - {共享上下文}
- **阻塞**: #{issue_number} ({简短标题}) - {启用什么}
## 当前状态
与此任务相关的当前代码库状态描述:
- 现有文件及其用途
- 当前架构模式
- 可能受影响的相关功能
## 提议更改
### 1. {组件/文件名}
- **操作**: 创建/修改/删除
- **位置**: src/path/to/file.ts
- **理由**: 为什么需要此更改
- **细节**: 具体实现说明
### 2. {下一个组件}
...
## 测试策略
如何验证更改:
- 要添加/修改的单元测试
- 需要的集成测试
- 手动测试步骤
- 验证命令
## 回滚计划
如果需要如何回退:
- 要回退的提交
- 要回滚的数据库迁移(如适用)
- 要撤销的配置更改
## 依赖项
任何外部依赖或阻塞项:
- 需要的新包
- 要添加的环境变量
- 需要的基础设施更改
## 实施顺序
推荐的更改执行顺序:
1. 第一组更改(基础性)
2. 第二组更改(基于第一组)
3. 最终更改和验证
## 验证命令
实施后要运行的命令:
- lint 检查
- 类型检查
- 单元测试
- 集成测试
- 构建
输出格式要求
创建计划文件后,仅返回文件路径作为纯文本单行。
不要包含:
- •解释性文本
- •Markdown 格式
- •引号或其他标点
正确输出:
code
docs/specs/plan-abc123.md