I want the obvious stuff caught before I open a PR. This is my pre-review pass.
The workflow
- Open the diff in Cursor
- Ask it to review for bugs and edge cases
- Have it suggest tests for the risky paths
- Fix, then open the PR
Result: Fewer review comments and fewer regressions.
The prompt
Review this diff. List correctness bugs first, then missing edge cases, then suggested tests. Be specific and skip style nits.A note on what follows. The workflow, the prompt and the result above come from the member. The notes below (why the prompt works, what to watch for, how to adapt it) were written with AI help.
Why this prompt works
"Skip style nits" is in there because the first few runs were 80 percent formatting. Naming, line length, an import order opinion. All of it noise next to a real bug, and it trained me to skim, which defeats the point. The ordering matters as much as the content. Correctness first, then edge cases, then tests, because I read the top of a list carefully and the bottom lazily, and I would rather be lazy about test suggestions than about a null deref. I keep it as a second pass, never a first. I read the diff myself, then run this, then compare. When it finds something I missed I pay attention to the category, not just the bug, because that tells me where my own reading is weak. Mine is concurrency.
What to watch for
- It reviews the diff, not the codebase. Anything that breaks a caller outside the changed lines is invisible.
- Confident wrong bugs. It will describe a race condition in code that holds a lock two functions up.
- Deleted code gets almost no scrutiny, which is where a surprising number of our regressions come from.
- Suggested tests tend to test the happy path it just read, not the edge case it just flagged.
How to adapt it
- Give it the contract. Add
This function is called from a webhook handler and must be idempotent.and the review changes completely. - For a big diff, add
List the three changes most likely to cause an incident, and ignore the rest. - Before a release, swap the framing with
What could this diff break that is not in the diff?It is a worse review and a better question.
What good output looks like
Line numbers, or at least quoted code. A finding I cannot locate in ten seconds gets skipped, and skipped findings are worse than no findings because they make the whole list feel optional. The correctness section should be short. If it lists nine bugs in a forty line diff, most of them are style complaints wearing a costume, and I rerun with the constraint spelled out.