用途
Vibe Debug Fix 用于修复现有功能中的缺陷，尤其适合处理来自真实使用后的粗糙反馈，例如“还是坏的”“没修好”“看起来不对”“感觉不对”，以及回归、此前修复失败、症状反复、环境相关行为、陈旧运行时产物、工具失败或自动化失败等情况。它也适用于首次报告只是示例而非完整复现的 bug，以及调试开始滑向大范围读源码、反复打补丁或频繁换方案，而运行时顺序、产物、清理或环境状态仍未被观察的情形。
该技能是自包含的。当项目规则、文档、工具和可用技能明显适用时可以使用，但不要求依赖任何其他技能来完成调试、修复、验证或交接。
主要能力
- 保留 vibe 意图：保留用户对症状、体验问题、“感觉不对”的观察以及对所给选项的修正原话，再翻译为可观察行为、预期行为、未知项、受影响用户或上下文，以及当前范围的收尾标准。
- 调试台账：为每个当前范围症状维护字段，包括报告症状、预期行为及来源、观察行为及来源、此前尝试及失败或未证实原因、疑似原因、探针或插桩计划与结果、已证实原因、受影响状态空间维度、验证路径、收尾状态。收尾状态只能是 fixed、not-reproduced、deferred、accepted-residual 或 blocked。
- 分析现有行为：在改代码前识别需保留的当前行为，拆分为用户可见输出、内部状态转换、持久化/生命周期行为、外部契约、运行/运行时产物，并标记为保留、有意更改、未知或不适用。
- 来源路由与工具可信度：在编辑不熟悉的外部 API、框架、协议、数据契约、权限、构建、部署或工具行为前，检查权威来源，如官方文档、上游源码、本地项目代码、CLI 帮助、变更日志、可用技能或用户提供的材料。工具失败时按失败命令、失败模式、失败输入形态、服务不可用、缺少权限、陈旧产物或环境不稳定等窄类分类，选择更窄的重试、替代证明或阻塞。
- 状态空间矩阵：对非平凡修复，先把用户示例转为领域通用维度，再命名领域特定案例。维度可包括表示、运行时产物、生命周期、顺序、身份、环境、权限、清理等；对动态、视觉、流式、事件驱动、队列、缓存或生命周期 bug，还应包括时间序列、顺序、重叠事件、按实体身份、重置/取消行为以及最终事件后的陈旧状态清理。
- 控制推测：把影响实现的陈述分类为已验证事实、假设、专家判断、预期结果或证明结果。除非下一步明确是证明步骤、用户接受残余风险或该项在当前修复之外，否则不基于假设、专家判断或预期结果行动。
- 诊断探针：先做有界静态分诊，包括最近源码路径、相关测试、现有日志、产物新鲜度、预期行为来源，以及可用时的一个快速反证检查。只有在有界分诊后仍存在多个活状态解释、静态证明会蔓延到多个文件或运行时路径、原方案被矛盾证据推翻，或反复仅靠源码的修复又收到“还是坏的”时，才触发探针。
- 失败尝试处理：对重复报告或“还是坏的”反馈，先解释上次修复为何没有解决症状，再提出下一个修复；下一个修复必须绑定新证明、源码追踪或状态空间发现。
- 最小已验证切片修复：优先复现；若本地无法复现，使用源码追踪、隔离证明或精确手动证明路径。编辑贴近已证实原因和现有本地模式，保留无关行为。
- 产物新鲜度证明：在让用户复测或宣布运行时问题已修复前，证明被测产物包含该更改，例如重新构建的包或二进制、刷新的开发服务器 bundle、迁移后的本地数据、重新生成的资源、更新的 lockfile、重启的进程、清理的陈旧缓存等。
- 降级验证处理：跳过、不可用、不稳定、环境受限或仅手动的检查不算证明。对每个降级检查选择替代证明、更窄的本地证明加明确残余、用户复测契约、接受残余或阻塞。
- 用户复测契约：当本地证明无法观察当前范围行为时，立即选择替代证明、阻塞、接受残余或完整的用户复测契约，不推迟为“如果需要”。契约需写明精确设置、操作序列、预期观察、产物/版本新鲜度等。
使用方式
工作流包括：连续性预检（恢复、中断、上下文压缩或“继续”请求后，重读最新用户请求、未解决症状、台账状态和下一步证明/行动）；捕获 vibe 意图；可选的可用技能与规则预检；打开调试台账；分析现有行为；路由来源与工具可信度；构建状态空间矩阵；控制推测；在合适时机选择诊断探针；处理失败尝试；修复最小已验证切片；证明产物新鲜度；处理降级验证；在需要时使用具体用户复测契约。
最小可见输出要求：即使即时回答很短、被阻塞、拒绝不安全捷径、没有本地文件可检查，或只处理调试/修复收尾（如仓库历史），也要保持工作流可见。在提出收窄问题、停止、委派或把检查交给用户前，包含紧凑的当前范围记录：当前切片、台账、声明标签、现有行为或状态。
委派诊断：当多个独立假设各自需要有限只读调查，且宿主暴露委派或子代理能力时，可并行展开调查。每个委派单元给一个假设形问题和只读边界，返回带来源的证据供调试台账使用。会改变状态的探针、临时插桩、用户环境复测、编辑和台账所有权仍由协调者负责。
仓库历史边界：调试证明只授权已验证的修复切片，不授权暂存、提交、暂存、重置、修订、版本变更、发布准备或任何其他索引或历史操作。当调试/修复收尾包含仓库变更请求时，先运行脏工作树和索引预检：刷新已暂存、未暂存和未跟踪状态；识别属于已验证修复切片的路径；在暂存或清理前暴露无关或有歧义的脏路径；要求明确的操作特定用户同意，指明操作名称，如 stage、commit、stash、reset、squash、amend、release preparation 或 version bump。通用“修好它”的许可、完成的调试台账或通过的测试都不构成仓库历史变更的同意。
适用场景
- 现有功能修复，用户报告“还是坏的”“没修好”“看起来不对”“感觉不对”等粗糙反馈。
- 回归、此前修复失败、症状反复、环境特定行为、陈旧运行时产物、工具失败或自动化失败。
- 首次报告只是示例而非完整复现的 bug。
- 调试开始滑向大范围读源码、反复打补丁或换方案，而运行时顺序、产物、清理或环境状态仍未被观察。
- 修复可能影响现有行为、契约、状态、权限、产物、生命周期或用户可见输出。
限制
- 不适用于没有现有行为或报告症状的全新功能开发。
- 不适用于已有活跃评审工作流且已足够的纯评审周期。
- 不适用于一般提交、历史改写或发布决策，除非它们是调试/修复收尾的一部分，并针对确切操作单独授权。
- 不适用于没有症状、回归或现有行为风险的一行机械编辑。
- 调试证明不授权仓库历史变更；暂存、提交、暂存、重置、修订等需明确的操作特定同意。
- 跳过、不可用、不稳定、环境受限或仅手动的检查不算证明。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。