receiving-code-reviewlisted

# Receiving code review Reviews are signal. Treat each issue as a hypothesis, not a verdict. ## When to use - Reviewer (human or agent) returns an `Issues:` block. - A user pastes "you should change X" feedback. - After `/llm-orchestrator:review` returns Critical or Important findings. ## The default response For each issue, decide one of: 1. **Agree, fix** — issue is real, fix is clear. Do it. 2. **Agree, push back on the fix** — issue is real but the suggested fix is wrong; propose an alternative. 3. **Disagree, with reason** — issue is not real; explain why with evidence. 4. **Need more info** — issue is ambiguous; ask one clarifying question. Never blanket-agree. Never silently ignore. ## Steps 1. Read every Issue. One pass, no skipping. 2. For each Critical: stop and address before continuing. 3. For each Important: fix before moving past this area. 4. For each Minor: decide — fix now or note as follow-up. 5. For each item, decide which of the four responses applies. ## Understand everything before implementing anything If any item is unclear, stop — and do not implement the ones you *did* understand. Findings are frequently related: a partial fix built on partial understanding is how a review round produces new findings. Ask about the unclear items, then work the whole set. ## Check it before you accept it Evidence is required to disagree, so it must also be required to agree — an unchecked suggestion is accepted on the reviewer's authority, not its merit.