关于 fix-bug
用于排查缺陷和进行小幅改进的编码 Agent 技能，强调先确认可验证的原因，再实施精简修复。若改动影响产品行为或架构，则先征求用户决定。
主要功能
- 01修复前验证原因
- 02优先使用项目现有能力
- 03产品或架构决策先询问
- 04检查分支状态与项目规范
- 05保持改动小且便于审查
适用场景
- 01修改代码前诊断缺陷
- 02进行聚焦且不改变行为的改进
- 03检查修复对迁移或架构的影响
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/fix-bug确认已加载。
详细介绍
错误修复与小幅改进
每次修改时，都要牢记项目声明的原则（如果有 PRINCIPLES.md、AGENTS.md、CONTRIBUTING.md 或类似文件）；无论项目是否有这些原则，都要遵循以下原则：先采集数据，再做判断；优先使用代码已有的能力；从预期结果出发，而不是从拟议的实现机制出发。
如果项目有 docs/acceptances/ATTENTION.md，也要阅读它，了解验收测试中的系统性经验。如果某个错误符合其中记录的条目，那就是某种模式的一个实例：修复这个实例，并说明这一点，让模式记录不断完善。
绝不要擅自作出产品决策。 即使是小幅修复，也可能改变客户看到的内容或产品行为——例如错误消息、边缘情况的处理结果或默认值。如果修复会造成这类变化，请停下来询问用户最终希望客户获得怎样的体验。说明你的建议及其理由，由用户决定。
大范围影响的改动也同样如此。 架构变更、新增依赖、数据模型或领域模型变更——任何需要深入了解系统且难以撤销的改动，都不应在未先询问的情况下作为错误修复的一部分。用简单明了的方式提问：每个问题只涉及一个决策，说明每个选项的含义，并给出你的建议。
在规划持久化架构或格式变更前，必须先告知用户。 每次提升持久化架构或格式的版本，以及新增任何迁移——包括数据库架构、文件格式、线缆或同步格式、设置布局——都要明确告知用户，例如“这会更改数据库架构”（或“……文件格式”），并在任何内容依赖该变更之前获得用户同意。迁移会写入其涉及的每个存储位置，而且很少会回滚，因此必须提前作出决定，不能等到实现时才让用户意外发现。首次运行包含这类变更的版本之前，请提醒用户将其隔离运行：使用可丢弃的数据——单独的数据目录、配置文件或测试数据库——绝不要使用共享数据或真实数据。
先与主集成分支核对。 诊断必须基于最新代码：先获取远程更新，并检查当前分支落后主集成分支多少（例如 main 或 dev）——运行 git fetch，然后运行 git log --oneline <branch>..<main>。如果当前分支落后，请说明这一点，并在合并更新前征求用户同意（参见 merge-branch）——合并会改变分支，并需要经过独立的审核流程。无论如何，代码偏移都很重要：错误可能已经修复、代码可能已经迁移，或者错误可能由后来已变更的代码导致，因此不要悄悄调查过时的代码。
修复错误时
- 说明原因。 编写修复前，先说明实际出了什么问题以及原因，确保审核者能够验证。如果原因尚不确定，请先添加监测手段并复现问题——绝不要提交基于猜测的修复。
- 说明方案的理由。 描述修复方案、考虑过的替代方案，以及为什么当前方案更好——更简单、更可靠、更贴合现有模型，或者能消除这一类错误，而不只是修复单个实例。
- 追问问题为何发生。 错误表明系统存在薄弱环节。寻找它揭示的简化方向：重复的机制、缺失的不变量，或无法检查的组件。也要修复或标记这些问题，让代码变得更可靠，而不只是打上补丁。
改进时（以及每次修改代码时）
- 每次修改都是让代码变得更好的机会：改用更清晰的名称、消除重复、为可观测性留出接口。
- 大型文件： 在大型文件中加入改动时，寻找自然拆分的方式——拆成更小的文件、类、函数或模块；提取可复用机制，同时让领域行为留在其所属领域中。不要创建通用的大杂烩。
让改动保持精简且易于审核；如果重构的范围超出修复本身，请单独提出，不要捆绑在一起。