用途：plan-fix 是 plan-feature 的修复流程对应技能，从仓库中的一个或多个 GitHub issue 出发，起草范围严格、分阶段的修复 SPEC，并在本地提交后停止，不推送、不创建 PR。修复单元没有 Product 部分，其依据是复现、根因、回归范围与回滚。
主要能力：产出 docs/fix/<primary>-<topic>/SPEC.md（含模板必需章节与 ## Phases 账本，阶段至少 2 个，最后为 Hardening & PR）和 docs/fix/<primary-issue-number>-<topic>/ACCEPTANCE.md（冻结的完成标准，每个 issue 保留一条准则）；SPEC 内含 ### Planning evidence 与 ### Obligations 两个冻结账本，修复行需给出证据：复现、带代码证据的根因、回归范围、回滚路径、受影响的不变量或用例；从 main 创建分支 fix/<primary>-<topic>；将 SPEC 与 docs/fix/README.md 作为一个本地提交提交。
使用方式：输入为当前仓库一个或多个以空格分隔的 issue 编号；单编号行为不变，多编号由第 5 步决定合并为一个能力包还是同质机械批次，合并后仍保留各 issue 的准则。代码证据须经符号/引用搜索（有 LSP/serena 时用之，否则用 grep）定位，不以模型记忆推断影响范围。仅当有界问题无法由仓库证据回答时，才在阶段产出前执行一次网络检索，并冻结 URL 与访问日期为证据行。结束前须逐项核对 turn contract，并原样打印 Hand-off 块，最后打印 → Next: 块与 2-3 句用户语言总结。
适用场景：需要先规划再实施的缺陷修复，尤其是多 issue 合并、需要复现与根因证据、需明确回滚边界的修复。
限制：不推送、不创建 PR；不自行审查自己的计划；READY-FOR-REVIEW 仅是交接许可；缺少必需资源时停止，不近似固定块或阶段规则；交接不得直连 execute-phase；产物语言优先级为显式用户指令 > 项目声明的文档语言 > 英语，会话语言不决定；输入含无效 token 时须指名并停止。其他平台可打开具名 SKILL.md、在最强模型上做架构定界。具体收费、价格、平台支持等资料暂未提供。