用途：处理来自其他 LLM、人工评审者或 CI 工具的代码评审反馈，强调“先验证、再确认、后修复”，不做表演式认同，技术正确性优先于社交舒适。
主要能力：对每条反馈在当前代码库中做基于工具的验证（读文件、搜索代码、跑测试等），分类为 VALID（必须修复）、INVALID（附证据驳回）或 NEEDS CLARIFICATION（仅无法解析时提一个澄清问题）。随后打印无效项及证据、编号列出有效项，并只问一个提示：launch fixes for 1,2,3?（默认提议为全部有效项）。用户可确认全部、回复数字子集或拒绝。
使用方式：以反馈文件路径为参数调用该技能，例如 receive-feedback reviews/pr-123-feedback.md。技能读取 $ARGUMENTS 指向的文件，解析编号、项目符号或自由文本形式的反馈项，逐条验证，确认后对每个选中项执行一次隔离修复。若智能体支持子智能体，则每项派发一个子智能体并行修复；否则由编排者按同一契约逐项顺序修复，两者输出应一致。
修复质量契约：必须修复、不得推迟或声称超出范围；修复需干净且符合语言与文件既有风格；不得过度设计；除必要说明外不写注释；若仓库有明确命令则运行类型检查/静态检查并报告；回报 diff、file:line 及一句话说明。
限制与禁止行为：不得询问用户“想修哪些项”，唯一允许的问题是 launch fixes for <numbers>?；不得声称问题预先存在或超出 PR 范围；不得推迟到 backlog、后续 PR 或未来工单；不得以风险、复杂度、时间、改动量、“次要”“外观”“边缘情况”等理由回避修复有效项；不得把多个修复捆绑在一起。最终响应只有 Implemented 与 Rejected 两节，无 Deferred 节；用户本轮明确排除的有效项仅以一行“Not run this round: <numbers> (user-excluded)”列出。
适用场景：接收其他 LLM 会话的代码评审、处理 PR 评审评论、评估 CI/linter 反馈、处理结对编程建议。
限制：具体验证命令、分类细则与输出模板分别见 VERIFICATION.md、EVALUATION.md、RESPONSE.md；与代码评审技能的集成见 references/skill-integration.md。其他平台支持、收费与价格信息暂未提供。