用途：为缺陷和技术债提供极简流程的修复工作流。GitHub issue 可选，提供可追踪，也可自由描述问题。用于替代 /issue-fix。与旧技能区别：不需要 issue 编号；默认不自动创建 PR（需用 --pr 主动开启）；流程为分支→修复→安全扫描→回归测试→提交。
适用对比：/quick 无流程、规模极小、任意类型；/fix 极简、小到中等、聚焦缺陷或技术债；/implementation 完整流程、中到大、面向功能或重构。issue 在三者中均可选，PR 仅 /fix 和 /implementation 支持，测试方面 /fix 仅写回归测试。
用法示例：/fix "broken login after password change"；/fix --issue 42 "auth regression on mobile"；/fix --pr "memory leak in worker queue"；/fix --issue 15 --pr "null pointer in parser"。
工作流：先分析，若有 issue 则运行 gh issue view <N>。简单修复（根因明确、涉及不超过 2 个文件、无安全影响）直接进入分支；复杂修复会自动进入 Plan Mode，调用 EnterPlanMode，启动 Plan agent（模型 sonnet）产出根因分析、最小改动计划、回归测试策略与安全影响，再调用 ExitPlanMode 等待批准；根因仍不明则先运行 /diagnose。随后创建分支：有 issue 用 git checkout -b fix/<N>-brief-description，无 issue 用 git checkout -b fix/brief-description，并先检查是否存在发布分支。实现遵循最小、安全、防御性三原则。测试需写回归测试，按项目类型运行相应 lint、类型检查与相关测试。提交前必须运行 /security-verify 扫描，然后按是否带 issue 提交。PR 仅在 --pr 或明确要求时用 gh pr create 创建。还需更新 CHANGELOG 的 [Unreleased] 段。最后提供 3–5 项手动冒烟测试清单，并按顺序先建议 /review changes，再按条件建议 /pre-commit。
技术债：当改动隔离、不涉及接口变更、只需更新既有测试、影响限于 1–3 个文件时适合使用 /fix；更大范围用 /implementation，追踪使用 GitHub milestone TECH-DEBT。
限制：其他细节、平台支持与收费方式资料暂未提供。