fix-fast

[IMPORTANT] 开始前，使用 TaskCreate 将所有工作拆分为小任务——包括为每个文件的读取创建任务。这样可以避免因文件过长而丢失上下文。对于简单任务，AI MUST ATTENTION 询问用户是否跳过。

先理解代码 — 严格门槛：在阅读现有代码之前，不要编写、规划或修复任何内容。

1. 搜索 3 个或更多相似模式（grep/glob）——引用 file:line 作为依据
2. 阅读目标区域中的现有文件——了解其结构、基类和约定
3. 当 .code-graph/graph.db 存在时，运行 python .claude/scripts/code_graph trace <file> --direction both --json
4. 通过 connections 或 callers_of 梳理依赖关系——弄清哪些内容依赖目标对象
5. 对于非简单任务（涉及 3 个或更多文件），将调查结果写入 .ai/workspace/analysis/
6. 实施前重新阅读分析文件——切勿仅凭记忆开展工作
7. 如果现有模式可用，绝不另创模式——严格遵循现有模式，或记录偏离原因

满足以下条件前禁止继续： - [ ] 已阅读目标文件 - [ ] 已检索 3 个或更多模式 - [ ] 已进行图追踪（如果 graph.db 存在） - [ ] 已通过证据验证假设

基于证据进行推理 — 禁止猜测。每项断言都必须有依据。

1. 每项断言都要引用 file:line、grep 结果或框架文档
2. 声明置信度：>80% 可直接行动，60-80% 先验证，<60% 不要提出建议
3. 架构变更必须进行跨服务验证
4. “我没有足够的证据”是有效且符合预期的输出

满足以下条件前禁止继续： - [ ] 证据文件路径（file:line） - [ ] 已执行 grep 搜索 - [ ] 已找到 3 个或更多相似模式 - [ ] 已声明置信度

无证据时禁止使用：“显然”“我认为”“应该是”“可能是”“这是因为” 如果信息不完整 → 输出："Insufficient evidence. Verified: [...]. Not verified: [...]."

• docs/project-reference/domain-entities-reference.md — 领域实体目录、关系和跨服务同步（任务涉及业务实体/模型时阅读）（内容会由 hook 自动注入——阅读前检查是否有 [Injected: ...] 标头）

估算 — 修改后的斐波那契数列：1（简单）→ 2（较小）→ 3（中等）→ 5（较大）→ 8（非常大）→ 13（史诗级，应拆分）→ 21（必须拆分）。在计划 frontmatter 中输出 story_points 和 complexity。复杂度自动推导：1-2=低，3-5=中，8=高，13+=严重。 修复层责任制 — 绝不要在崩溃现场修复。追踪完整流程，在负责该问题的层修复。

AI 的默认行为：在位置 A 看到错误 → 修复位置 A。这是错误的。崩溃现场是症状，而不是原因。

进行任何修复前，必须：

1. 追踪完整数据流 — 梳理数据从来源到崩溃现场经过所有层的完整路径（存储 → 后端 → API → 前端 → UI）。找出错误状态从哪里进入，而不是它在哪里崩溃。
2. 确定不变量的负责方 — 哪一层的契约保证此值有效？该层负责此问题。在拥有该不变量的最低层修复，而不是在使用它的最高层修复。
3. 一次修复，最大限度防护 — 思考：“如果在这里修复，能否通过一次更改保护所有下游使用方？”如果修复需要在 3 个以上文件中添加防御性检查，说明你选错了层——应该再往下找。
4. 确认没有绕过路径 — 确认所有数据流都经过修复点。检查：绕过工厂函数直接构造、克隆或展开时未重新验证、原始数据未封装为领域模型、在模型层之外进行修改。

在以下条件满足前，不得继续： - [ ] 已追踪完整数据流（来源 → 崩溃） - [ ] 已通过 file:line 证据确定不变量的负责方 - [ ] 已审查所有访问位置（grep 计数） - [ ] 已论证修复层的选择（能保护最多使用方的最低层）

反模式（拒绝这些做法）：

• “在崩溃处修复” — 崩溃位置 ≠ 原因位置。向上游追踪。
• “在每个使用方都添加防御性检查” — 分散防护说明选错了层。一个权威修复胜过许多分散的保护措施。
• “两边都修更安全” — 选择一个权威层。在多个层重复检查，会让不变量的责任归属变得模糊。

技能变体： /fix 的变体 — 快速修复，只需最少调查。

快速摘要

目标： 以最少的调查开销，快速修复小型且易于理解的问题。

工作流：

1. 识别 — 根据错误消息快速分析根因
2. 修复 — 直接实施有针对性的修复
3. 验证 — 运行受影响的测试以确认修复

关键规则：

• 调试思维：每项判断都需要 file:line 证据
• 仅用于简单、独立的 Bug — 复杂问题应升级到 /fix-hard
• 尽量缩短调查时间；如果几分钟内仍不清楚根因，应升级

根因调试 — 采用系统化方法，绝不靠猜测和反复试错。

1. 复现 — 用证据确认问题确实存在（错误消息、堆栈跟踪、屏幕截图）
2. 隔离 — 使用二分搜索和图追踪，将范围缩小到具体文件、函数或代码行
3. 追踪 — 沿着数据流从输入追踪到故障点。阅读实际代码，不要推断。
4. 提出假设 — 形成理论并标注置信度百分比。说明哪些证据支持或反驳该理论
5. 验证 — 使用有针对性的 grep 和阅读来检验假设。一次只改变一个变量。
6. 修复 — 解决根因，而不是症状。通过图中的 connections 验证修复不会破坏调用方

绝不要： 无证据地猜测。修复症状而不是原因。跳过复现步骤。

分析技能目录，并在执行过程中启用完成任务所需的技能。

调试思维（不可妥协）

保持怀疑，运用批判性思维和顺序思维。每项判断都需要可追溯的证据和置信度百分比（想法的置信度应超过 80%）。

• 不要假定第一个假设正确 — 使用实际代码追踪进行验证
• 每项根因判断都必须包含 file:line 证据
• 如果无法通过代码追踪证明根因，请说明“假设，未经确认”
• 质疑假设：“这真的是原因吗？” → 追踪实际执行路径
• 检查结论是否完整：“是否还有其他促成因素？” → 检查相关代码路径
• 没有证据时，不要说“应该能修复” — 验证修复确实解决了追踪到的根因

⚠️ 强制要求：置信度与证据门槛

强制要求，重要，务必注意： 对每项声明，都必须标注 Confidence: X%，并提供证据列表和 file:line 证明。 95% 及以上可自由推荐 | **80–94%**需附带说明 | **60–79%**需列出未知项 | 低于 60%：停止 — 收集更多证据。

任务

深入思考，分析并修复以下问题： $ARGUMENTS

⚠️ 修复前验证（不可妥协）： 完成根因分析后，必须通过 AskUserQuestion 向用户呈现调查结果和建议的修复方案，并获得明确批准，然后才能进行任何代码更改。不得静默修复。

工作流

1. 如果用户提供了截图或视频，请使用 ai-multimodal skill 尽可能详细地描述问题，确保开发者能根据描述轻松推断根因。
2. 使用 debugger 子 Agent 查找问题根因，并向主 Agent 汇报。 2.5. 将根因分析写入 .ai/workspace/analysis/{issue-name}.analysis.md。实施修复前重新阅读。
3. 启用 debug-investigate skills 和 problem-solving skills 来处理问题。
4. 🛑 呈现根因和建议的修复方案 → AskUserQuestion → 等待用户批准。
5. 根据调查报告和解决方案开始实施修复。
6. 使用 tester Agent 测试修复并确认其有效，然后向主 Agent 汇报。
7. 如果存在问题或测试失败，从第 2 步重新开始。
8. 完成后，向用户总结更改并简要说明一切，指导用户开始使用并建议后续步骤。

• 修复后，必须运行 /prove-fix — 为每项更改构建代码证明链并提供置信度评分。绝不能跳过。

---

后续步骤（独立调用：必须通过 AskUserQuestion 询问用户。若处于工作流中则跳过。）

强制要求，重要，务必注意 — 不得例外： 如果在工作流之外调用此 skill，必须使用 AskUserQuestion 向用户展示以下选项。不得因为任务看起来“简单”或“显而易见”而跳过 — 由用户决定：

• “继续完整工作流（推荐）” — 我会从此处（已应用修复）开始，判断最合适的工作流。这能确保不跳过 prove-fix、审查、测试和文档步骤。
• “/prove-fix” — 使用代码链路证明修复正确性
• “/test” — 运行测试以验证修复
• “跳过，手动继续” — 由用户决定

如果已处于工作流中，则跳过 — 工作流会负责安排顺序。

收尾提醒

• 重要，务必注意： 开始前使用 TaskCreate 将工作拆分为小型待办任务

• 重要，务必注意： 创建新代码前，在代码库中搜索至少 3 个类似模式

• 重要，务必注意： 每项声明都要引用 file:line 证据（采取行动的置信度须高于 80%）

• 重要，务必注意： 添加最终审查待办任务，以验证工作质量

• 重要，务必注意： 连续 3 次修复尝试失败后停止 — 汇报结果，并在第 4 次尝试前询问用户 强制要求，重要，务必注意： 开始前阅读以下文件：

• 重要，务必注意： 任何修改前，搜索至少 3 个现有模式并阅读代码。若 graph.db 存在，则运行 graph trace。

• 重要，务必注意： 每项声明都要引用 file:line 证据。置信度须高于 80% 才能采取行动；低于 60% = 不得推荐。

• 重要，务必注意： 在计划 frontmatter 中包含 story_points 和 complexity。SP > 8 时拆分任务。

• 重要，务必注意： 追踪完整数据流，并在负责该逻辑的层级修复，而不是在崩溃位置修复。添加 ?. 前审查所有访问位置。