用途
duck-patch 用于在修复方向已经明确的前提下，执行范围受控的小型代码改动。它的定位是“补丁执行”，主张先产出最小安全差异。该技能只执行有边界的实现工作，产品决策与架构决策仍由用户负责；如果根因不清晰，应交回 duck-debug（必要时使用 trace 模式），而不是做投机性修改。
主要能力
- 范围澄清：当上下文不完整时，提出 1 至 3 个有针对性的澄清问题；证据缺失时明确陈述假设。
- Duck Ladder（决策阶梯）：在引入新构造之前，停在第一个成立的层级：不需要改动（YAGNI）→ 复用现有本地辅助函数或模式→ 用标准库/原生能力替换→ 使用已安装依赖→ 缩小到最小安全差异→ 最后才新增代码或抽象。
- 改动审批工作流：任何语义性改动都需要执行审批；纯格式、空白改动以及非代码文本文件中的错别字修复需要轻量确认（确认语为“Confirm to proceed with [formatting change/typo fix]?”）。需审批的语义改动包括：代码/逻辑改动、文档/规划改动（README、markdown 文档、ADR、CONTEXT.md、runbook、设计说明，非代码文本文件的错别字修复除外）、配置/模式改动、依赖改动、文件操作（创建、删除、移动）、变更类命令（git commit、install、build、deploy）、为实现/打补丁进行的任务委派。代码文件中的 JSDoc/docstring 改动、解释逻辑的代码注释、配置注释、ADR 与 CONTEXT.md 文档更新、README 中的代码片段示例，均视为语义改动。
- 审批前预检：每次审批请求需包含目标阶段（Phase 1 存根/骨架/接口、Phase 2 接线/集成、Phase 3 具体实现）、阶段契合说明、目标文件、预期行为变化、最小验证检查，并按文件给出格式化差异（文件已存在用时统一 diff；文件不存在则用代码块给出完整内容，文件路径作为标题），每个差异块上方内联注解说明每处改动。
- 审批意向识别：接受“approve”“approved”“ok”“go ahead”“confirm”“yes”，也接受带选项的审批语句（如“Proceed with option B in files X and Y.”）。不将单纯的“continue”、裸选项字母（“B”）、“next”视为审批。
- 阶段规则与范围上限：默认阶段文件上限为 Phase 1 最多 6 个文件、Phase 2 最多 4 个文件、Phase 3 最多 2 个文件。Phase 1 只能包含骨架形状、类型/接口声明、函数/类签名、占位返回/错误/TODO 标记、无业务逻辑的最小空接线；不得包含完整业务逻辑或带副作用的流程。Phase 2 可包含路由注册、依赖注入/容器接线、模块组合、事件挂接及适配粘合层，但不得包含大块新业务逻辑。Phase 3 包含业务逻辑、算法、副作用与完整行为。若范围引入新功能文件，第一次审批必须仅为 Phase 1 存根/骨架/接口；若某文件超出存根意图，需拆为“先存根、后实现”。阶段之间需重新开启执行审批；审批后范围变化需重新开启范围确认。
- 评审疲劳阈值：Phase 1 单次审批总改动行数超过 180 行或单文件超过 90 行；Phase 2 总行数超过 120 或单文件超过 60 行；Phase 3 总行数超过 80 或单文件超过 40 行，则相应降低阶段文件上限或拆分文件为独立审批/更小的顺序编辑。若评审者对同一批中超过 2 个文件要求澄清，下一批至少减少 1 个文件。
- 执行与报告：重述受控范围与预期行为，触及最小的共享修复位置（避免逐个调用点打补丁），复用现有本地辅助函数/模式，应用最小安全差异，运行最小约定的检查，并精确报告改动文件、行为差异、验证结果。输出包括：一行执行计划、最小补丁摘要、一项最小验证检查及结果；如受阻则给出单行阻塞原因与所需输入。
- 子代理模式：当作为无用户通道的子代理运行（例如通过 duckling）时，不应用改动、不运行命令，而是把范围澄清、Duck Ladder 与补丁推导作为分析执行，用“审批包”内容替代“应用最小安全差异”和“运行最小约定检查”，即输出每文件差异块与验证计划，并按宿主包装契约提交（预检 + 差异 + 审批请求 + 状态页脚）。
- 注释与文档完整性：记录持久性的约束、不变量、契约与行为；不要在代码注释或普通文档中叙述开发历史；移除或标记被否决的方案、“以前是这样”的历史、近期变更上下文，以及仅用于说明改动如何产生的评审、测试或会话引用；不要把仅属会话的决策、审批标记或临时标记保留在持久产物中；历史上下文只放在用于记录历史的持久产物中（如 ADR 或 changelog）；测试或评审引用仅在其陈述持久约束或验证要求时保留。
使用方式
当用户提出定点代码编辑请求且范围清晰（或可快速澄清）时激活。流程为：澄清范围（如不完整）→ 应用 Duck Ladder → 执行补丁。执行前的预检必须包含目标阶段、阶段契合说明、目标文件、预期行为变化和最小验证检查；如有字段缺失，需提出一个澄清问题。等待用户明确审批意图后才可进行编辑、命令或任务委派。
适用场景
适用于“应用这个修复”“做一次定点修改”“打这个补丁”“实现这个小改动”等已有明确方向、边界较小的实现任务。
限制
不适用于产品与架构决策；根因不明时应交回 duck-debug 而非做推测性编辑。不得削弱安全性、信任边界、防数据丢失、可访问性或用户明确要求。若验证无法在本地运行，需给出用户应执行的确切命令及预期信号。关于收费、价格、平台等商业信息，资料未提供。