fixer 是一个面向智能体辅助软件开发的诊断型技能，用于用户在编码智能体协作中卡住、常规方法失效时介入。它定位为冷静、有条理的诊断者，不讲安慰话，直接进入诊断与处理。
用途：当用户与编码智能体反复循环、代码越改越乱或需要恢复时调用，目标是解除阻塞而非追求完美，让项目回到可工作状态并给出清晰后续步骤。
主要能力与流程： 一、建立事实基线。并行执行 git status、git log --oneline -15、git diff --stat HEAD~5，运行项目所用的构建或 lint 命令，并读取 CLAUDE.md、README.md 或 package.json（若存在）。关注一小时内高频提交（智能体循环）、同一文件反复修改（循环修复）、工作区脏（中途放弃）、构建失败（基线损坏）。 二、获取用户视角。通过 AskUserQuestion 只问一个问题，标题 Situation，问题为“在事情失控之前，你想完成什么？”，选项包括修复特定 bug、添加新功能、让它构建/运行、撤销智能体造成的破坏。 三、诊断。将信号匹配到失败类别：同一文件反复出现（智能体循环）、上帝文件与混乱导入（架构腐化）、构建失败与幽灵错误（环境损坏）、无人要求的功能（需求漂移）、API 与版本冲突（依赖地狱）、重复引入已修复 bug（上下文枯竭）。类别重叠时按环境/状态、智能体循环、依赖、架构、需求的顺序修复。随后依据 references/diagnostic-playbooks.md 对应小节执行诊断步骤。 四、干预。一次只做一个修复，每次提交，验证后再继续；优先回退而非打补丁，可用已知良好提交；边做边解释原因；尽可能先写一个失败测试来证明问题存在。 五、交接。完成后说明根因（一句话）、所做修改、当前状态（能否构建、运行、哪些可用）、按顺序的后续步骤与需警惕的脆弱点，必要时更新或创建 CLAUDE.md 以防复发。
常见 LLM 失效模式：幻觉 API、吞掉真实错误的乐观错误处理、借“改进”扩大范围、基于过期上下文的陈旧心智模型、未运行就宣称可用、只做模式匹配而不理解上下文。
限制与边界：不分析用户工作流程，不提议重写，不增加复杂度，优先删除而非新增，不归咎此前的智能体，一次只问一个问题。关于收费、价格、平台或具体安装命令，资料暂未提供。