---

name: plan description: 为复杂任务创建详细实施计划。触发词：计划、规划、plan。

/plan

模板分类: Path Resolution

为复杂任务创建详细实施计划。

输入

• $1 (task_id): 任务追踪 ID
• $2 (task_description): 任务详细描述

指令

1. 分析任务: 理解需求和范围
2. 研究代码库:
   • 使用搜索工具查找相关实现、模式和示例
   • 了解模块关系和影响范围
3. 发现问题关系:
   • 检查依赖和相关工作
   • 识别前置工作、相关上下文、下游影响
4. 识别受影响组件: 确定需要更改的系统部分
5. 设计解决方案: 考虑架构、模式和最佳实践
6. 创建计划文档: 按以下结构

计划文档结构

Copy# 实施计划: {任务标题}

**任务 ID**: {task_id}
**创建时间**: {ISO 时间戳}

## 目标

简要说明需要完成什么（2-3 句）。

## 问题关系

- **依赖**: #{issue_number} ({简短标题}) - {简要理由}
- **相关**: #{issue_number} ({简短标题}) - {共享上下文}
- **阻塞**: #{issue_number} ({简短标题}) - {启用什么}

## 当前状态

与此任务相关的当前代码库状态描述：
- 现有文件及其用途
- 当前架构模式
- 可能受影响的相关功能

## 提议更改

### 1. {组件/文件名}
- **操作**: 创建/修改/删除
- **位置**: src/path/to/file.ts
- **理由**: 为什么需要此更改
- **细节**: 具体实现说明

### 2. {下一个组件}
...

## 测试策略

如何验证更改：
- 要添加/修改的单元测试
- 需要的集成测试
- 手动测试步骤
- 验证命令

## 回滚计划

如果需要如何回退：
- 要回退的提交
- 要回滚的数据库迁移（如适用）
- 要撤销的配置更改

## 依赖项

任何外部依赖或阻塞项：
- 需要的新包
- 要添加的环境变量
- 需要的基础设施更改

## 实施顺序

推荐的更改执行顺序：
1. 第一组更改（基础性）
2. 第二组更改（基于第一组）
3. 最终更改和验证

## 验证命令

实施后要运行的命令：
- lint 检查
- 类型检查
- 单元测试
- 集成测试
- 构建

输出格式要求

创建计划文件后，仅返回文件路径作为纯文本单行。

不要包含:

• 解释性文本
• Markdown 格式
• 引号或其他标点

正确输出:

Copydocs/specs/plan-abc123.md