Code Change Review
Review a pinned change and return evidence-bounded findings.
Workflow
- Pin the repository, base revision, head revision, diff scope, intended behavior, and relevant authority.
- Read the changed code in context, including callers, consumers, contracts, tests, configuration, and generated boundaries.
- Test each suspected issue against actual control flow, data flow, upgrade order, failure handling, and repository conventions.
- Rank only actionable findings by user impact and likelihood. Attach exact locations and a concrete failure scenario.
- Check whether tests would fail for the defect and whether the proposed behavior is compatible with existing consumers.
- Separate findings from questions, optional improvements, and unsupported concerns.
- Report validation performed, unavailable evidence, and the remaining review boundary.
Boundaries
- A changed line is not automatically defective, and an unchanged line can still be affected.
- Do not implement fixes unless the user separately asks for changes.
- Do not treat a review comment as a decision, a passing check as merge authority, or a mergeable state as approval.
- Do not claim the change is safe outside the inspected scope.
Output
Lead with findings ordered by severity. For each finding provide Location, Failure, Evidence, Impact, and Suggested direction. Then report Questions, Validation, and Review boundary. If no actionable finding survives verification, say so and name remaining risks or untested surfaces.
1---2name: code-change-review-23description: Review an exact code change for correctness, regressions, security, compatibility, test quality, and maintainability using the diff and repository evidence. Use before commit, pull request, merge, or release when the user wants findings rather than implementation.4license: MIT5---67# Code Change Review89Review a pinned change and return evidence-bounded findings.1011## Workflow12131. Pin the repository, base revision, head revision, diff scope, intended behavior, and relevant authority.142. Read the changed code in context, including callers, consumers, contracts, tests, configuration, and generated boundaries.153. Test each suspected issue against actual control flow, data flow, upgrade order, failure handling, and repository conventions.164. Rank only actionable findings by user impact and likelihood. Attach exact locations and a concrete failure scenario.175. Check whether tests would fail for the defect and whether the proposed behavior is compatible with existing consumers.186. Separate findings from questions, optional improvements, and unsupported concerns.197. Report validation performed, unavailable evidence, and the remaining review boundary.2021## Boundaries2223- A changed line is not automatically defective, and an unchanged line can still be affected.24- Do not implement fixes unless the user separately asks for changes.25- Do not treat a review comment as a decision, a passing check as merge authority, or a mergeable state as approval.26- Do not claim the change is safe outside the inspected scope.2728## Output2930Lead with findings ordered by severity. For each finding provide `Location`, `Failure`, `Evidence`, `Impact`, and `Suggested direction`. Then report `Questions`, `Validation`, and `Review boundary`. If no actionable finding survives verification, say so and name remaining risks or untested surfaces.
JovaniPink