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 — Prefer Fresh Context Use the freshest review mechanism the host and active policy permit. Give it exactly what it needs, constructed on purpose: - **When available, 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. - **Or a mechanical review command** supplied by the host, such as `/code-review`. - **Fallback:** when none of those capabilities exists, start a deliberate adversarial self-review: re-read the requirements, inspect the complete diff from the base, trace affected callers, and try to construct a failing case. State that the review was not independent. Run a review after each task in a fan-out, after a major feature, and before anything merges. Prefer independent context, but do not block solely because the h