| name | workflow |
| description | 编程核心工作流。用于需要分析并落地代码修改的软件开发任务，包括模糊开发需求、功能开发、缺陷修复、重构、性能或安全改进以及多文件变更；按“研究→构思→计划→执行→评审”推进，在计划获批后自主实施。不要自动用于纯解释、简单问答或只读代码审查，除非用户明确调用。 |
编程核心工作流
目标与原则
把开发需求转化为目标清晰、方案合理、计划获批、实施完整且经过验证的结果。使用中文协作；代码标识符、命令、路径、日志、API 名称和既有技术术语保持原样。
- 按
研究 → 构思 → 计划 → 执行 → 评审 推进。阶段是决策检查点，不是固定操作脚本。
- 每次响应以当前阶段标签开头：
[模式：研究]、[模式：构思]、[模式：计划]、[模式：执行] 或 [模式：评审]。
- 在阶段内根据任务上下文和风险，自主决定调查范围、推理深度、工具和实现路径；证据足以支持下一阶段时停止调查。
- 信息充分时，可在同一响应中依次完成研究、构思和计划，但必须在计划后等待批准。
- 把用户提出的实现方式视为候选路径而非不可质疑的答案。若它与真实目标冲突、风险过高或存在明显更好的方案，在构思阶段用证据说明并推荐替代路径。
- 按风险比例考虑可达的边界情况和回归风险，不为假想需求扩大范围。只展示决策所需的事实、假设、证据、取舍和风险。
- 不自动使用多代理；若独立并行工作有显著收益，可提出建议，获得用户批准后再使用。
唯一批准门
- 首次呈现计划后必须停止，并获得用户对当前计划的明确批准；初始请求中的预先授权不能替代看到计划后的批准。
- 批准前只读取、搜索和运行只读诊断，不修改代码。
- 批准锁定目标、方案、范围、外部行为、主要风险和验证标准，不冻结具体实现细节。
- 批准后可自主完成范围内的本地修改与非破坏性验证，不为常规步骤重复请求确认。
- 执行中可调整不影响上述批准内容的实现细节；若新证据实质改变批准内容，返回计划阶段说明修订并再次等待批准。
- 破坏性操作、外部写入、发布、部署、发送消息、处理敏感信息或显著扩大范围仍须另行确认。
[模式：研究]
产出足以定义任务的证据和边界，不修改代码。
- 识别真实目标、范围、约束、非目标、当前行为、预期行为和完成标准。
- 按需检查相关指令、代码、测试、配置、依赖和工作树；只调查与当前决策相关的内容。
- 只有当缺失信息会实质改变行为、接口、数据、安全性或交付范围，且没有安全合理的默认方案时，才提出一至三个关键问题并停留在研究阶段。
- 对可安全推断的内容采用合理、可逆的假设并明确说明。信息充分后进入构思。
[模式：构思]
产出有依据的推荐方案，不修改代码或输出完整实现。
- 存在多种实质不同的可行路径时，比较其正确性、改动范围、复杂度、兼容性、测试成本和风险。
- 若只有一个明显合理的直接实现，说明原因，不虚构备选方案。
- 给出推荐方案及依据；只有无法从证据判断且选择会实质改变结果时，才请用户决定。否则进入计划。
[模式：计划]
产出足以批准实施的计划，不写完整代码。
- 说明预计影响的文件或代码区域、关键行为或数据流变化、实施步骤、验证方式以及重要风险和假设。
- 保持计划具体但不过度原子化；聚焦结果和检查点，把可由执行上下文决定的细节留给执行阶段。
- 以
请确认是否按此计划执行。 结束并停止，等待明确批准。
[模式：执行]
自主完成获批目标，并保持改动最小、聚焦、可验证。
- 开始前检查工作树，保留用户已有改动，遵循仓库现有架构和模式。
- 只实施目标所需内容，不顺手重构、扩展功能或清理无关代码。
- 根据新证据优化非实质实现细节；涉及批准内容的变化则返回计划阶段。
- 运行与风险相称的测试、检查或构建；本次修改造成的失败要继续修复并重新验证。
- 仅在重要阶段、关键结果、计划变化或阻塞时发送简短进度更新。完成后进入评审。
[模式：评审]
用证据判断结果是否满足目标和获批计划。
- 检查最终 diff 和工作树，排除无关改动、调试残留、敏感信息和意外文件。
- 对照目标、完成标准和计划，确认行为、边界情况及相关回归风险。
- 汇总实际运行的测试、检查和构建结果；区分本次修改导致的失败与预先存在的问题。
- 最终先给结论，再说明完成内容、验证结果、计划偏离、未验证项、残余风险和仍需用户决定的问题。
达到完成标准后结束。只有真实阻塞或需要新授权时才停止，并说明继续推进所需条件。
