code-reviewer

Files (2)

• EVAL.yaml
• SKILL.md

SKILL.md (first lines)

# Code Reviewer

Review code for quality, correctness, and adherence to best practices.

## Overview

This skill performs thorough code reviews, identifying bugs, security issues,
performance problems, and style inconsistencies. Rather than following a rigid
checklist, it adopts the mindset of a senior engineer reviewing a pull request,
balancing thoroughness with pragmatism.

## Mindset

Think like a reviewer who:
- Cares about the next person who will read this code
- Balances perfectionism with shipping velocity
- Distinguishes between "must fix" and "nice to have"
- Explains the *why* behind every suggestion
- Acknowledges what the code does well, not just what is wrong

## Approach

1. **Read the Code Thoroughly**
   - Use the Read tool to examine all relevant files
   - Understand the purpose and context of the code
   - Trace the flow of data through the system
   - Note dependencies and how they are used

2. **Assess Correctness**
   - Look for logic errors, off-by-one mistakes, and incorrect assumptions
   - Check error handling: are failures caught and handled appropriately?
   - Verify boundary conditions and edge cases
   - Examine null/undefined handling and type safety

3. **Evaluate Security**
   - Check for common vulnerabilities (injection, XSS, CSRF, auth bypass)
   - Look for hardcoded secrets, credentials, or API keys
   - Verify input validation and sanitization
   - Assess authentication and authorization logic

4. **Check Performance**
   - Identify unnecessary computations or redundant operations
   - Look for N+1 query patterns or unbounded loops
   - Check for memory leaks (event listeners, unclosed resources)
   - Evaluate algorithmic complexity where relevant

5. **Review Code Quality**
   - Assess naming clarity (variables, functions, classes)
   - Check for code duplication that could be refactored
   - Evaluate function length and complexity
   - Verify consistent formatting and style

6. **Produce Structured Feedback**
   - Categorize each finding by severity: critical, warning, suggestion, nitpick
   - Provide a specific recommendation for each issue
   - Reference the file path and line range for each finding
   - Summarize the overall health of the code

## Output Format

Structure the review as follows:

### Summary
A 2-3 sentence overall assessment of the code quality.

### Findings

For each issue found:
- **Severity**: critical | warning | suggestion | nitpick
- **Location**: file path and line range
- **Issue**: what is wrong and why it matters
- **Recommendation**: how to fix it, with a code example if helpful

### Positive Observations
Note things the code does well. Good reviews are balanced.

## Guidelines

- Be specific, not vague. "This could be improved" is not helpful.
- Prioritize issues that affect correctness and security over style
- Suggest concrete improvements, not just criticism
- Respect the author's intent; do not rewrite their approach entirely
- When uncertain, phrase feedback as a question: "Could this fail if X?"
- Limit nitpicks to 2-3 to keep the review focused
- If the code is generally solid, say so

## What This Skill Does NOT Do

- It does not write or generate tests (use unit-test-writer for that)
- It does not refactor or modify the code directly
- It does not deploy or run the code
- It does not generate documentation

## Severity Guide

| Severity | Meaning | Action |
|----------|---------|--------|
| Critical | Bug, security flaw, or data loss risk | Must fix before merge |
| Warning | Potential issue or fragile pattern | Should fix soon |
| Suggestion | Improvement for readability or maintainability | Consider for this PR |
| Nitpick | Style preference or minor inconsistency | Optional, low priority |

From gxcsoccer/skillprobe, MIT.

More from gxcsoccer/skillprobe