Verified against Cursor · 2026-07-30
Point Cursor BugBot at the actual risk in a PR instead of a generic pass over the diff
A PR description written for BugBot, Cursor's automated PR-review agent, that states risk areas and known trade-offs up front and defines exactly how findings must be classified and cited, so its comment thread concentrates on real logic and security risk instead of restating the diff or re-litigating a deliberate choice.
The prompt
Ready to copy — highlighted parts are example details you can swap.
PR SUMMARY Switches the checkout discount calculation from a flat percentage to a tiered table looked up by cart total. RISK AREAS TO FOCUS REVIEW ON The boundary values between tiers (is $100.00 exactly tier 2 or tier 3?), and whether the old flat-percentage code path is fully removed or still reachable from the cart API. KNOWN TRADE-OFFS — do not flag these as bugs, they were a deliberate choice Tier boundaries are hardcoded, not config-driven — intentional for this release; a follow-up ticket will move them to settings. TEST COVERAGE ADDED IN THIS PR tiers.test.ts asserts exact-boundary behavior at $99.99/$100.00/$100.01, and one test for the removed flat-discount path returning a 404. @BugBot review this PR against the risk areas above specifically. For each finding: 1. Cite the exact file and line. 2. Classify it as Bug, Security, or Style. 3. Rate it Blocking or Minor. 4. State whether the test coverage listed above would have caught it — if it would have, and the tests are passing, explain the contradiction rather than just flagging the risk in isolation. Skip anything already listed under known trade-offs entirely. If you disagree with a trade-off on its merits, raise it as a Minor note explicitly labeled "disagreement with stated trade-off," not as a Blocking finding — a deliberate choice the author already made is not the same category of problem as a bug they didn't notice. Do not restate what the diff already makes visible (a renamed variable, a moved function) as a finding. A finding without a specific failure scenario attached — an input, a state, or a sequence of calls that produces the wrong result — is not a finding; note it separately as an observation if it seems worth mentioning at all. If the risk areas above turn out not to be where the actual problems are, say so directly instead of manufacturing a finding to justify the review having focused there.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
BugBot runs automatically against a PR's diff once enabled on a repo and posts inline comments without anyone writing a review prompt at all by default, which is exactly the problem this brief solves: with no steer, it reviews the whole diff at a uniform level of attention, and its comment thread ends up mixing genuine logic risk with restated-diff narration and style nits in no particular order, which trains reviewers to skim past the thread entirely after a few PRs of low signal. Naming RISK_AREAS concentrates its attention the same way a scoped rubric concentrates any LLM reviewer — it's told where the actual uncertainty in this change lives, rather than treating every changed line as equally suspicious, which matters because an automated reviewer with no steer tends to spend equal words on a renamed variable and a genuine boundary-condition bug. KNOWN_TRADEOFFS suppresses the single most common false-positive pattern in automated PR review: a deliberate simplification gets flagged as a defect because the reviewer has no way to distinguish an oversight from a choice, and downgrading disagreement to an explicitly labeled Minor note rather than a Blocking finding means a legitimate design debate doesn't block a merge that both the author and BugBot might actually be right about, just from different priorities. The requirement to check findings against TEST_COVERAGE_NOTES adds a layer most review prompts skip entirely: it forces BugBot to reconcile "tests are passing" with "here is a bug," which either surfaces a real gap in the tests (they claim to cover the boundary but don't actually assert what they claim to) or catches BugBot manufacturing a finding for a case that's already provably handled — a specific check against a specific failure mode of automated review, not a generic instruction to "be thorough."
What you get back
BugBot findings: 1. checkout/pricing/tiers.ts:34 — Bug, Blocking. Tier lookup uses cartTotal > threshold, so a cart total of exactly $100.00 falls into tier 1, not tier 2 as the PR summary implies. tiers.test.ts asserts $100.00 as tier 2 but the test currently passes because the fixture cart total is actually $100.01 — the boundary case is not really covered despite the test name claiming it is. 2. checkout/pricing/legacy.ts:12 — Bug, Blocking. calculateFlatDiscount is still exported and still called from api/cart/quote.ts, so the old code path you asked me to check is in fact still reachable. No test covers this call site. 3. checkout/pricing/tiers.ts:8 — disagreement with stated trade-off, Minor. Hardcoded tier boundaries are noted as intentional, but the follow-up ticket referenced isn't linked anywhere in this PR or its description.
Verified against
Cursor 2.2 · 2026-07-30
Changelog
- 2026-07-30 — Initial publish, verified against Cursor BugBot's GitHub PR integration on Cursor 2.2.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
