mcpField
R
reviewing-code

reviewing-code

github.com/spencerpaulyTesting & quality868522 installsUpdated 13w ago
Repository

About reviewing-code

A code-review skill for examining changes when feedback or quality checks are requested. It covers correctness, maintainability, performance, TypeScript type safety, and tests, then organizes actionable findings by severity.

Key features

  1. 01Correctness and edge-case checks
  2. 02Maintainability review
  3. 03Performance checks
  4. 04TypeScript type-safety review
  5. 05Test coverage checks
  6. 06Severity-ranked feedback

Use cases

  1. 01Reviewing a feature or bug fix
  2. 02Checking asynchronous error handling
  3. 03Assessing tests for changed code

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill reviewing-code

After installing, type/reviewing-codein Claude Code to confirm it loaded.

Details

From the project README

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.

Comments

Markdown supported