Change Review
Review the behavioral delta, not the typography of the diff.
Protocol
- Determine the review range and read applicable
AGENTS.md. Inspect status so
uncommitted user work is not mistaken for the target change.
- Reconstruct intent from the request, commits, tests, and changed call sites.
State ambiguity when intent affects whether behavior is defective.
- Inventory changed surfaces: API/schema, state, authorization, side effects,
concurrency, errors/retries, configuration, observability, and release.
- For each surface, state the invariant before and after the change. Trace the
changed value/control flow beyond edited lines into callers and consumers.
- Inspect the risky counter-paths: absent/empty/malformed input, denied access,
duplicate/retry, partial failure, timeout/cancellation, stale state,
concurrent execution, upgrade/downgrade, and rollback. Use only relevant
paths.
- Read tests as executable claims. Check whether assertions would fail for the
suspected regression; test presence alone is not coverage.
- Validate each finding against the actual diff and surrounding code. A
finding must identify a reachable trigger, violated invariant, user impact,
and a bounded location introduced or exposed by the change.
- Rank by impact and likelihood using
references/finding-rubric.md. Omit
speculative concerns, pre-existing unrelated issues, and style preferences.
Finding bar
Emit a finding only when all are true:
- The reviewed change introduces or exposes it.
- A realistic execution path reaches it.
- The consequence is incorrect behavior, vulnerability, data loss, meaningful
degradation, or an operational failure.
- The developer can act on it locally.
- The evidence is specific enough to falsify.
If a concern is plausible but unproven, perform another read-only check. If it
remains uncertain, describe it as an open question outside the findings and
state what evidence is missing.
Output
Lead with findings ordered by priority. For each, use one concise paragraph:
[P#] imperative title, reachable scenario, consequence, and why current code
does not prevent it. Cite the smallest useful changed-line range.
Then give a short review summary and testing gaps. If no findings meet the bar,
say so explicitly and name residual risks or unverified surfaces.
1---2name: review-change3description: Review a code change for concrete correctness, security, data-integrity, compatibility, concurrency, and operability regressions by reconstructing intent and checking affected invariants and boundary paths. Use for local diffs, commits, branches, patches, or pull requests when the user wants actionable review findings. Report only defects introduced or exposed by the change with precise evidence; do not modify code unless asked to address findings.4---56# Change Review78Review the behavioral delta, not the typography of the diff.910## Protocol11121. Determine the review range and read applicable `AGENTS.md`. Inspect status so13 uncommitted user work is not mistaken for the target change.142. Reconstruct intent from the request, commits, tests, and changed call sites.15 State ambiguity when intent affects whether behavior is defective.163. Inventory changed surfaces: API/schema, state, authorization, side effects,17 concurrency, errors/retries, configuration, observability, and release.184. For each surface, state the invariant before and after the change. Trace the19 changed value/control flow beyond edited lines into callers and consumers.205. Inspect the risky counter-paths: absent/empty/malformed input, denied access,21 duplicate/retry, partial failure, timeout/cancellation, stale state,22 concurrent execution, upgrade/downgrade, and rollback. Use only relevant23 paths.246. Read tests as executable claims. Check whether assertions would fail for the25 suspected regression; test presence alone is not coverage.267. Validate each finding against the actual diff and surrounding code. A27 finding must identify a reachable trigger, violated invariant, user impact,28 and a bounded location introduced or exposed by the change.298. Rank by impact and likelihood using `references/finding-rubric.md`. Omit30 speculative concerns, pre-existing unrelated issues, and style preferences.3132## Finding bar3334Emit a finding only when all are true:3536- The reviewed change introduces or exposes it.37- A realistic execution path reaches it.38- The consequence is incorrect behavior, vulnerability, data loss, meaningful39 degradation, or an operational failure.40- The developer can act on it locally.41- The evidence is specific enough to falsify.4243If a concern is plausible but unproven, perform another read-only check. If it44remains uncertain, describe it as an open question outside the findings and45state what evidence is missing.4647## Output4849Lead with findings ordered by priority. For each, use one concise paragraph:50`[P#] imperative title`, reachable scenario, consequence, and why current code51does not prevent it. Cite the smallest useful changed-line range.5253Then give a short review summary and testing gaps. If no findings meet the bar,54say so explicitly and name residual risks or unverified surfaces.
contextosai