
Reviewing Code
- 262 installs
- 655 repo stars
- Updated August 2, 2026
- spencerpauly/awesome-cursor-skills
Helps with ai & agent building tasks.
About
reviewing-code is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.
- reviewing-code
- AI & Agent Building
- AI-coding skill
Reviewing Code by the numbers
- 262 all-time installs (skills.sh)
- +32 installs in the week ending Jul 27, 2026 (Skillselion tracking)
- Ranked #2,467 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill reviewing-codeAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 262 |
|---|---|
| repo stars | ★ 655 |
| Last updated | August 2, 2026 |
| Repository | spencerpauly/awesome-cursor-skills ↗ |
What it does
Helps with ai & agent building tasks.
Files
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
anytypes 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.