Code review

Always start by inspecting the changes. If you're on the main git branch, typically the (staged) git diff. If you're on a different branch, the committed and uncommitted changes compared to the main branch.

Method

Please dispatch two subagents to carefully review the code changes. Tell them that they're competing with another agent. Make sure they look at both architecture and implementation. Tell them that whoever finds more issues wins honour and glory.

Also have them run one targeted check on comments: read each new or changed comment as a reader who knows only this package and the public API of what it imports. Flag any mention of callers or importing packages, and any reference to internals hidden behind an abstraction the code consumes. Such context leakage is a real defect, not a comment nitpick -- surface it even when only one reviewer finds it.

Surfacing issues

Signal-to-noise ratio matters more than completeness. When reporting back to the caller:

• By default, only surface issues that both sub-agents independently found. Agreement between two reviewers is a strong signal that an issue is real.
• Drop issues that only one sub-agent raised, unless the issue is serious -- e.g. a correctness bug, security flaw, data-loss risk, concurrency hazard, or significant architectural problem. Serious issues get surfaced even without corroboration.
• Minor issues and nitpicks (style preferences, naming bikesheds, comment suggestions, micro-optimisations) should only be surfaced when both sub-agents flagged them.

State clearly in the report which issues had consensus and which are single-reviewer calls promoted for seriousness.