用途：这是红-绿-重构中的重构阶段。实现已用通过的测试确定所需行为后，本技能检查代码是否符合编码规范与原始规格，并应用有支持的重构，同时保持行为不变。
主要能力：两条独立审查轴针对同一初始 diff。Standards 轴检查代码是否符合仓库文档化的编码标准，以及哪些基线坏味道值得重构；Specifications 轴检查代码是否忠实实现原始规格，重构是否保留其要求。审查者收集证据并提出具体改动，协调代理核对证据后执行编辑，再让同一批审查者用原有上下文验证结果。仅要求报告时，审查后即结束，只给发现不改代码。
使用方式：1) 固定起始状态，解析用户提供的固定点（commit、分支、tag、main、HEAD~5 等），无则询问；解析固定点与 HEAD 为 commit ID 并记录 merge-base；用 git diff 捕获起始 diff，读取 git status --short 区分目标工作与无关本地修改，把起始补丁、文件内容、提交列表与审查范围保存到仓库外。2) 确定规格来源，按顺序查找 issue tracker、用户提供的规格、documentation/、specifications/、backlog/、.refinement/ 等。3) 确定规范来源，查找 GUIDELINES.md、CONTRIBUTING.md 等，缺失时调用 domain-modeling 技能；并始终附带 Fowler 代码坏味道基线，仓库文档优先。4) 并行审查，派发独立 Standards 与 Specifications 子代理，各自报告需含稳定标识、文件与 hunk 引用、证据、具体建议及预期行为影响，每份报告不超过 400 词。5) 应用有支持的重构，逐条核对证据，记录接受、驳回或待决；小步保持可观察行为与公共接口，用现有测试作行为基线。6) 用同一批审查者验证，回传补丁与处置结果，按各自轴标记已解决或未决。7) 报告，分 ## Standards 与 ## Specifications 两节列出每条发现的证据、处置、改动与验证状态。8) 询问是否发布及发布位置，发布需用户明确授权。
适用场景：代码重构、提交前审查、结合需求规格做合规检查。
限制：无法确定分类时归为其他；缺失事实如具体收费、平台支持、价格等暂未提供；无规格时跳过 Specifications 轴并报告“no specifications available”；需要行为变更的规格问题应回到红/绿实现阶段，重构不能靠改规格或弱化测试来解决。