ask-me

询问我

选择最适合当前情况的最精简工作流。

工作流是贯穿各项技能的一条路径。大多数编码 Agent 工作都从理解需求开始，然后依次进入规划、实现和审查。修复 Bug 时，应先诊断，再规划。

主流程：更改代码

当用户希望添加、修改或移除行为时，使用此流程。

1. /plan-it — 理解目标，检查相关代码，找出受影响的模块，选择方案并定义验证方式。
2. /implement-plan — 分小步进行商定的更改，运行适当的检查，并持续修复，直到验证通过或确认存在实际阻碍。
3. /review-change — 用户要求时，或差异的风险值得审查时，进行独立审查。

对于明确且低风险的实现请求，使用简短的内联计划并直接开始，无需额外征求批准。当范围、设计或风险需要作出决策时，使用完整的规划工作流。只有在调查或审查技能能提供任务所需的证据时，才加载这些技能。

Bug 流程：症状 → 诊断 → 修复

当行为或错误与预期不符，且原因尚未确认时，使用此流程：例如报告功能异常、运行缓慢或行为出乎意料；粘贴的错误或日志；询问“为什么会这样”；或修复未能奏效。

1. /diagnose-bug — 重述症状，判断这是缺陷、预期设计还是环境问题，复现问题，并在修复前确认原因。
2. /plan-it — 原因和验证路径明确后，规划修复方案。
3. /implement-plan — 实施修复并运行验证流程。
4. /review-change — 用户要求时，或修复的风险值得审查时，在全新上下文中进行审查。

编辑前先找出原因。如果用户要求修复，且原因、范围和验证方式都已明确，则继续简要规划并实施，无需再次询问。如果用户只要求诊断，则在诊断后停止。

审查流程

工作完成后、有差异需要检查时，或用户要求审查时，使用 /review-change。

优先针对明确的基准点进行审查，例如 main、某个分支、提交或提供的差异。

上下文管理

计划仍在进行时，保持规划与实现相互衔接。审查时，优先使用全新上下文或子代理，以免审查者受实现者思路的影响。

如果工作需要稍后继续，请提供简短的对话式交接，说明目标、当前状态、验证情况和剩余风险。只有获得用户批准后，才将交接内容保存到文件中。