接收反馈

概述

以“验证优先”为准则处理代码审查反馈。

不进行形式上的认同。技术正确性高于社交舒适度。

Orchestrator 依据严格的逐项契约，对反馈项进行验证并应用修复。

若代理支持子代理（subagent），则每个有效反馈项均由一个专用子代理并行处理；否则，Orchestrator 自身按相同修复质量契约（Fix-Quality Contract），逐项顺序执行修复——两种路径必须产出完全一致的结果。

快速参考

┌─────────────┐     ┌──────────────┐     ┌──────────────────────┐
│   VERIFY    │ ──▶ │   CONFIRM    │ ──▶ │   APPLY FIXES        │
│ (tool-based)│     │ ("launch     │     │ (one fix per valid   │
│             │     │  fixes for   │     │  item — parallel     │
│             │     │  1,2,3?")    │     │  subagents if        │
│             │     │              │     │  supported, else     │
│             │     │              │     │  sequential)         │
└─────────────┘     └──────────────┘     └──────────────────────┘

核心原则

先验证，再一次性确认，最后统一应用所选反馈项的修复。

若某缺陷确属有效，则必须修复。仅此而已。不得推迟，不得找借口。当子代理可用时，每个反馈项由一个子代理并行修复；否则 Orchestrator 按相同契约顺序逐项修复。

适用场景

• 接收来自另一 LLM 会话的代码审查反馈
• 处理 PR 审查评论（PR review comments）
• 评估 CI / linter 反馈
• 处理结对编程（pair programming）中提出的建议

工作流

1. 逐项验证：基于当前代码库（使用工具，而非记忆）验证每一项反馈。
2. 分类：将每项反馈明确归类为 VALID（必须修复）或 INVALID（拒绝，并提供证据）。
   • 真正无法解析的项，仅允许提出一次澄清问题。这是唯一例外。
3. 输出简要摘要：列出被判定为 INVALID 的项及其拒绝依据；同时列出 VALID 项并编号。
4. 仅发出一条提示：launch fixes for 1,2,3?（列出所有 VALID 项的编号——默认提案始终为全部 VALID 项集合）。
5. 解析用户回复：
   • 确认类回复（y、yes、go、ok、do it、lgtm 或仅回车 ↵）→ 执行全部默认提案项。
   • 以逗号或空格分隔的数字列表（如 1,3 或 1 3 4）→ 仅执行所列编号项。该列表必须是默认 VALID 集合的子集。用户未提及的项不标记为“延期”，而是在本轮中直接跳过。
   • no / cancel / stop → 中止流程，不执行任何修复。
   • 其他任何输入 → 重新输出一次原始提示；不得自行推断或生成新处置逻辑。
6. 对每个选定项应用修复，严格遵循 Fix-Quality Contract。若代理支持子代理，则为每个选定项并行派发一个子代理（Orchestrator 在此分支下不直接编辑文件）；否则，Orchestrator 自行按相同契约顺序逐项执行修复。两种路径结果必须完全一致。
7. 汇总各反馈项的修复结果，并输出最终响应表格。

禁止行为

以下为不可协商的硬性约束。Orchestrator 不得：

• 向用户询问“哪些项需要修复”。唯一允许的提问是 launch fixes for ?，其中 默认为全部 VALID 项集合。（用户可通过回复自定义数字子集来覆盖该默认值——这是用户主动覆盖，而非代理发起的提问。）
• 声称某问题为既存问题（pre-existing）。只要审查者在本次 PR 中发现该问题，即属本 PR 范围。
• 声称某问题超出本 PR 范围（out of scope）。只要该缺陷存在于当前分支，本 PR 即对其负责。
• 将有效项推迟至“后续”、“待办清单（backlog）”、“后续 PR” 或 “未来工单（future ticket）”。
• 以任何理由——风险、复杂度、耗时、代码扰动（churn）、“轻微”、“美化类（cosmetic）”、“边缘情况（edge case）”等——回避修复有效项。
• 将多个修复打包合并。一项有效反馈 = 一次独立修复（子代理支持时交由一个子代理；否则由 Orchestrator 进行一次聚焦式顺序处理）。
• 在子代理可用时，Orchestrator 直接编辑代码——应将每项修复委托给子代理执行。

由代码审查员或安全审查员提出的有效缺陷，必须修复。别无他选。

硬性关卡（Hard Gates）

必须待当前关卡的通过条件满足后，方可进入下一关卡。详细规则见 VERIFICATION.md、EVALUATION.md 和 RESPONSE.md。

关卡 1 —— 验证证据（逐项）

1. 定位所涉代码或行为（读取对应文件、在代码库中搜索、运行相关测试，或执行 VERIFICATION.md 中定义的其他检查）。
2. 记录验证结果：VALID（主张成立且可操作）或 INVALID（主张不成立），并附带证据（文件路径与行号范围、命令/测试结果、或简短引用的工具输出——不可仅作转述）。
3. 若无法解析，标记为 NEEDS CLARIFICATION 并附上具体问题。不得自行推断处置方式。

通过条件：每项反馈均标注为 VALID / INVALID / NEEDS CLARIFICATION，并附有相应证据。失败（中止）：在无证据情况下继续流程，或将 VALID 项降级为“跳过”/“延期”/“既存问题”/“超出范围”。

关卡 2 —— 单批次确认

1. 输出 INVALID 项（含拒绝依据）及 VALID 项（编号列出）。
2. 发出唯一一条提示：launch fixes for ? —— 必须为全部 VALID 项集合。不得预先缩小范围。
3. 按工作流中的解析规则响应用户回复：确认 → 执行全集；数字子集 → 仅执行该子集；拒绝 → 中止。

通过条件：用户确认或提供所提议数字的子集，且选定集合在进入关卡 3 前已书面锁定。失败（中止）：默认提议缩小后的集合、提问“您希望修复哪些？”、或提议推迟任一 VALID 项。

关卡 3 —— 对选定集合应用修复

1. 每个选定项必须获得一次独立修复，内容包括：原始反馈文本、验证证据、目标文件与行号、以及 Fix-Quality Contract。
2. 若代理支持子代理，需在单个指令块中为每个选定项派发一个子代理，确保其并行运行，且 Orchestrator 不得编辑文件。否则，Orchestrator 自行按相同契约顺序逐项执行修复。

通过条件：用户选定集合中的每一项均已按契约完成修复（子代理支持时为每个项分配一个子代理；否则为每个项执行一次聚焦式顺序修复）。失败（中止）：合并多个修复，或跳过用户实际选定的任一项。

关卡 4 —— 响应产物（批次）

1. 子代理返回结果后，填充 RESPONSE.md 中定义的结构化模板。
2. 响应严格分为两个章节：Implemented（已实现）和 Rejected（已拒绝）。不允许存在 “Deferred”（已延期）章节。
3. 用户在本轮中明确排除的有效项，仅需在表格下方添加一行：Not run this round: (user-excluded)，除此之外不得添加任何内容。不得将其标记为 “deferred” 或 “out of scope”。

通过条件：每项反馈均出现在 Implemented 或 Rejected 章节中，并附带 file:line 引用；所有用户排除的有效项须原样列于表格下方。失败（中止）：输出的摘要遗漏任一项、拒绝项缺乏证据、或擅自引入 “Deferred” 分类。

命令工作流

以反馈文件路径为参数，调用 receive-feedback 技能。

1. 读取 $ARGUMENTS 指定的反馈文件
2. 解析 各反馈项（无论编号、项目符号或自由格式文本）
3. 验证 每一项，依据 VERIFICATION.md
4. 确认：通过唯一提示 launch fixes for ?
5. 应用修复：对每个 VALID 项——子代理可用时各派发一个子代理；否则由 Orchestrator 顺序逐项执行
6. 生成 RESPONSE.md 中定义的响应摘要

预期反馈文件格式

1. 删除第 15 行的未使用导入语句
2. 为 API 调用添加错误处理
3. 对大数据集考虑使用生成器（generator）
4. 修正变量名拼写错误：`usr` → `user`

自由格式文本亦可接受；需从中提取可操作的具体反馈项。

修复派发模板

无论派发子代理还是由 Orchestrator 自行顺序执行，每次修复的简报（fix brief）必须包含：

• 原始反馈文本（逐字保留）。
• 验证证据：文件路径、行号范围，以及已确认的内容。
• 所需的确切变更，或当审查者已明确指定时，表述为“按审查者原文建议实现”。
• 下方 Fix-Quality Contract（应用于每次修复；子代理启用时，需将该契约原文复制进每个子代理提示中）。

Fix-Quality Contract（应用于每次修复）

你正在修复一项代码审查发现。硬性要求如下：

1. 必须完成修复。不得推迟。不得声明任何内容“超出范围”。
   不得称其为“既存问题”。若修复需修改邻近代码才能保证正确性，
   则必须一并修改。

2. 修复必须干净、符合架构设计——符合语言惯例及目标文件周边代码模式。
   编辑前须通读足够多的周边模块，以匹配其编码风格。
   禁止内联补丁（inline hacks）、临时方案（band-aids）、
   或仅为“让测试变绿”的最小改动（"minimum to make it green"）。

3. 禁止过度设计。不得引入新抽象、推测性通用逻辑、辅助层、
   或配置开关。仅解决报告中指出的实际问题。
   若三行代码即可解决，就只写三行。

4. 禁止添加注释，除非未来读者确实会因缺少注释而困惑
   （例如：非显而易见的不变量、针对特定上游 Bug 的规避方案、
   隐式约束）。切勿编写复述代码行为的注释。
   禁止添加标题、分隔横幅、"fix:" 标记、
   或 "// added for review feedback" 类说明。
   过度注释本身即为缺陷——不得产生。

5. 若仓库中存在明显命令，需对所修改文件运行项目类型检查（typecheck）/
   代码规范检查（lint）。报告所执行的具体命令。

6. 返回结果：变更产生的 diff、变更所在 file:line、
   以及一句说明“你做了什么，以及为什么这么做”。

派发子代理时，优先使用通用型子代理；仅当领域专用子代理明显更优时才选用后者。

示例

以反馈文件路径调用 receive-feedback 技能：

receive-feedback reviews/pr-123-feedback.md

该命令将读取文件，逐项验证，输出 INVALID/VALID 摘要，发出提示 launch fixes for 1,3,4?；用户确认后，修复第 1、3、4 项——若子代理可用，则并行启动三个子代理；否则按相同契约顺序执行三次修复。

相关文件

• VERIFICATION.md —— 基于工具的验证工作流
• EVALUATION.md —— 分类规则（VALID / INVALID / NEEDS CLARIFICATION）
• RESPONSE.md —— 结构化输出格式
• references/skill-integration.md —— 与代码审查技能协同使用指南