用途：在收到代码审查反馈、准备实施建议之前使用，尤其当反馈不清晰或技术上有疑问时，帮助使用者以技术评估而非情绪化回应处理反馈。核心原则：实施前先验证，假设前先询问，技术正确性优先于社交舒适。
主要能力与流程：按阅读、理解、验证、评估、回应、实施逐项推进；用技术性确认代替表演性同意，禁止“你说得对极了”“好观点”等回应。若反馈有不清晰项，应停止实施并先询问澄清，避免部分理解导致错误实施。实施顺序为先澄清所有不清晰项，再按阻塞问题、简单修复、复杂修复处理，逐项测试并验证无回归。
来源处理：来自协作方的反馈可信，但范围不清仍要问；来自外部审查者应保持怀疑并仔细验证，检查对该代码库是否技术正确、是否破坏现有功能、当前实现理由、跨平台版本兼容性、审查者是否理解完整上下文。对“专业”功能建议做 YAGNI 检查，grep 代码库确认实际使用。
反对与确认：在建议破坏功能、审查者缺乏上下文、违反 YAGNI、技术错误、存在遗留或兼容性原因、与架构决策冲突时可反对，用技术推理、具体问题和有效测试/代码支撑。反馈正确时直接说明修复内容，不道谢、不表演。
限制：资料未提供安装命令、平台支持、许可或收费信息，暂未提供。