Code Review Enforcement Skill

Ensures every code review is thorough, consistent, and produces actionable feedback. Used by the reviewer agent.

10-Point Review Checklist

Every review MUST evaluate all 10 items. No shortcuts.

1. Correctness

• Does the code do what the ticket/plan requires?

• Are edge cases handled (empty input, None, boundary values)?

• Are return types consistent with declarations?

2. Test Coverage

• Do tests exist for new/changed code?

• Do ALL tests pass (100%, not "most")?

• Are edge cases and error paths tested?

3. Error Handling

• Are exceptions specific (not bare except: )?

• Do error messages include context (what failed, what was expected)?

• Is there graceful degradation where appropriate?

4. Type Hints on Public APIs

• All public functions have parameter and return type annotations?

• Complex types use Optional , Union , List , Dict correctly?

5. Naming Conventions

• Variables/functions: snake_case

• Classes: PascalCase

• Constants: UPPER_SNAKE_CASE

• Names are descriptive (no single-letter except loop vars)

6. Security

• No hardcoded secrets, API keys, or passwords

• No bare except: that swallows errors silently

• SQL queries use parameterized statements

• User input is validated before use

7. Style Compliance

• Code is formatted with black (100 char line length)

• Imports sorted with isort

• No unused imports or variables

8. Documentation

• Public APIs have Google-style docstrings

• Complex logic has inline comments

• Examples provided for non-obvious usage

9. No Stubs or Placeholders

• No NotImplementedError in shipped code

• No pass as the sole body of a function

• No TODO without a linked issue number

10. No Unnecessary Complexity

• No premature abstraction

• No dead code paths

• Functions do one thing

• Nesting depth <= 3 levels

Severity Levels

BLOCKING (must fix before approval)

• Failing tests

• Security vulnerabilities (hardcoded secrets, SQL injection)

• Missing error handling on external calls

• Stubbed/placeholder code

• Incorrect logic or data loss risk

ADVISORY (prefix with "Nit:")

• Style preferences beyond black/isort

• Alternative naming suggestions

• Minor documentation improvements

• Performance micro-optimizations

HARD GATE: Required Output

Every review MUST conclude with exactly one of:

• APPROVED — all 10 checklist items pass, no BLOCKING issues

• REQUEST_CHANGES — at least one BLOCKING issue found

FORBIDDEN:

• Saying "looks good" without running the full checklist

• Approving code with failing tests

• Approving stubbed or placeholder code

• Approving without checking security items (checklist #6)

• Mixing BLOCKING and ADVISORY without clear labels

• Rubber-stamping: approving in under 30 seconds of analysis

REQUIRED:

• Per-file summary with specific line references for each finding

• Explicit pass/fail on each of the 10 checklist items

• Test results included (run pytest and report output)

• Security checklist explicitly addressed

• BLOCKING vs ADVISORY clearly labeled on every finding

Required Output Format

Review: [file or PR title]

Checklist

1. Correctness: PASS/FAIL — [details]
2. Test Coverage: PASS/FAIL — [details]
3. Error Handling: PASS/FAIL — [details]
4. Type Hints: PASS/FAIL — [details]
5. Naming: PASS/FAIL — [details]
6. Security: PASS/FAIL — [details]
7. Style: PASS/FAIL — [details]
8. Documentation: PASS/FAIL — [details]
9. No Stubs: PASS/FAIL — [details]
10. Complexity: PASS/FAIL — [details]

Findings

• [BLOCKING] file.py:42 — description
• [Nit:] file.py:88 — suggestion

Test Results

[paste pytest output summary]

Verdict: APPROVED / REQUEST_CHANGES

Anti-Patterns

BAD: Rubber-stamp approval

"Looks good to me, ship it!"

Missing: checklist, line references, test results, security review.

GOOD: Structured review

Review: lib/auth.py

Checklist

1. Correctness: PASS — token validation logic matches RFC 7519
2. Test Coverage: PASS — 12 tests, all pass, covers expiry edge case ...
3. Security: FAIL — API key on line 34 is hardcoded

Findings

• [BLOCKING] auth.py:34 — Hardcoded API key, move to env var

Verdict: REQUEST_CHANGES

BAD: Nitpicking style, missing logic bugs

Spending 10 comments on variable naming while an off-by-one error goes unnoticed.

BAD: "Will fix later" acceptance

Approving with known BLOCKING issues and a verbal promise to fix. If it is BLOCKING, it blocks.

Cross-References

• python-standards: Style and type hint requirements

• testing-guide: Test coverage expectations

• security-patterns: Security checklist details