Pull request review with ranked findings

Get a prioritized code review that separates real defects from style nits, with a concrete fix for each issue.

LLazyPrompt(@lazyprompt)CodingCritiqueWorks with any model
No ratings yetSign in to rate
Save 0 Fork Report
Prompt template
Review the following {{language}} change as a careful senior engineer who will be on call for it.

Context: {{context}}
Review focus: {{focus}}

Diff or code:
{{diff}}

How to review:
- Read the whole change before commenting. Work out what it is trying to do, then check whether it does it.
- Only raise issues you can point to in the code. If something depends on code you cannot see, say what you would need to check instead of guessing.
- Skip formatting and naming nitpicks unless they hide a real problem.

Output format:
1. Verdict: approve, approve with changes, or request changes, in one sentence with the main reason.
2. Blocking issues: bugs, data loss, security holes, broken edge cases. For each give the location, why it fails (with a concrete input or scenario), and a suggested fix as a short code snippet.
3. Should fix: maintainability, missing tests, unclear error handling.
4. Optional suggestions: keep to at most three.
5. What is done well: one or two specifics.
6. Missing tests: list the cases you would add.
Example output
**Verdict:** Request changes. The idempotency check has a race that can still double-charge. **Blocking issues** 1. `handleWebhook`, dedupe check: you read `processedEvents` and write it in two separate steps. Two deliveries of the same event arriving together both pass the read and both charge. Fix: make the insert the guard. ```ts const inserted = await db.insertIfAbsent("processed_events", { id: event.id }); if (!inserted) return res.status(200).end(); ``` 2. Retry loop swallows the final error. After the last attempt the function returns normally, so the provider sees a 200 and never retries. Rethrow after the last attempt. **Should fix** - Retries use a fixed 100 ms delay; use exponential backoff with jitter or a retry storm will hit the payment API. - Event id is logged together with the card fingerprint. Drop the fingerprint. **Optional** - Extract the retry loop into a small helper so it can be tested alone. **Done well:** The handler is small and the signature check happens before any parsing. **Missing tests:** duplicate event delivered concurrently; provider returns 500 on every attempt; malformed signature.

Why it works

It forces a verdict first and ranks findings by severity, so the author sees what blocks the merge. Requiring a concrete failing scenario for each issue cuts speculative comments. Paste the surrounding files for deeper checks.

Licensed CC0 (public domain) Version 1 · history