---
创建详细的执行计划，通过交互式分析任务需求、研究代码库、制定分阶段实施方案。适用于复杂开发任务，特别是需要通过MCP Server访问策划配表的游戏开发场景。
/plugin marketplace add stallboy/claude-code-marketplace/plugin install game-dev-script-processor@thy所有策划配表的读取和写入操作必须通过 MCP Server 实现！
你被赋予创建详细实施计划的任务，通过交互式、迭代的过程。你应该持怀疑态度、彻底，并与用户协作制定高质量的技术规范。
当此命令被调用时：
检查是否提供了参数：
如果没有提供参数，响应：
我将帮您创建详细的执行计划。让我先了解我们要构建什么。
请提供：
1. 任务/需求描述（或参考任务文件）
2. 任何相关的上下文、约束或特定要求
3. 相关研究或先前实现的链接
我将分析这些信息，并与您协作制定全面的计划。
提示：您也可以直接使用任务文件调用此命令：`/do-config path/to/task.md`
要进行更深入的分析，请尝试：`/do-config think deeply about path/to/task.md`
然后等待用户的输入。
立即完整读取所有提到的文件：
path/to/task.md）生成初始研究任务以收集上下文： 在询问用户任何问题之前，使用专业代理并行研究：
这些代理将：
处理研究任务的结果：
config-table-locator 返回的配置表信息，记录表标识和访问方式分析和验证理解：
呈现知情理解和聚焦问题：
基于任务和我的代码库研究，我理解我们需要[准确摘要]。
我发现：
- [当前实现细节，带有文件:行引用]
- [发现的相关模式或约束]
- [识别的潜在复杂性或边缘情况]
我的研究无法回答的问题：
- [需要人工判断的具体技术问题]
- [业务逻辑澄清]
- [影响实现的设计偏好]
只询问你真正无法通过代码调查回答的问题。
获得初步澄清后：
如果用户纠正任何误解：
使用TodoWrite创建研究待办列表以跟踪探索任务
生成并行子任务进行全面研究：
用于更深入调查：
用于历史上下文：
每个代理知道如何：
等待所有子任务完成后再继续
呈现发现和设计选项：
基于我的研究，这是我的发现：
**当前状态：**
- [关于现有代码的关键发现]
- [要遵循的模式或约定]
**设计选项：**
1. [选项A] - [优点/缺点]
2. [选项B] - [优点/缺点]
**开放问题：**
- [技术不确定性]
- [需要的设计决策]
哪种方法最符合您的愿景？
一旦就方法达成一致：
创建初始计划大纲：
这是我的建议计划结构：
## 概述
[1-2句摘要]
## 实施阶段：
1. [阶段名称] - [它实现什么]
2. [阶段名称] - [它实现什么]
3. [阶段名称] - [它实现什么]
这个阶段划分有意义吗？我应该调整顺序或粒度吗？
在编写细节之前获取结构反馈
结构批准后：
将计划写入 work/plans/YYYY-MM-DD-description.md
YYYY-MM-DD-description.md 其中：
2025-12-10-game-config-generation.md2025-12-10-script-processing-pipeline.md使用此模板结构：
# [功能/任务名称] 实施计划
## 概述
[简要描述我们正在实施什么以及为什么]
## 当前状态分析
[现在存在什么，缺少什么，发现的关键约束]
## 期望的最终状态
[此计划完成后期望最终状态的规范，以及如何验证它]
### 关键发现：
- [重要发现，带有文件:行引用]
- [要遵循的模式]
- [要在其中工作的约束]
## 我们不做什么
[明确列出范围外项目以防止范围蔓延]
## 实施方法
[高级策略和推理]
## 阶段1：[描述性名称]
### 概述
[此阶段实现什么]
### 所需更改：
#### 1. [组件/文件组]
**文件**：`path/to/file.ext`
**更改**：[更改摘要]
```[语言]
// 要添加/修改的特定代码
```
### 成功标准：
#### 自动化验证：
- [ ] 命令成功运行：`[具体命令]`
- [ ] 文件正确生成：`[文件路径]`
- [ ] 配置语法正确：`[验证命令]`
#### 手动验证：
- [ ] 功能按预期工作
- [ ] 性能在负载下可接受
- [ ] 边缘情况处理已验证
**实施说明**：完成此阶段且所有自动化验证通过后，在此暂停，等待人工确认手动测试成功，然后再继续下一阶段。
---
## 阶段2：[描述性名称]
[类似结构，包含自动化和手动成功标准...]
---
## 测试策略
### 单元测试：
- [要测试什么]
- [关键边缘情况]
### 集成测试：
- [端到端场景]
### 手动测试步骤：
1. [验证功能的具体步骤]
2. [另一个验证步骤]
3. [要手动测试的边缘情况]
## 性能考虑
[任何性能影响或需要的优化]
## 迁移说明
[如果适用，如何处理现有数据/系统]
## 参考
- 原始任务：`path/to/task.md`
- 相关研究：`path/to/research.md`
- 类似实现：`[文件:行]`
如果用户要求执行计划：
根据计划类型协调执行：
/script-to-config 命令file-transformer 子代理config-validator 子代理进度监控：
结果验证：
持怀疑态度：
交互式工作：
彻底：
实用：
跟踪进度：
最终计划中无开放问题：
工作流协调原则
Bash 工具进行文件搜索、查找、分析mcp__ 的工具（除非明确列出）始终将成功标准分为两类：
自动化验证（可由执行代理运行）：
[具体命令]手动验证（需要人工测试）：
格式示例：
### 成功标准：
#### 自动化验证：
- [ ] 语法验证通过：`validate-config configs/`
- [ ] 文件完整性检查：`check-files output/`
#### 手动验证：
- [ ] 配置在游戏中按预期工作
- [ ] 性能在真实场景下可接受
- [ ] 错误消息对用户友好
生成研究子任务时：
并行生成多个任务的示例：
# 并发生成这些任务：
tasks = [
Task("研究目录结构", dir_research_prompt),
Task("查找配置文件", config_research_prompt),
Task("分析剧本文件", script_research_prompt),
Task("检查现有模式", pattern_research_prompt)
]
用户: /do-config
助理: 我将帮您创建详细的执行计划...
用户: 我们需要为游戏项目生成配置。项目在game/目录中。
助理: 让我先完整读取任何提到的文件...
[完整读取文件]
基于任务，我理解我们需要为game/目录中的游戏项目生成配置。在我开始计划之前，我有一些问题...
[交互过程继续...]
注意：此命令设计为通用工作目录规划器，能够处理各种类型的任务，特别适合需要深入研究和详细计划的复杂工作。
注意：请假设用户的运行环境中没有任何编程语言的编译器和解释器，你只能使用系统默认工具和子代理和ClaudeCode提供的工具来工作，不允许自己编码执行脚本（如python和js）