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.
Make tangled code easier to read and change without altering behavior, with every edit explained.
Simplify the {{language}} code below so it is easier to read, test and change. Behavior must stay exactly the same.
What the code is for: {{purpose}}
Priorities: {{priority}}
Style constraints (linters, team conventions, language version): {{style}}
Code:
{{code}}
Process:
1. First, in a few bullets, state what the code does, so I can confirm you understood it. List its inputs, outputs, side effects and error behavior.
2. Identify the specific sources of complexity: deep nesting, long functions, duplicated logic, unclear names, mixed responsibilities, boolean flags, hidden state, magic values, and error handling that obscures the main path.
3. Show the simplified version in full. Prefer early returns, small well-named functions, clear data structures, and removing dead code. Do not introduce new abstractions, patterns or dependencies that are heavier than the problem.
4. Give a change log: each edit, its reason, and a risk note if any edit could alter behavior in an edge case (such as null handling, ordering, or short-circuit evaluation).
5. List the tests I should run or write to prove nothing changed, naming the exact inputs that exercise the riskiest edits.
If you spot a real bug, do not silently fix it. Keep the behavior, point out the bug separately and show the one-line fix.Restating the behavior first lets you catch misunderstandings before any code changes. Reporting bugs separately keeps a cleanup from quietly altering behavior.
Licensed CC0 (public domain) Version 1 · history
Get a prioritized code review that separates real defects from style nits, with a concrete fix for each issue.
Prepare for a major library or framework upgrade: breaking changes, code to update and a safe rollout order.
Port code to another language so it reads like native code, with notes on behavior differences and gotchas.
Audit code or a feature design for vulnerabilities, mapped to realistic attack scenarios and fixes.
Create a PR description that helps reviewers understand the change, how to test it and what to watch for.
Plan a database, framework or infrastructure migration with phases, rollback points and verification at each step.
Comments (0)
Sign in to join the discussion.
No comments yet. Be the first to share how it worked.