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 **dispatches**. It never edits files itself. Every valid item is fixed by a dedicated subagent spawned in parallel. ## Quick Reference ```text ┌─────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ VERIFY │ ──▶ │ CONFIRM │ ──▶ │ DISPATCH FIXES │ │ (tool-based)│ │ ("launch │ │ (one subagent per │ │ │ │ fixes for │ │ valid item, run in │ │ │ │ 1,2,3?") │ │ parallel) │ └─────────────┘ └──────────────┘ └──────────────────────┘ ``` ## Core Principle **Verify, confirm once, then dispatch subagents. The orchestrator does not fix.** If a bug is valid, a subagent fixes it. Full stop. No deferral, no excuses. ## 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,...