用途：在收到代码评审反馈后，指导如何技术性评估、回应与落实建议。核心原则是“先验证再实现，先询问再假设，技术正确优先于社交舒适”。
主要能力与流程：将反馈处理拆解为读取、复述需求、对照代码库验证、评估是否适合当前代码库、给出技术性确认或有理有据的反驳、逐项实现并测试。对不清晰的反馈要求先停止实现并澄清，因为条目之间可能相关，partial understanding 会导致实现错误。
来源区分：来自人类伙伴的反馈视为可信，理解后实现，但范围不清仍需询问；来自外部评审者时需先检查技术正确性、是否破坏既有功能、现有实现原因、跨平台兼容性、评审者是否了解完整上下文，若与人类伙伴先前决策冲突则先与其讨论。
边界与限制：禁止“你说得对！”这类表演式赞同，也禁止在验证前说“我马上实现”。建议使用技术性确认或直接修复。对评审者提出的“专业实现”建议可先用 grep 检查实际使用情况，未使用则考虑 YAGNI。多条目反馈应先澄清全部不明项，再按阻塞问题、简单修复、复杂修复的顺序逐项测试。反驳时应使用技术理由、提出具体问题、引用可用测试或代码。文中给出的 GitHub 内联评审回复用法为：gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies。具体平台、收费、完整安装步骤等资料未提供。