Deep Code Review
Goal
Find meaningful issues before merge while avoiding noisy or subjective feedback.
When to use
Use for PR reviews, diffs, architecture reviews, risk reviews, and pre-merge checks.
When not to use
Do not use when the user asks for direct implementation rather than review.
Inputs
Inspect the diff, changed files, tests, affected public interfaces, dependency changes, and related docs.
Workflow
- Understand the intent of the change.
- Review correctness first.
- Check edge cases, error handling, data validation, and auth boundaries.
- Check security and privacy risks.
- Check maintainability, duplication, and architecture fit.
- Check tests and validation coverage.
- Prioritize findings by impact.
- Avoid comments that are only personal style preferences.
Severity levels
- Blocker: likely production breakage, data loss, security issue, or failed build.
- Major: likely bug, missing validation, risky architecture, or poor test coverage.
- Minor: maintainability or clarity issue worth fixing.
- Nit: optional style improvement.
Validation
Recommend or run relevant tests, lint, typecheck, build, and security checks.
Final response
List findings by severity with file references when possible. Include positives only if helpful and brief.
1---2name: deep-code-review3description: Use this when reviewing code, pull requests, diffs, architecture changes, security risks, regressions, or maintainability problems.4---56# Deep Code Review78## Goal910Find meaningful issues before merge while avoiding noisy or subjective feedback.1112## When to use1314Use for PR reviews, diffs, architecture reviews, risk reviews, and pre-merge checks.1516## When not to use1718Do not use when the user asks for direct implementation rather than review.1920## Inputs2122Inspect the diff, changed files, tests, affected public interfaces, dependency changes, and related docs.2324## Workflow25261. Understand the intent of the change.272. Review correctness first.283. Check edge cases, error handling, data validation, and auth boundaries.294. Check security and privacy risks.305. Check maintainability, duplication, and architecture fit.316. Check tests and validation coverage.327. Prioritize findings by impact.338. Avoid comments that are only personal style preferences.3435## Severity levels3637- Blocker: likely production breakage, data loss, security issue, or failed build.38- Major: likely bug, missing validation, risky architecture, or poor test coverage.39- Minor: maintainability or clarity issue worth fixing.40- Nit: optional style improvement.4142## Validation4344Recommend or run relevant tests, lint, typecheck, build, and security checks.4546## Final response4748List findings by severity with file references when possible. Include positives only if helpful and brief.
YankielDBC2