Cursor Skill

reviewing-code

Perform a thorough code review focused on correctness, maintainability, performance, and best practices.

LLM Mart · 0 points · 26 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download spencerpauly-awesome-cursor-skills-resources_reviewing-code-99cd265.zip · 1 KB

spencerpauly/awesome-cursor-skills 790 140 forks CC0-1.0 Updated 53d ago

Part of spencerpauly/awesome-cursor-skills — 65 skills

Install

skills CLI npx skills add https://github.com/spencerpauly/awesome-cursor-skills/tree/main/resources/reviewing-code

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install spencerpauly-awesome-cursor-skills@llmmart

Git git clone https://github.com/spencerpauly/awesome-cursor-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole spencerpauly/awesome-cursor-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Code Review

Use this skill when the user asks for a code review, feedback on their code, or to check code quality.

Steps

Understand the change — read the files or diff to understand what the code is supposed to do. Identify the scope (new feature, bug fix, refactor).
Check correctness
- Does the code handle edge cases (empty input, null, zero, negative numbers)?
- Are error states handled (try/catch, error boundaries, fallback UI)?
- Does async code handle race conditions, cancellation, and timeouts?
- Are there off-by-one errors in loops or array access?
Check maintainability
- Are functions focused on a single responsibility?
- Are variable and function names descriptive?
- Is there unnecessary duplication that should be extracted?
- Are magic numbers replaced with named constants?
- Is the code complexity reasonable (deeply nested conditionals, long functions)?
Check performance
- Are there N+1 query patterns in database access?
- Are expensive computations or API calls happening in render loops?
- Are large lists missing virtualization or pagination?
- Are there missing indexes for common database queries?
- Is memoization used appropriately (not over-applied)?
Check type safety (TypeScript projects)
- Are there any types that should be narrowed?
- Are function return types explicit for public APIs?
- Are union types handled exhaustively?
Check testing
- Are there tests for the new/changed code?
- Do tests cover the happy path AND error cases?
- Are tests isolated (no shared mutable state)?
Provide feedback — organize findings by severity:
- Must fix: bugs, security issues, data loss risks
- Should fix: performance issues, maintainability concerns
- Nit: style preferences, minor suggestions
For each finding, include the file, line, the issue, and a suggested fix.

Notes

Be constructive — explain why something is a problem, not just that it is.
Acknowledge what's done well, not just what needs fixing.
Don't bikeshed on style issues that a linter/formatter should handle.

Files (awesome-cursor-skills)

SKILL.md 2.3 KB

---
name: reviewing-code
description: Perform a thorough code review focused on correctness, maintainability, performance, and best practices.
---

# Code Review

Use this skill when the user asks for a code review, feedback on their code, or to check code quality.

## Steps

1. **Understand the change** — read the files or diff to understand what the code is supposed to do. Identify the scope (new feature, bug fix, refactor).

2. **Check correctness**
   - Does the code handle edge cases (empty input, null, zero, negative numbers)?
   - Are error states handled (try/catch, error boundaries, fallback UI)?
   - Does async code handle race conditions, cancellation, and timeouts?
   - Are there off-by-one errors in loops or array access?

3. **Check maintainability**
   - Are functions focused on a single responsibility?
   - Are variable and function names descriptive?
   - Is there unnecessary duplication that should be extracted?
   - Are magic numbers replaced with named constants?
   - Is the code complexity reasonable (deeply nested conditionals, long functions)?

4. **Check performance**
   - Are there N+1 query patterns in database access?
   - Are expensive computations or API calls happening in render loops?
   - Are large lists missing virtualization or pagination?
   - Are there missing indexes for common database queries?
   - Is memoization used appropriately (not over-applied)?

5. **Check type safety** (TypeScript projects)
   - Are there `any` types that should be narrowed?
   - Are function return types explicit for public APIs?
   - Are union types handled exhaustively?

6. **Check testing**
   - Are there tests for the new/changed code?
   - Do tests cover the happy path AND error cases?
   - Are tests isolated (no shared mutable state)?

7. **Provide feedback** — organize findings by severity:
   - **Must fix**: bugs, security issues, data loss risks
   - **Should fix**: performance issues, maintainability concerns
   - **Nit**: style preferences, minor suggestions

   For each finding, include the file, line, the issue, and a suggested fix.

## Notes

- Be constructive — explain *why* something is a problem, not just that it is.
- Acknowledge what's done well, not just what needs fixing.
- Don't bikeshed on style issues that a linter/formatter should handle.