用途：fix-fast 是 /fix 的快速变体，针对小型、已充分理解的问题做最小调查量的修复，复杂问题应升级到 /fix-hard。
主要能力与规则：
- 先理解代码：在阅读现有代码前不得编写、规划或修复；用 grep/glob 搜索 3 个以上相似模式并引用 file:line 证据；当 .code-graph/graph.db 存在时运行 python .claude/scripts/code_graph trace <file> --direction both --json；非平凡任务（3 个以上文件）把调查写入 .ai/workspace/analysis/ 并在实现前重读。
- 证据驱动：禁止臆测，每条结论需 file:line、grep 结果或框架文档支撑；声明置信度，>80% 可自由行动，60-80% 先验证，<60% 不建议；证据不足时输出“Insufficient evidence. Verified: [...]. Not verified: [...].”。
- 修复层级问责：不得在崩溃点修复，需追踪从数据源到崩溃点的完整数据流，找到不变量归属层，在拥有该不变量的最低层修复，并审计所有访问点、确认无绕过路径。
- 根因调试：复现、隔离、追踪、假设、验证、修复，禁止猜测与只修症状。
- 估算：使用修正斐波那契 1/2/3/5/8/13/21，输出 story_points 与 complexity，SP>8 应拆分。
使用方式：调用时传入问题描述（$ARGUMENTS）；如有截图或视频，用 ai-multimodal 技能描述问题；用 debugger 子代理定位根因，写分析文件，激活 debug-investigate 与 problem-solving 技能；在改代码前必须通过 AskUserQuestion 向用户展示根因与拟议修复并获得明确批准；实现后用 tester 代理测试，失败则从第 2 步重复；完成后运行 /prove-fix，并向用户总结改动与后续步骤。若在工作流之外调用，必须用 AskUserQuestion 让用户选择继续完整工作流、/prove-fix、/test 或手动继续。连续 3 次修复失败后必须停止并询问用户。
适用场景：小型、孤立、根因可在数分钟内明确的缺陷。
限制：不适用于复杂问题；若根因短时间内不清晰应升级；未提供具体安装命令、收费、平台与效果信息。