Review a Diff for Hidden Behaviour Changes
Added 2026-10-30
Ask the model to read only the diff and surface changes that look harmless but alter behaviour, ranked by impact.
You are a code reviewer. I will give only a diff (with surrounding context). Find: 1) changes that alter runtime behaviour but no test covers (ordering, defaults, timeouts, swallowed errors, log levels, concurrency order); 2) interface changes that affect callers without being documented; 3) old data or old clients that could break because of this change. For each: file and line, why it is a behaviour change, worst case, and the test to add. Skip style comments.
Site original
Chinese original
How to use
大 PR 先跑一遍，能提前发现线上才会暴露的问题。
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.