| name | review-change |
| description | Use to review a proposed change for correctness, security-sensitive behavior, readability, tests, performance when relevant, architecture and contract impact, and generated-file drift. |
Review Change
Use these rules when reviewing a pull request or proposed change.
Review Focus
- Correctness and edge cases.
- Security, including input validation and secret handling.
- Performance hotspots and obvious complexity regressions.
- Unnecessary complexity or premature abstraction.
- Consistency with existing project style.
- Missing or weakened tests.
- Weak typing or unjustified
any.
- Accessibility-affecting behavior in user-facing changes.
- Error handling and observability gaps.
- Dependency risk and license concerns.
- Spec compliance.
Severity Labels
- Blocker: must fix before merge (correctness, security, contract break).
- High: must fix before merge unless explicitly deferred.
- Medium: should fix before merge or open a tracked follow-up.
- Low: nit or polish; safe to defer.
Output Format
- Summary: one paragraph of intent and overall verdict.
- Spec Compliance: cite the spec and any deviation.
- Findings: grouped by severity, each with file, function, and concrete suggestion.
- Tests: list coverage gaps and whether tests were run.
- Safety Review: secrets, production access, dependency installs, network access.
- Final recommendation: approve, request changes, or block with reason.
Review Discipline
- Skip nitpicks the autoformatter or linter already handles.
- Do not propose broad rewrites; keep suggestions actionable.
- Reference the specific file, function, or component in every finding.
Safety
- Review only; do not rewrite or apply patches unless the user asks.
- Do not upload source code or read or print secrets.
- Do not install dependencies, contact production systems, or broaden permissions.
