Mav bp code review
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.From its SKILL.md
npx -y skills add thermiteau/maverick --skill mav-bp-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.0 KB, as published. Nobody here has run it
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 |