Post-Implementation Review 是一个实现后审查流程，作为独立程序手动运行。根据其说明，自动审查入口应优先使用 code-review，而本技能更适合在实现完成后由人工主动触发。
用途 该技能用于审查已完成的实现，默认应用明显安全的 Bucket I 修复，并在有界范围内尽力反复复查，直到不再存在 Bucket I 项。除非用户明确要求，否则不执行暂存、提交或推送操作。
主要能力
- 确定审查范围：当用户未指定范围时，默认以当前未提交的变更作为范围；检查 git status --short、相关 diff 以及判断变更所需的周边代码；区分本次审查变更引入的问题与既有债务。
- 审查实质性问题：倾向于不报告弱发现；只记录离散、可操作的问题，并附具体受影响路径、触发场景和可能的维护者动作。审查角度包括正确性、状态/生命周期顺序、校验与不变量、类型/模式匹配、所有权边界、集成契约、测试和用户可见回归。当范围内每个变更文件都按此清单检查后，审查通过即完成。
- 按需使用子代理：使用能实质性提升信心的最轻量审查形态，通常不用，有时一个专注审查者，仅在广泛或高风险且具有不同审查角度的变更中使用多个。合适的子代理任务包括对第 2 步任一角度进行全新上下文审查，以及并发、安全/隐私、性能、UI 行为或对不熟悉子系统的广泛侦察。子代理仅用于审查，要求提供简洁发现及证据、受影响路径、触发场景、可能的验证和 Bucket I / Bucket II / Keep As-Is 建议。子代理输出视为线索而非结论，记录发现或应用修复前需自行验证证据。不得使用子代理创建自主审查/修复循环、并发编辑或在有界通过完成后继续审查。
- 运行 Bucket I 清理循环：Bucket I 修复是狭窄、局部、范围内、可机械验证或自明，且不涉及产品、设计、架构、发布、兼容性、改动量或风险判断的修复。默认应用所有当前 Bucket I 修复，除非用户表示仅审查、不要编辑或类似要求。Bucket I 编辑后，重新检查新 diff 和受影响代码路径；如果出现新的 Bucket I 项，则应用并再次复查。在有用时持续进行，直到不再有 Bucket I 项、只剩 Bucket II 决策、验证/范围/上下文阻止安全继续，或再次通过只会造成无谓改动。除非工件是明显死代码（如未使用的导入或损坏的文档链接），否则不应用删除看似有意保留的代码。
- 保留人工决策边界：将更大范围重构、模糊修复、有风险的行为变更和设计选择放入 Bucket II。未经用户明确批准，不实施 Bucket II。如果验证被阻止、不可用或因外部原因失败，则报告并停止；不要以更广泛的静态改动来补偿。
- 验证：在可行时运行最相关的现有验证。优先针对受影响区域进行定向检查，而非广泛昂贵的测试套件，除非变更风险需要。将无关的既有失败与审查修复引入的失败区分开。
使用方式 该技能作为独立程序手动运行。默认以当前未提交的变更作为审查范围，检查 git status --short、相关 diff 和周边代码。默认应用所有当前 Bucket I 修复，除非用户要求仅审查。Bucket II 需要用户明确批准。最终响应需报告：Bucket I 已应用的安全修复（问题、变更文件、验证证据）或无；Bucket II 需要决策（所需决策和主要权衡）或无；Keep As-Is（已检查并有意拒绝的有意义关注点，如有用）；运行的验证及结果；如果跳过或阻止验证，则说明残余风险。
适用场景 适合在实现完成后进行人工触发的质量把关，尤其适合希望自动清理安全小问题、同时保留人工决策边界的场景。也适合需要区分本次变更引入问题与既有债务、并围绕多个审查角度系统检查变更的场合。
限制 不自动暂存、提交或推送，除非用户明确要求。不实施 Bucket II，除非用户明确批准。不使用子代理创建自主审查/修复循环、并发编辑或在有界通过完成后继续审查。验证被阻止、不可用或因外部原因失败时报告并停止，不以更广泛的静态改动补偿。不删除看似有意保留的代码，除非是明显死代码。