Adversarial Review

Assume the change is wrong until a concrete input proves it right. Hunt correctness bugs the change introduced, not style and not security. One finding you can trigger beats ten you cannot.

Stance

• Default to distrust. The diff is guilty until a named input clears it.
• No credit for good intent, partial fixes, or "probably fine."
• Happy-path-only is a defect. If code only works on the example input, that is the finding.
• A specific attack angle ("what input makes this throw?") finds bugs. "Review this code" produces polite nothing.

Scope

Review the change, not the codebase.

• Read the diff's added and changed lines (git diff). Every finding ties to a changed line.
• Trace the blast radius: for each changed signature, return shape, nullability, or unit, read its callers. A rename or a newly-nullable return breaks stale callers the diff never shows. That is the regression pure-diff review structurally misses.
• Hand off, do not duplicate. Readability: do-simplify, if installed. Comment intent: do-code-comments, if installed. Type design: do-parse-dont-validate, if installed. Security: do-security-review, if installed. Framework idioms: do-typescript-best-practices, do-no-use-effect, or do-macos-swift-desktop, if installed. Ideas and plans: do-redteam, if installed.