用途：该技能用于处理“用户或评审者已给出具体实现方向”的代码改动场景，例如明确要求“这样改”“用方案 B”“照这个补丁思路做”，或需要回应包含直接修复指示和多个选项的评审意见。其核心原则是把每条实现指令视为假设而非必须盲目执行的命令，先验证对问题和约束的理解，再选择最能保持正确性与契约意图的方案，风险只作次要筛选条件。
主要流程与能力：一是拆解指令，区分意图（解决什么问题）、约束（必须满足的边界）与提出的方法（如何解决），并标记各项为强制或可协商；二是在编码前重建实际问题，从代码、测试或评审上下文中找到缺陷或关注点的具体证据，用一两句话精确复述问题。三是评估候选方案，始终评估被请求的方案，并在可行时与至少一个替代方案对比，判断维度包括正确性、兼容性、性能、维护成本和验证覆盖。四是选择并说明理由，优先正确性和行为契约契合，而非机械降低风险；仅在多个候选同样满足契约与意图时才偏好低风险方案；若被请求方案弱于替代方案，应说明原因并提出更好选择。五是编码前先给出简短自析总结，涵盖重建的问题、对比的选项、所选方案及否决其他方案的原因。最后是挑战门禁：当需求或评审意图含糊、冲突，改动可能以不明显方式改变 SQL 语义、兼容性或分布式行为，改动扩大爆炸半径（大范围重构、跨模块行为变化、脆弱变通），或验证计划无法用限定测试证明安全时，应先向用户提问澄清，问题要简洁且能促成决策，不得凭假设推进。
实现阶段：对齐后再编码，保持 diff 最小且聚焦约定意图；行为变更或修复缺陷时补充或更新回归覆盖；仍存在取舍时明确报告残余风险。
适用场景与限制：适用于 TiDB 相关代码评审与修复实施流程。资料未提供安装命令、平台价格或更多具体操作示例，相关事实暂未提供。