Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Design the code-review practice for a whole team. Deliver: (1) a REVIEW GUIDE / checklist covering what reviewers look for (priority order: correctness/design over style), the standard for approval ('improves overall code health', not perfection), reviewer mindset (review the code not the person), and severity-labeled feedback norms (e.g. Conventional Comments); (2) a PROCESS spec — the PR/MR lifecycle, branch protection/required reviews, a one-business-day turnaround SLA, small-PR norms, and CODEOWNERS-based routing; (3) an AUTOMATION plan that moves all mechanical checks (formatters/linters, static analysis, type checks, CI tests, secret/dependency scanners) to run BEFORE human review so humans focus on logic/design; (4) a CULTURE section (psychological safety, blameless, juniors-review-seniors, no weaponized metrics); and (5) a stance on AI in review (first-pass aid, human-in-the-loop, extra scrutiny for AI-generated code). Explain the trade-offs (speed vs thoroughness) you're optimizing.
Checklist prioritizes correctness/design over style; uses the 'improves code health' standard; code-not-person mindset; severity-labeled feedback norms.
Sound PR lifecycle + protection + turnaround SLA + small-PR norms + CODEOWNERS; mechanical checks automated BEFORE human review (review complements tests, not replaces).
Psychological safety/blameless, no weaponized metrics, inclusive; AI as a first-pass aid with human-in-the-loop and extra scrutiny for AI-generated code.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A team code-review guide & automation plan
## Goal
Design the code-review practice for a whole team. Deliver: (1) a REVIEW GUIDE / checklist covering what reviewers look for (priority order: correctness/design over style), the standard for approval ('improves overall code health', not perfection), reviewer mindset (review the code not the person), and severity-labeled feedback norms (e.g. Conventional Comments); (2) a PROCESS spec — the PR/MR lifecycle, branch protection/required reviews, a one-business-day turnaround SLA, small-PR norms, and CODEOWNERS-based routing; (3) an AUTOMATION plan that moves all mechanical checks (formatters/linters, static analysis, type checks, CI tests, secret/dependency scanners) to run BEFORE human review so humans focus on logic/design; (4) a CULTURE section (psychological safety, blameless, juniors-review-seniors, no weaponized metrics); and (5) a stance on AI in review (first-pass aid, human-in-the-loop, extra scrutiny for AI-generated code). Explain the trade-offs (speed vs thoroughness) you're optimizing.
## Acceptance criteria
- [ ] Guide & standard: Checklist prioritizes correctness/design over style; uses the 'improves code health' standard; code-not-person mindset; severity-labeled feedback norms.
- [ ] Process & automation: Sound PR lifecycle + protection + turnaround SLA + small-PR norms + CODEOWNERS; mechanical checks automated BEFORE human review (review complements tests, not replaces).
- [ ] Culture & AI: Psychological safety/blameless, no weaponized metrics, inclusive; AI as a first-pass aid with human-in-the-loop and extra scrutiny for AI-generated code.
## Verification
- [ ] Document installation and run commands.
- [ ] Record automated checks and their exact commands.
- [ ] Add representative output, screenshots, or a short demo where useful.
- [ ] Confirm failure paths and known constraints.
## Decision log
### Decision title
- Context:
- Choice:
- Alternatives considered:
- Tradeoffs:
## Evidence
- Link each rubric criterion to the file, test, or artifact that demonstrates it.
## Known limitations
- List what is intentionally out of scope and what should be improved next.