用途：在收到代码审查反馈时使用，典型场景是 superpowers-evaluator 对某个批次返回 REWORK、需要修复评估报告中的返工项，或接收任何代码审查反馈。其目标不是取悦评估者，而是修对问题。
核心原则：先验证再实现，先询问再假设；技术正确性高于社交舒适度。评估者是红队审查者，不是下命令的人。
响应模式（每项返工都先走一遍）：READ 完整读完返工项（file:line、失败原因、纠正措施）而不立刻反应；UNDERSTAND 用自己的话复述技术要求，或重读返工所引用的清单条目；VERIFY 对照代码库现状检查该断言是否成立，被引用的 file:line 是否真的这么说；EVALUATE 判断纠正措施对当前代码库是否技术合理；RESPOND 用技术性确认或有理有据的反驳回应，绝不做表演式认同；IMPLEMENT 一次只改一项，每项改完重新验证，再重新触发评估者。
禁止的回应：即使评估者是对的，也不要输出“You're absolutely right!”“Great point!”“Excellent feedback!”“Thanks for catching that”之类措辞，不要未经验证就说“Let me implement that now”，不要表达感谢或表演式认同。替代做法是复述技术要求、不清楚就提澄清问题、有误就用技术理由反驳，或直接修好并展示 diff。
处理不清楚的条目：若任一条目不清楚，不要先做清楚的那些而把不清楚的搁置，因为它们可能相互关联，理解不全会导致错误实现。应先重读所引用的清单条目；仍不清楚则在返回中注明歧义，待其解决后再实现其余项，或按冲刺契约的自主解决协议以最具体解释将其标记为 [AUTO-RESOLVED]。
何时反驳：当返工项破坏评估者未见到的既有功能、引用了不适用于本批次范围的清单条目、违反 YAGNI（修复引入了无人使用的功能）、对本技术栈而言不正确、与计划 ## Global Constraints 块中记录的先前的架构决策冲突，或评估者误读了文件（file:line 的表述与报告声称不符）时，应基于技术理由而非防御心态反驳。返回时引用可用的测试或与之矛盾的明确 file:line，说明已验证与无法验证之处；若涉及架构，提请主 agent 考虑 PIVOT。若评估者是对的而自己错了，应事实性地说明纠正并继续，不做长篇道歉，也不辩解此前为何反驳。
多条目返工的实施顺序：先澄清所有不清楚的条目（重读清单条目）；再按顺序实现——阻塞性问题（破坏测试、安全、正确性）、简单修复（拼写、导入、缺失的守卫）、复杂修复（重构、逻辑变更）；每完成一项修复就重跑该任务的验证命令（依据 verification-before-completion）；只有当所有条目都已处理且本轮验证通过后，才重新触发 superpowers-evaluator 进入下一轮。
底线：评估者的 REWORK 是待评估的发现，不是必须服从的命令。逐项对照代码库验证，质疑错误的，逐项实现正确的并加以验证；不要表演式认同，不要盲目批量实现。
限制：资料未提供该技能的安装命令、平台兼容范围、是否收费或具体适用技术栈等信息，暂未提供。