reviewing-worklisted

# Reviewing-Work ## Overview **Core principle:** Fresh eyes catch what yours can't — you're too close to code you just wrote. Review **early and often** (per meaningful chunk, not just at the end), get it from a context that *doesn't share your assumptions*, and engage the feedback as a technical evaluation, not a social one. Two halves: **getting** the review, and **receiving** it well. ## Getting a Review — Use Fresh Context The reviewer must not inherit your session's history and rationalizations. Give it exactly what it needs, constructed on purpose: - **A fresh reviewer subagent** (**dispatching-subagents**) with a crafted brief: the diff range (base…head), what the change is meant to do, the requirements/constraints it must meet, and "return severity-ranked findings." It keeps the diff in *its* context; only the findings come back to you. - **Or an independent model** — **consulting-codex** in review or challenge mode for a second opinion. Mandatory after each task in a fan-out, after a major feature, and before anything merges. "It's simple" is not a reason to skip — simple changes carry the bugs you stopped looking for. ## Receiving a Review — Technical, Not Emotional Review is evaluation of the *code*, not of you. Respond to the substance. **Forbidden reflexes:** "You're absolutely right!", "Great catch!", "Thanks so much!" — performative agreement and gratitude. They add nothing and often precede applying a *wrong* fix to please the reviewer. **State th