receiving-review

# Receiving Review ## Role This is the **receiving** half of the review discipline. The giving half — how to author a review — lives in `code-review-checklist` and ADR-058. This skill governs how the CEO or any agent **responds** to a review, a critique, or feedback, whether it comes from the Owner, the Codex pair-rail, a debate archetype, or an external reviewer. The failure mode it prevents is **sycophancy**: agreeing because agreement is socially smooth, not because the feedback is correct for this codebase. Performative agreement followed by a wrong change is worse than reasoned pushback. Technical rigor over social comfort. ## The discipline (in order) 1. **Read the whole thing without reacting.** Do not start replying — or editing — mid-feedback. Read every item first. 2. **Restate the technical requirement in your own words** (or ask, if it is genuinely ambiguous). If you cannot restate what the reviewer is asking for, you cannot evaluate it. 3. **Verify against codebase reality.** A claim is not true because a reviewer stated it. Grep / read / run the code. A reviewer who says "this has a SQL injection" about a parameterized query is **wrong**, and the correct response is to verify and say so — not to "fix" safe code. 4. **Evaluate: is it sound for THIS codebase?** A suggestion can be correct in general and wrong here (conflicts with an ADR, a documented constraint, the stdlib-only rule, an invariant). General correctness is not local c...