/receive-feedback

name: receive-feedback
description: Process external code review feedback with technical rigor. Use when receiving feedback from another LLM, human reviewer, or CI tool. Verifies claims before implementing, tracks disposition.
disable-model-invocation: false

Receive Feedback

Overview

Process code review feedback with verification-first discipline. No performative agreement. Technical correctness over social comfort.

The orchestrator **verifies** and **applies fixes** under a strict per-item contract. **If the agent supports subagents**, each valid item is fixed by a dedicated subagent dispatched in parallel; **otherwise** the orchestrator applies the same fixes sequentially itself, one item at a time, under the identical Fix-Quality Contract — producing identical output.

Quick Reference

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

Core Principle

**Verify, confirm once, then apply the fixes for the chosen set.**

If a bug is valid, it gets fixed. Full stop. No deferral, no excuses. When subagents are available, one subagent fixes each item in parallel; otherwise the orchestrator fixes each item sequentially under the same contract.

When To Use

• Receiving code review from another LLM session
• Processing PR review comments
• Evaluating CI/linter feedback
• Handling suggestions from pair programming

Workflow

1. **Verify every item** against the current codebase (tools, not memory). 2. **Classify** each item as **VALID** (must fix) or **INVALID** (reject with evidence).

• Truly unparseable items get one clarification question. That is the only escape.

3. **Print** a short summary: invalid items with evidence, valid items numbered. 4. **Ask exactly one prompt**: `launch fixes for 1,2,3?` (list every valid item's number — the default proposal is always the full valid set). 5. **Resolve the user's reply**:

• Confirmation (`y`, `yes`, `go`, `ok`, `do it`, `lgtm`, or just ↵) → dispatch the full proposed set.
• A comma/space-separated list of numbers (e.g. `1,3` or `1 3 4`) → dispatch only those numbers. They must be a subset of the proposed valid set. Items the user omits are NOT marked deferred — they are simply not run this round.
• `no` / `cancel` / `stop` → halt without dispatching.
• Anything else → re-print the prompt once; do not invent a new disposition.

6. **Apply the fix for each chosen item** under the Fix-Quality Contract. **If the agent supports subagents**, dispatch one subagent per chosen item in parallel (the orchestrator does not edit files itself in this branch); **otherwise** apply each fix sequentially yourself, one item at a time, following the same contract. Either branch must produce identical results. 7. **Collect** the per-item results and emit the final response table.

Forbidden Behaviors

These are non-negotiable. The orchestrator may **not**:

• Ask the user *which* items to fix. The only question allowed is `launch fixes for <numbers>?`, where `<numbers>` defaults to the full valid set. (The user may override by replying with their own subset of numbers — that is a user override, not an agent question.)
• Claim an issue is **pre-existing**. If a reviewer found it on this PR, it is in scope.
• Claim an issue is **out of scope** for the PR. If the bug exists on this branch, the PR owns it.
• **Defer** a valid item to "later", a "backlog", a "follow-up PR", or a "future ticket".
• Use any reasoning — risk, complexity, time, churn, "minor", "cosmetic", "edge case" — to avoid fixing a valid item.
• Bundle multiple fixes together. One valid item = one isolated fix (one subagent when supported, one focused sequential pass otherwise).
• **When subagents are available**, edit code directly in the orchestrator — delegate each fix to a subagent instead.

A valid bug raised by a code or security reviewer **must** be fixed. There is no other option.

Hard Gates

Do not advance to the next gate until its **pass condition** is true. Details live in `VERIFICATION.md`, `EVALUATION.md`, and `RESPONSE.md`.

**Gate 1 — Verification evidence (per item)**

1. Locate the referenced code or behavior (read the file, search the codebase, run the relevant test, or another check from `VERIFICATION.md`). 2. Record the outcome: **VALID** (claim holds and is actionable) or **INVALID** (claim fails), with an artifact (file path and line range, command/test result, or short quoted tool output — not paraphrase alone). 3. If unparseable, mark **NEEDS CLARIFICATION** with the specific question. Do not invent a disposition.

**Pass when:** Every item has VALID / INVALID / NEEDS CLARIFICATION plus an artifact. **Fail (stop):** Proceeding without an artifact, or downgrading a VALID item to "skip" / "defer" / "pre-existing" / "out of scope".

**Gate 2 — Single batch confirmation**

1. Print the invalid items (with rejection evidence) and the valid items (numbered). 2. Ask the **single** prompt: `launch fixes for <comma-separated numbers>?` — `<numbers>` MUST be the full valid set. Do not pre-narrow it. 3. Accept the user's reply per the Workflow resolution rules: confirmation → full set; subset of numbers → that subset only; refusal → halt.

**Pass when:** The user confirms or supplies a subset of the proposed numbers, and the chosen set is locked in writing before Gate 3. **Fail (stop):** Proposing a narrowed default, asking "which would you like to fix?", or proposing to defer any valid item.

**Gate 3 — Apply fixes for the chosen set**

1. Each chosen item get