adversarial-lens-reviewlisted

# Refute, Don't Confirm: Adversarial Review by Named Lens Cooperative review confirms what the author already believes; adversarial review tries to break it. An author who reviews their own work grades against their own blind spots — everything looks compliant because they wrote it to look compliant. The fix is structural, not attitudinal: put the artifact in front of a reviewer with no context from writing it, whose only job is to find what's wrong, through a specific named lens. ## When to use At the spec-to-plan, plan-to-code, and code-to-merge gates — anywhere an artifact needs to be trusted before the next hard-to-reverse step. This hardens the "gate each phase behind review" step of [spec-driven-development](../spec-driven-development/SKILL.md) into a concrete, binding protocol. Red-flag thoughts that mean STOP and apply this skill: - "I re-read it myself and it looks solid." (You wrote it to look solid to you.) - "One reviewer said it looks good, that's enough." (A single "looks good" is cooperative, not adversarial.) - "The reviewer fixed the two issues they found, we're done." (Reviewers enumerate; they don't fix — a reviewer that fixes has stopped finding.) - "It passed the code-quality pass, ship it." (Did it pass spec-compliance first? The two catch different bug classes.) - "That constant is obviously fine." (Every bare number needs a justification a lens can check.) ## The lens contract (binding — dispatch the full row for the artifact) | Artifact | Named