mav-bp-code-review

name	mav-bp-code-review
description	Code review conventions for all projects. Covers mandatory review requirements, review scope, PR sizing, reviewer and author responsibilities, and automated review integration. Applied when creating or reviewing pull requests.
user-invocable	false
disable-model-invocation	true

Code Review Standards

Ensure all code changes are reviewed before merging; in Maverick the reviewer is agent-code-reviewer running in-session, backed by branch-protection gates.

Maverick's Rules

• No unreviewed merges: at least one approval on protected branches; no self-approval; stale approvals are dismissed when new commits are pushed; all CI checks must pass. Never disable or skip a check to merge faster — fix the check or the code.
• Security is out of scope for PR review — it runs as a separate pre-push gate via do-cybersecurity-review (update mode against the diff and impact set) before the PR is opened. By review time, security findings are already surfaced and folded into the PR body.
• Review scope: correctness, maintainability, test coverage, documentation. Style and formatting are the linter's job — do not comment on them. Do not review generated code (codegen, lockfiles) line by line, and do not request changes to correct-but-different approaches on personal preference.
• Verdict discipline: distinguish blocking findings from non-blocking (prefix "nit:" or "optional:"); demonstrate understanding of the change rather than rubber-stamping; approve once the code is correct, tested, and maintainable — do not hold changes hostage for perfection. AI review findings require judgement — dismiss false positives with reasoning, never silently.
• Automated checks pass before review begins — do not review code that fails lint, type checks, or tests.

PR Size

Size	Lines changed	Review quality	Recommendation
Small	< 100	Excellent	Ideal. Aim for this size.
Medium	100 - 400	Good	Acceptable for most feature work.
Large	400 - 800	Declining	Split if possible. Flag to reviewers.
Too large	> 800	Poor	Must split. Reviewers cannot effectively review this.

Split strategies: by layer (backend vs frontend), by feature slice (one endpoint/component per PR), by phase (refactor PR before feature PR), or by dependency (extract shared utilities/models into a preparatory PR).

Detecting Code Review Anti-Patterns

Pattern	Issue	Fix
PR merged without any review	No review gate	Enable branch protection requiring approvals
PR with 1000+ lines changed	Too large to review effectively	Split into smaller, focused PRs
All review comments are style nits	Wasted review effort	Configure linters to catch style; focus on logic
Reviewer approves without comments on large PR	Rubber-stamp review	Reviewers must demonstrate understanding of the change
Author pushes "fix review" commits without context	Lost review trail	Explain what was changed in response to which comment
Self-approval on protected branch	Missing review gate	Configure branch protection to disallow self-approval
Skipping CI to merge faster	Bypassing quality gates	CI must pass; fix failures, do not skip them