| name | spec-fix |
| description | 在需求已经过 `spec-review`、进入修正迭代阶段后，根据 review 结论、缺陷清单或验证失败结果，对既有实现执行增量修正。用于用户要求 fix、根据 review findings 修问题、补齐遗漏的 spec 条目、修复回归或质量问题、继续迭代已完成实现，并且每次修正后都必须同步 `spec.md`、`tasks.md`、`log.md` 时使用。 |
spec-fix
协同技能
在执行本 skill 时，同时遵守 ../../references/full-sdd-lifecycle.md 中 spec-fix 阶段的协同规则。
- 先按本插件
skills/debugging-and-error-recovery/SKILL.md 复现和定位
- 再按本插件
skills/test-driven-development/SKILL.md 补证明与防回归
- 当修正改变长期决策时，补充本插件
skills/documentation-and-adrs/SKILL.md 的沉淀要求
目标
在现有实现基础上做受控的增量修正，而不是重新开始一轮 /apply。
/apply 负责按 tasks.md 顺序完成初始实现/fix 负责在 review 或验证之后，针对明确问题做补丁式修正- 每次
/fix 都必须同步 spec.md、tasks.md、log.md
进入条件
执行前先确认以下条件成立：
- 对应需求目录已存在，且包含
spec.md
- 最好同时存在
tasks.md、log.md；若缺失其中任一，先补齐再修正
- 已经有明确的修正来源，例如 review findings、失败测试、验收缺口、回归问题或用户指定缺陷
- 当前任务属于增量修正，而不是尚未开始的首次实现
若出现以下情况，先停止，不直接改代码：
- 问题描述过于模糊，无法定位到具体行为、路径或验收缺口
- 修正范围已经超出原始 spec，需要先回写
spec.md
- 缺少文档载体，无法满足同步要求
执行顺序
按以下顺序执行，不要把修正、补文档、汇报混成一个模糊动作。
1. 锁定修正输入
先读取最小必要上下文：
- 读取
spec.md、tasks.md、log.md
- 读取 review 结论、失败测试、错误日志或用户点名的问题
- 只补充读取与当前问题直接相关的实现、测试、接口和配置
执行时坚持下面约束：
- 把 review finding、失败用例或验收缺口视为修正入口
- 以代码和运行结果为事实来源，不以口头解释代替证据
- 若修正会改变已确认行为边界，先更新
spec.md，再改实现
2. 判断修正类型
在动手前先判定当前属于哪类 fix：
- Spec 缺口：实现未满足既有 spec
- Quality 缺陷：实现能跑，但存在设计、安全、异常处理或可维护性问题
- 回归问题：之前可用的行为被新变更破坏
- 验证补强：关键路径缺少测试、类型校验、lint 或运行证据
若一个问题跨越多类，先修关键路径，再修外围问题。
3. 实施最小闭环修正
围绕当前问题做最小必要改动：
- 只修改与当前问题直接相关的代码、测试和配置
- 优先修复关键行为，再补必要测试和校验
- 不借
/fix 顺手扩展无关需求
- 若发现问题根因与 spec、任务拆分或历史记录不一致，先停下并同步文档
- 默认先建立失败证据，再提交修复；不要直接凭经验改动
4. 生成验证证据
每次 fix 后都必须给出验证证据。
- 优先使用测试、类型检查、lint、接口调用、页面行为或复现步骤前后对比
- 若修的是 review finding，要明确说明该 finding 如何被关闭
- 若环境限制导致无法验证，明确写出未验证项、阻塞原因和剩余风险
- 若修的是回归问题，至少保留一个能长期防回归的自动化证明
没有证据时，不宣布修正完成。
5. 执行文档同步
文档同步是铁律，每次 /fix 都必须完成。
- 更新
spec.md：仅在修正导致需求边界、验收口径、已知限制或行为说明需要调整时更新
- 更新
tasks.md：记录新增 fix task、状态变化或关闭结果
- 更新
log.md：记录问题来源、修正动作、验证结果、额外发现和后续建议
不要只改代码不改文档，也不要只在汇报里口头说明而不落文档。
6. 汇报下一步
向用户汇报时至少包含：
- 本次修了什么问题
- 对应证据是什么
spec.md、tasks.md、log.md 各自同步了什么- 当前问题是否已关闭，是否建议回到
spec-review 复审
紧急停车
遇到以下情况时立即停止，并明确说明原因：
- 修正会引入新的行为范围，但
spec.md 尚未更新
- 发现 review 结论与代码现状、测试结果相互矛盾
- 为修一个问题必须连带重写大量无关模块
- 缺少
tasks.md 或 log.md，无法满足同步铁律
停止时要说明：
- 当前阻塞点
- 受影响的问题或 task
- 需要先更新哪份文档
- 建议回到
spec-propose、spec-apply 或继续补 fix 输入
硬门控
/fix 只做增量修正，不替代首次实现- 每次
/fix 都必须同步 spec.md、tasks.md、log.md
- 没有明确问题来源时，不开始修
- 没有验证证据时，不宣称修复完成
- 若修正超出既有 spec，先改文档再改代码
质量检查
交付前自行检查：
- 当前修正是否直接对应已知 finding、缺陷或验收缺口
- 改动是否控制在最小必要范围
- 验证证据是否足以证明问题已关闭
spec.md、tasks.md、log.md 是否都已同步- 是否需要建议用户回到
spec-review 做复审
