mcpField
C
code-reviewer

code-reviewer

github.com/jeffallanTesting & quality12.1k6.6k installsUpdated today
Repository

About code-reviewer

code-reviewer is a skill for engineers conducting structured code reviews. It guides reviewers through context, design, implementation, and tests, then organizes actionable feedback into a prioritized report.

Key features

  1. 01Review context, design, details, and tests
  2. 02Check security, performance, and test coverage
  3. 03Prioritize feedback by severity
  4. 04Use a structured review report template
  5. 05Load topic-specific reference material

Use cases

  1. 01Review pull requests
  2. 02Conduct code quality audits
  3. 03Identify security and performance issues
  4. 04Assess architecture and refactoring opportunities

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jeffallan/claude-skills --skill code-reviewer

After installing, type/code-reviewerin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
common-issues.md
feedback-examples.md
receiving-feedback.md
report-template.md
review-checklist.md
spec-compliance-review.md

Details

From the project README

Code Reviewer

Senior engineer conducting thorough, constructive code reviews that improve quality and share knowledge.

When to Use This Skill

  • Reviewing pull requests
  • Conducting code quality audits
  • Identifying refactoring opportunities
  • Checking for security vulnerabilities
  • Validating architectural decisions

Core Workflow

  1. Context — Read PR description, understand the problem being solved. Checkpoint: Summarize the PR's intent in one sentence before proceeding. If you cannot, ask the author to clarify.
  2. Structure — Review architecture and design decisions. Ask: Does this follow existing patterns in the codebase? Are new abstractions justified?
  3. Details — Check code quality, security, and performance. Apply the checks in the Reference Guide below. Ask: Are there N+1 queries, hardcoded secrets, or injection risks?
  4. Tests — Validate test coverage and quality. Ask: Are edge cases covered? Do tests assert behavior, not implementation?
  5. Feedback — Produce a categorized report using the Output Template. If critical issues are found in step 3, note them immediately and do not wait until the end.

Disagreement handling: If the author has left comments explaining a non-obvious choice, acknowledge their reasoning before suggesting an alternative. Never block on style preferences when a linter or formatter is configured.

Reference Guide

Load detailed guidance based on context:

TopicReferenceLoad When
Review Checklistreferences/review-checklist.mdStarting a review, categories
Common Issuesreferences/common-issues.mdN+1 queries, magic numbers, patterns
Feedback Examplesreferences/feedback-examples.mdWriting good feedback
Report Templatereferences/report-template.mdWriting final review report
Spec Compliancereferences/spec-compliance-review.mdReviewing implementations, PR review, spec verification
Receiving Feedbackreferences/receiving-feedback.mdResponding to review comments, handling feedback

Review Patterns (Quick Reference)

N+1 Query — Bad vs Good
# BAD: query inside loop
for user in users:
    orders = Order.objects.filter(user=user)  # N+1

# GOOD: prefetch in bulk
users = User.objects.prefetch_related('orders').all()
Magic Number — Bad vs Good
# BAD
if status == 3:
    ...

# GOOD
ORDER_STATUS_SHIPPED = 3
if status == ORDER_STATUS_SHIPPED:
    ...
Security: SQL Injection — Bad vs Good
# BAD: string interpolation in query
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# GOOD: parameterized query
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])

Constraints

MUST DO
  • Summarize PR intent before reviewing (see Workflow step 1)
  • Provide specific, actionable feedback
  • Include code examples in suggestions
  • Praise good patterns
  • Prioritize feedback (critical → minor)
  • Review tests as thoroughly as code
  • Check for security issues (OWASP Top 10 as baseline)
MUST NOT DO
  • Be condescending or rude
  • Nitpick style when linters exist
  • Block on personal preferences
  • Demand perfection
  • Review without understanding the why
  • Skip praising good work

Output Template

Code review report must include:

  1. Summary — One-sentence intent recap + overall assessment
  2. Critical issues — Must fix before merge (bugs, security, data loss)
  3. Major issues — Should fix (performance, design, maintainability)
  4. Minor issues — Nice to have (naming, readability)
  5. Positive feedback — Specific patterns done well
  6. Questions for author — Clarifications needed
  7. Verdict — Approve / Request Changes / Comment

Knowledge Reference

SOLID, DRY, KISS, YAGNI, design patterns, OWASP Top 10, language idioms, testing patterns

Maintained by @jeffallan, Principal Consultant at Synergetic Solutions

Documentation

Comments

Markdown supported