核心用法
fix 是一个用户行为反馈驱动的自我修正技能，通过 fix: 前缀触发（如 "fix: 为什么没提交？"）。执行严格的 5 步闭环：
1. Step 0 (TodoWrite) — 强制注册 4 项任务（根因分析→规则修复→恢复工作→收尾），禁止删除历史任务
2. Step 1 (5-Why 根因分析) — 递归 grep + RAG 语义搜索识别复发模式，强制深挖至 Why 5（结构性缺陷源头）
3. Step 1.5 (行动计划表) — 每项 Why 映射到具体文件位置，多 spot 枚举防止遗漏
4. Step 2 (Prompt 改进) — 4-filter 门槛决定修复介质（memory→rule→hook），--plan 模式支持预审核
5. Step 3 (Resume 原始工作) — 推断用户原始意图，复现验证环境，解决被拒问题
6. Step 4 (收尾) — 按介质分离待办（可执行→TaskList / 阻塞→fix_plan.md），状态修剪任务
显著优点
- 防止复发优先：不修症状修结构，Why 4-5 定位技能/规则/Hook 层面的系统性缺陷
- 强制可追溯：TodoWrite 为硬性门控，文本输出前必须完成工具调用
- 复发升级矩阵：1-2 次→memory feedback；3 次→rule 文件；4 次+→Hook 自动化
- Resume 完整性：强制声明依赖与基准 commit，防止修复后工作流断裂
潜在缺点 / 局限性
- 流程重量：即使"简单 typo"也须完整执行 5 步，时间成本高
- 工具依赖重：依赖 RAG、Grep、TodoWrite、TaskCreate、多文件读写，环境适配复杂
- 递归风险：
fix触发新fix时需手动处理任务链合并，易遗漏历史任务 - Antigravity 特例：Gemini 环境需用
task.mdartifact 替代 TodoWrite，增加分支逻辑
适合人群
- 高可靠性要求的 AI Agent 开发者：需要系统性错误追踪而非单点修复
- 多轮对话长 session 场景：Resume 机制确保复杂任务中断后可恢复
- 规则/Hook 驱动架构：已有 infrastructure 支撑分级修复介质升级
常规风险
- 任务数据丢失：TodoWrite 数组覆盖特性若未携带历史任务会导致全量清空（HARD STOP 防护）
- Why 分析浅层化：未达 Why 5 即进入 Step 2，导致复发（有 Completion Gate 但需自律）
- RAG/grep 双轨遗漏：仅执行其一可能误判复发状态，影响升级矩阵决策
- Resume 范围窄化：自动分类 Reject findings 可能剥夺用户覆盖权，需显式呈现全部选项