Code Reviewing

Code Reviewing

This skill is for code review in plain practical terms: find what can break, what is weak, and what still needs proof.

Use it when:

• code was just written
• you want a pre-merge review
• you suspect hidden regressions
• you need more than “looks fine”

Main benefit:

• catches real defects early
• pushes review toward evidence, not taste
• highlights missing tests and invalid integrations

Primary Output

Findings first.

Each finding should include:

• severity
• file
• line
• issue
• impact
• recommended fix

Review Dimensions

Check what matters for the changed area:

• correctness
• cross-file consistency
• error handling
• test coverage and test quality
• security boundaries
• maintainability
• performance only when clearly relevant

For cross-file verification rules, read cross-file-checks.md.

Rules

• Prioritize real bugs and regressions over style nits.
• Verify imports, function signatures, and called APIs against source.
• If tests are missing for meaningful logic, call that out.
• If no findings exist, say so explicitly and mention residual risk or testing gaps.
• Do not inflate severity for trivial style issues.

Severity Guidance

• critical: likely broken behavior, security issue, data loss risk, invalid cross-file usage
• major: strong regression risk, missing important validation, meaningful maintainability issue
• minor: worthwhile improvement but not likely to break behavior

Output Shape

Default response order:

1. findings
2. open questions or assumptions
3. brief summary