receive-feedback

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.