Review Change
Find issues that would change a competent author’s decision. Prefer a few proven findings over speculative volume.
Workflow
- Establish scope: requested diff, base, repository state, generated files, and user intent.
- Read repository instructions and the change description or spec.
- Inspect the whole diff, then read surrounding call sites, tests, data flow, ownership, and history where it changes interpretation.
- Trace critical behaviors: success, failure, permissions, concurrency, retries, migrations, cleanup, compatibility, observability, UI states, and accessibility.
- Run focused, read-only checks when they can confirm or reject a finding.
- For each issue, identify a concrete input or state, causal path, user or system impact, and the tightest changed line range.
- Check that tests would fail if the implementation were wrong. Do not count mere test presence as coverage.
- Report findings by severity. If none qualify, say so and list residual risks or unrun checks.
Severity
P0: immediate catastrophic security, data loss, or widespread outage risk.P1: likely severe user impact, exploitable security issue, or correctness failure in a central path.P2: real defect with bounded impact or an important missing failure case.P3: low-impact defect worth fixing. Pure style preferences are excluded.
Finding contract
[P2] Imperative, specific title
Trigger: concrete input, state, or sequence.
Cause: why the changed code produces the problem.
Impact: observable consequence.
Evidence: file:line, command, trace, or contract.
Fix direction: smallest safe direction, without redesigning the patch.
Review rules
- Comment on code, not the author.
- Explain why. Distinguish required findings from optional suggestions.
- Do not report pre-existing issues unless the change makes them materially worse.
- Do not claim a vulnerability without a plausible threat path.
- Do not claim a race without an interleaving.
- Do not flag a missing test without naming the behavior it must protect.
- Review generated artifacts through their source when possible; do not edit generated files.
Evidence packet
Lead with findings. Then list checks run, scope reviewed, assumptions, and residual risks. Never say “looks good” when relevant verification could not run; say what was and was not established.
1---2name: review-change3description: Review a code change in repository context for behavioral regressions, correctness, security, privacy, accessibility, operability, and test quality. Use for diffs, pull requests, or pre-commit review. Do not use to summarize code without evaluating it.4license: Apache-2.05---67# Review Change89Find issues that would change a competent author’s decision. Prefer a few proven findings over speculative volume.1011## Workflow12131. Establish scope: requested diff, base, repository state, generated files, and user intent.142. Read repository instructions and the change description or spec.153. Inspect the whole diff, then read surrounding call sites, tests, data flow, ownership, and history where it changes interpretation.164. Trace critical behaviors: success, failure, permissions, concurrency, retries, migrations, cleanup, compatibility, observability, UI states, and accessibility.175. Run focused, read-only checks when they can confirm or reject a finding.186. For each issue, identify a concrete input or state, causal path, user or system impact, and the tightest changed line range.197. Check that tests would fail if the implementation were wrong. Do not count mere test presence as coverage.208. Report findings by severity. If none qualify, say so and list residual risks or unrun checks.2122## Severity2324- `P0`: immediate catastrophic security, data loss, or widespread outage risk.25- `P1`: likely severe user impact, exploitable security issue, or correctness failure in a central path.26- `P2`: real defect with bounded impact or an important missing failure case.27- `P3`: low-impact defect worth fixing. Pure style preferences are excluded.2829## Finding contract3031```markdown32[P2] Imperative, specific title3334Trigger: concrete input, state, or sequence.35Cause: why the changed code produces the problem.36Impact: observable consequence.37Evidence: file:line, command, trace, or contract.38Fix direction: smallest safe direction, without redesigning the patch.39```4041## Review rules4243- Comment on code, not the author.44- Explain why. Distinguish required findings from optional suggestions.45- Do not report pre-existing issues unless the change makes them materially worse.46- Do not claim a vulnerability without a plausible threat path.47- Do not claim a race without an interleaving.48- Do not flag a missing test without naming the behavior it must protect.49- Review generated artifacts through their source when possible; do not edit generated files.5051## Evidence packet5253Lead with findings. Then list checks run, scope reviewed, assumptions, and residual risks. Never say “looks good” when relevant verification could not run; say what was and was not established.
leihuang23