用途：在接收代码审查反馈、准备实施建议前使用，尤其当反馈含糊或技术上存疑时。核心原则是先验证再实施，先询问再假设，技术正确性优先于社交舒适。
主要能力：提供一套响应流程——完整阅读反馈、用自己的话复述需求、对照代码库现实核验、评估是否适合当前代码库、作出技术性确认或有理有据的驳回、逐项实施并逐项测试。针对不清晰条目要求先停止实施并请求澄清；针对外部审查者建议前需检查是否技术正确、是否破坏现有功能、现有实现原因、跨平台兼容性及审查者是否了解完整上下文。还包括对“专业实现”建议做 YAGNI 检查（先检索实际调用）。提供多条目反馈的实施顺序：阻塞性问题、简单修复、复杂修复，并逐项测试。
使用方式：按 READ、UNDERSTAND、VERIFY、EVALUATE、RESPOND、IMPLEMENT 流程操作，不输出表演式同意或感谢，直接陈述修复；发现建议有误时用技术理由回应。在 GitHub 内联评论回复时，使用 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies 在评论线程内回复，而非顶层 PR 评论。
适用场景：接收人类搭档或外部审查者的代码审查反馈；处理含糊、错误、与既有架构决策冲突或违反 YAGNI 的建议。
限制：未提供具体安装步骤、命令参数细节或平台支持信息。