Guides › Documents & Data
Catch problems in your code before review
A private first pass over your change that flags likely bugs, unclear names, missing tests and security risks before a colleague sees it.
When to use it
Before you open a pull request
Step by step
Copy your diff
Copy the diff of your change from your editor or GitHub. Remove secrets, keys and customer data, and check your company allows code to be shared with your AI tool.
Ask for a focused review
Paste the diff with this prompt.
Prompt to copyAct as a careful senior reviewer for [language/framework]. Here's my change and what it's meant to do: [one-line purpose]. Diff: [paste diff]. Review it and list findings grouped as: Bugs or logic errors, Security concerns, Error handling and edge cases, Missing or weak tests, Readability (naming, structure). For each finding give the file and line, why it matters, and a suggested fix. Rank by severity. Don't comment on style that a linter would catch. If something looks fine, don't invent problems.Fix what's real
Work through the findings, fix the genuine ones and ignore the rest. You know the codebase better than the assistant does.
Write the PR description
Ask: 'Write a short pull request description: what changed, why, how to test it and anything reviewers should look at closely.'
What you get
High - Bug: orders.js line 42, discount applied before tax is calculated, so totals are off for VAT-registered customers. Fix: move applyDiscount() after calcTax(). Medium - Missing test: no case for an empty basket.
Tips
- Give it the surrounding function or interface as well as the diff, or it will flag things that are handled elsewhere.
- Treat it as a second pair of eyes, not a replacement for your team's review.