receive-feedback

接收反馈

概述

以验证优先的原则处理代码审查反馈。 不做表面附和。技术正确性高于社交舒适度。

编排器在严格的逐项契约下验证并应用修复。 如果 Agent 支持子 Agent，则为每个有效项并行派发一个专用子 Agent 来修复；否则，编排器按照相同的修复质量契约自行逐项依次应用相同的修复，产出相同的结果。

快速参考

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

核心原则

先验证，一次确认，然后应用所选项目的修复。

如果 bug 有效，就必须修复。就这样，不得推迟，不得找借口。如果有子 Agent 可用，则由一个子 Agent 并行修复每个项目；否则，编排器按照相同的契约逐项依次修复。

适用场景

• 接收来自另一个 LLM 会话的代码审查意见
• 处理 PR 审查评论
• 评估 CI／linter 反馈
• 处理结对编程中的建议

工作流

1. 根据当前代码库验证每个项目（使用工具，而不是凭记忆）。
2. 将每个项目归类为有效（必须修复）或无效（提供证据予以驳回）。
   • 对于确实无法解析的项目，只能提出一个澄清问题。这是唯一的例外。
3. 打印简短摘要：列出无效项目及其证据，并为有效项目编号。
4. 只提出一个提示：launch fixes for 1,2,3?（列出每个有效项目的编号——默认方案始终是完整的有效项目集合）。
5. 处理用户的回复：
   • 确认（y、yes、go、ok、do it、lgtm 或直接按 ↵）→ 派发完整的建议集合。
   • 以逗号或空格分隔的数字列表（例如 1,3 或 1 3 4）→ 仅派发这些编号。它们必须是建议的有效项目集合的子集。用户省略的项目不会标记为延后——它们只是在本轮不执行。
   • no／cancel／stop → 不派发任务，直接停止。
   • 其他任何回复 → 重新打印一次提示；不得自行编造其他处理方式。
6. 根据修复质量契约应用每个所选项目的修复。如果 Agent 支持子 Agent，则为每个所选项目并行派发一个子 Agent（此分支中编排器不自行编辑文件）；否则，自行逐项依次应用每个修复，一次处理一项，并遵循相同的契约。两个分支必须产出相同结果。
7. 收集每项的结果，并输出最终响应表格。

禁止行为

以下要求不可妥协。编排器不得：

• 询问用户要修复哪些项目。唯一允许的问题是 launch fixes for <numbers>?，其中 <numbers> 默认为完整的有效项目集合。（用户可以通过回复自己的数字子集来覆盖——这是用户主动覆盖，并非 Agent 提问。）
• 声称问题是既存问题。如果审查者在这个 PR 中发现了它，就属于处理范围。
• 声称问题超出 PR 范围。如果这个分支上存在该 bug，这个 PR 就有责任修复。
• 将有效项目推迟到“以后”、“待办列表”、“后续 PR”或“未来工单”。
• 使用任何理由——风险、复杂度、时间、改动量、“小问题”、“表面问题”、“边缘情况”——来逃避修复有效项目。
• 将多个修复捆绑处理。一个有效项目 = 一个独立修复（支持时使用一个子 Agent；否则进行一次有针对性的顺序处理）。
• 当子 Agent 可用时，由编排器直接编辑代码——应将每项修复委派给一个子 Agent。

代码审查者或安全审查者提出的有效 bug 必须修复。没有其他选择。

严格关卡

在某个关卡的通过条件满足前，不要进入下一关。详情请参阅 VERIFICATION.md、EVALUATION.md 和 RESPONSE.md。

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

1. 找到相关代码或行为（阅读文件、搜索代码库、运行相关测试，或执行 VERIFICATION.md 中的其他检查）。
2. 记录结果：VALID（声明成立且可执行）或 INVALID（声明不成立），并提供佐证材料（文件路径和行范围、命令／测试结果，或简短引用的工具输出——不能只改述）。
3. 如果无法解析，标记为 NEEDS CLARIFICATION，并提出具体问题。不要擅自判定。

通过条件： 每一项都标记为 VALID / INVALID / NEEDS CLARIFICATION，并附有佐证材料。失败（停止）： 在没有佐证材料的情况下继续，或将 VALID 项降级为“跳过”／“推迟”／“已存在”／“超出范围”。

关卡 2 — 确认单次批次

1. 列出无效项（附拒绝证据）和有效项（编号列出）。
2. 只提出以下一个问题：launch fixes for <comma-separated numbers>? — <numbers> 必须是完整的有效项集合。不要预先缩小范围。
3. 按工作流的处理规则接受用户回复：确认 → 完整集合；回复部分编号 → 仅处理该子集；拒绝 → 停止。

通过条件： 用户确认或提供了所提议编号的子集，并且在进入关卡 3 前已书面锁定所选集合。失败（停止）： 提出缩小范围的默认选项、询问“你想修复哪些？”，或建议推迟任何有效项。

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

1. 每个选定项都必须对应一项独立修复，并包含：原始反馈文本、验证佐证材料、文件／行目标，以及 Fix-Quality Contract。
2. 如果 Agent 支持子 Agent，则在一个代码块中为每个选定项分派一个子 Agent，让它们并行运行，且编排 Agent 不得编辑文件。否则，你必须在相同契约下逐项依次修复，每次处理一项。

通过条件： 用户所选集合中的每一项都已按契约修复（支持子 Agent 时每项分派一个，否则每项进行一次专注的顺序处理）。失败（停止）： 将多项修复捆绑处理，或跳过用户实际选择的任何项目。

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

1. 子 Agent 返回后，填写 RESPONSE.md 中的结构化模板。
2. 响应必须且只能包含两个部分：Implemented 和 Rejected。不得设置 Deferred 部分。
3. 用户明确排除在本轮之外的有效项，只能在表格下方单独占一行，格式为：Not run this round: <numbers> (user-excluded)，除此之外不添加任何内容。不要将这些项目标记为 deferred 或 out of scope。

通过条件： 每一项都出现在 Implemented 或 Rejected 中，并附有文件：行号引用；任何被用户排除的有效项都按原样列在表格下方。失败（停止）： 提交的摘要遗漏项目、拒绝时缺少证据，或擅自添加“Deferred”类别。

命令工作流

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

1. 读取 $ARGUMENTS 中的反馈文件
2. 解析各条反馈，无论其采用编号、项目符号还是自由文本形式
3. 根据 VERIFICATION.md 验证每一项
4. 通过唯一的问题 launch fixes for <numbers>? 确认
5. 为每个有效项应用修复——如果支持子 Agent，则每项分派一个；否则依次逐项处理
6. 生成 RESPONSE.md 中定义的响应摘要

预期反馈文件格式

1. Remove unused import on line 15
2. Add error handling to the API call
3. Consider using a generator for large datasets
4. Fix typo in variable name: `usr` → `user`

也可以使用自由文本；请从文本中提取可执行的事项。

修复任务模板

修复某个项目时——无论是派遣子 Agent，还是由自己按顺序处理——修复简报都必须包含：

• 原始反馈文本（逐字引用）。
• 验证依据：文件路径、行范围，以及已确认的内容。
• 需要进行的确切更改；如果审阅者指定了更改，则写明“按审阅者的建议实施”。
• 以下修复质量约定，适用于每项修复（使用子 Agent 时，将其逐字复制到每个子 Agent 的提示词中）。

修复质量约定（适用于每项修复）

You are fixing one code review finding. Hard requirements:

1. Make the fix. Do not defer. Do not declare anything out of scope.
   Do not call anything pre-existing. If you discover the fix needs to
   touch adjacent code to be correct, touch it.

2. The fix must be clean and architectural — idiomatic for the language
   and the file's surrounding patterns. Read enough of the
   surrounding module to match its conventions before editing.
   No inline hacks, no band-aids, no "minimum to make it green".

3. Do NOT over-engineer. No new abstractions, no speculative
   generality, no helper layers, no config knobs. Solve the actual
   reported problem. If three lines are right, write three lines.

4. Write NO comments unless a future reader would be genuinely
   confused without one (a non-obvious invariant, a workaround for a
   specific upstream bug, a hidden constraint). Never write comments
   that restate what the code does. Never write headers, banners,
   "fix:" markers, or "// added for review feedback" notes.
   Excessive comments are a defect — do not produce them.

5. Run the project's typecheck / lint for the file you touched if a
   command is obvious from the repo. Report what you ran.

6. Report back: the resulting diff, the file:line of the change, and
   one sentence on what you changed and why.

派遣子 Agent 时，除非有明显更合适的特定领域子 Agent，否则使用通用子 Agent。

示例

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

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

读取文件，验证每项内容，输出无效／有效项摘要，询问 launch fixes for 1,3,4?，并在确认后修复第 1、3、4 项——如果支持并行，则派遣三个子 Agent 并行处理；否则由一个 Agent 按照相同约定依次完成三项修复。

文件

• VERIFICATION.md - 基于工具的验证工作流
• EVALUATION.md - 分类规则（有效／无效／需要澄清）
• RESPONSE.md - 结构化输出格式
• references/skill-integration.md - 与代码审查技能配合使用