I spend a lot of time doing code reviews. It’s one of those things everyone agrees is important and it’s always a scramble to get them done. It’s probably the number one thing that slows down merges because context-switching is difficult especially when you have your own priorities and work to get done. Using Cursor to help with code reviews doesn’t excuse going through a PR\/MR manually and certainly pairing on code reviews with the code creator helps immensely, but it does help speed things up.<\/p>\n\n\n\n
Cursor lets you enable terminal command execution, which means you can point it straight at a pull request. I use the GitHub CLI for this:<\/p>\n\n\n\n
gh pr diff https:\/\/github.com\/account\/project\/pull\/1234<\/code><\/pre>\n\n\n\nThis pulls the full unified diff of the PR directly into Cursor’s context. No copy-pasting, no switching tabs, no losing your place.<\/p>\n\n\n\n
Alternatively, you can ask the AI to run the command directly without the need to switch your working branch.<\/p>\n\n\n\n
Either way, once you’ve run that command and the diff is loaded, the model you end up using for the code review now has the context it needs to do what it needs to do.<\/p>\n\n\n\n
The Prompt<\/h4>\n\n\n\n
Here’s the prompt:<\/p>\n\n\n\n
Please do a code review. Concentrate on functionality, syntax errors, \nand possible security issues.<\/code><\/pre>\n\n\n\nThat’s genuinely it. The simplicity is the point. I’m trying to make my life easier to utilizing AI, so I’m not trying to throw a ton of instructions at it .<\/p>\n\n\n\n
What the Output Looks Like<\/h4>\n\n\n\n
Here’s a sample of what Cursor might return after reviewing a PR\/MR that adds a new API endpoint:<\/p>\n\n\n\n
\nCode Review \u2014 PR #1234<\/strong><\/p>\n\n\n\nFunctionality<\/strong><\/p>\n\n\n\n\ngetUserById()<\/code> on line 42 is called without awaiting the result. The downstream handler assumes a resolved user object, so any request hitting this path will likely return undefined<\/code> data rather than throwing \u2014 making this silent and hard to catch in testing.<\/li>\n\n\n\n- The pagination logic in
listOrders()<\/code> applies the limit<\/code> before filtering by status<\/code>, which means pages can return fewer items than expected when most records are filtered out. The filter should run first.<\/li>\n<\/ul>\n\n\n\nSyntax \/ Code Quality<\/strong><\/p>\n\n\n\n\n- Line 87: unused import
parseDate<\/code> from date-fns<\/code>. Minor, but worth cleaning up to avoid confusion.<\/li>\n\n\n\n- The
switch<\/code> statement in routeAction()<\/code> is missing a default<\/code> case. If an unrecognized action string is passed, the function returns undefined<\/code> silently rather than throwing or logging.<\/li>\n<\/ul>\n\n\n\nSecurity<\/strong><\/p>\n\n\n\n\n- The
userId<\/code> parameter on line 61 is interpolated directly into a raw SQL string. This is a SQL injection risk \u2014 use parameterized queries or your ORM’s query builder instead.<\/li>\n\n\n\n- The error handler on line 114 returns the full stack trace in the response body. In production this leaks internal implementation details. Sanitize error responses before they leave the server.<\/li>\n<\/ul>\n\n\n\n
Summary<\/strong><\/p>\n\n\n\nTwo issues worth fixing before merge: the missing await<\/code> on getUserById()<\/code> and the SQL injection vector. The rest are improvements worth a follow-up ticket.<\/p>\n<\/blockquote>\n\n\n\nThat kind of output with specific line numbers, concrete problems, actionable fixes is what makes this actually useful rather than just a vibe check.<\/p>\n\n\n\n
Make It Even Smarter: The Cursor Rules File<\/h4>\n\n\n\n
A .cursor\/rules<\/code> file (or a CURSOR.md<\/code> at the root of your repo) helps even more. This is where you teach Cursor about your<\/em> project specifically.<\/p>\n\n\n\nHere’s what that file might look like:<\/p>\n\n\n\n
# Cursor Rules \u2014 MyProject\n\n## Build & Run\n- `npm run build` to compile\n- `npm run dev` to start the dev server (port 3000)\n- `npm test` to run the full test suite (Jest)\n\n## Linting & Formatting\n- ESLint config: `.eslintrc.js` \u2014 no unused variables, no `console.log` in production code\n- Prettier is enforced on commit via Husky\n- Run `npm run lint:fix` before raising a PR\n\n## Code Conventions\n- All API routes live in `\/src\/routes` \u2014 one file per resource\n- Database queries go through the repository layer in `\/src\/repositories` \u2014 never query directly from a controller\n- Use parameterized queries only \u2014 no raw string interpolation in SQL\n- Error responses must use the shared `ApiError` class from `\/src\/utils\/errors`\n\n## Security Notes\n- Never log request bodies \u2014 they may contain PII\n- All user-supplied IDs must be validated with `validateUUID()` before use\n- Auth middleware is applied globally; routes that bypass it must be explicitly listed in `PUBLIC_ROUTES`\n\n## PR Checklist\n- Tests added or updated for any changed behavior\n- No new `any` types in TypeScript without a comment explaining why\n- Migration files named `YYYYMMDD_description.sql`\n<\/code><\/pre>\n\n\n\nWhen Cursor reads this file alongside the diff, it knows your conventions. You can always type out a lot of these in the AI chat area, but having this file will save you from having to repeat these. The review now becomes a reflection of your team’s actual standards and not an inferred one or a generic checklist.<\/p>\n\n\n\n
Why This Works<\/h4>\n\n\n\n
All this turns Cursor into something close to a knowledgeable teammate doing a first-pass review. It’s important to remember that none of this is meant to replace human judgment on architecture decisions or product tradeoffs, but it can reliably catch stuff that is also easy to miss like syntax, injection risks, unused imports, violated conventions. That’s exactly the category of issue that’s easy to miss. The rules file is the part that makes the biggest difference. Spend a few minutes writing it once, and every review after that is better because of it.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
I spend a lot of time doing code reviews. It’s one of those things everyone agrees is important and it’s always a scramble to get them done. It’s probably the number one thing that slows down merges because context-switching is difficult especially when you have your own priorities and work to get done. Using Cursor […]<\/p>\n","protected":false},"author":1,"featured_media":265,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[165],"tags":[10,25,81,14,187,8,27,7],"class_list":["post-264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","tag-agile","tag-ai","tag-codereviews","tag-development","tag-llm","tag-productivity","tag-software","tag-softwaredevelopment"],"_links":{"self":[{"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=264"}],"version-history":[{"count":1,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/264\/revisions"}],"predecessor-version":[{"id":266,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/264\/revisions\/266"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/media\/265"}],"wp:attachment":[{"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.parhammofidi.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}