version: "1.0.0" name: code-review description: > Use when reviewing code for quality, correctness, security, and performance. Activate after completing a coding task or when the user asks for a code review.

Code Review Skill

Perform a structured code review on completed code. Follow the checklist below and provide feedback in the specified format.

When to Use This Skill

• After completing a coding task, before presenting results to the user
• When the user explicitly asks for a code review
• When refactoring or improving existing code
• Before finalizing any non-trivial code change

Review Workflow

1. Read the code — Use read_file to load all relevant source files
2. Understand the intent — What is this code supposed to do?
3. Run the checklist — Go through each category below systematically
4. Test if possible — Execute the code and its tests to verify behavior
5. Report findings — Use the feedback format at the bottom

Review Checklist

Correctness

• [ ] Does the code do what it's supposed to do?
• [ ] Are edge cases handled (empty input, None, boundary values)?
• [ ] Are there any off-by-one errors?
• [ ] Are return values and error conditions checked?
• [ ] Does the code handle concurrent/async scenarios correctly?

Security

• [ ] No hardcoded credentials, API keys, or secrets
• [ ] Input validation on all external data
• [ ] No injection vectors (SQL, command, path traversal)
• [ ] Proper error handling that doesn't leak internal details
• [ ] Sensitive data is not logged or printed

Performance

• [ ] No unnecessary loops or redundant computations
• [ ] Appropriate data structures used (dict for lookups, set for membership)
• [ ] No memory leaks or unbounded growth (unbounded lists, caches without eviction)
• [ ] I/O operations are efficient (buffered reads, batch operations)
• [ ] No premature optimization that hurts readability

Readability

• [ ] Clear, descriptive variable and function names
• [ ] Functions are focused and not too long (< 50 lines preferred)
• [ ] Complex logic has comments explaining why, not what
• [ ] Consistent code style throughout
• [ ] No dead code or commented-out blocks

Testing

• [ ] Are there tests for the new code?
• [ ] Do tests cover happy path and edge cases?
• [ ] Are tests readable and maintainable?
• [ ] Do all tests pass?

Python-Specific

• [ ] Type hints on function signatures
• [ ] Docstrings on public functions and classes
• [ ] Context managers used for resource management (files, connections)
• [ ] f-strings preferred over .format() or % formatting
• [ ] pathlib used for file path operations

Feedback Format

When reporting review findings, use this structure:

## Code Review Summary
[1-2 sentence overview of the code quality]
 
## Issues Found
 
### [Critical/Major/Minor]: [Short Description]
- **File:** path/to/file.py
- **Line:** 42
- **Issue:** Description of the problem
- **Suggestion:** How to fix it
- **Example:**
  ```python
  # Before
  data = eval(user_input)
  # After
  data = json.loads(user_input)
  ```
 
## Positive Notes
- [Things done well — acknowledge good patterns]
 
## Recommendations
- [Optional: broader suggestions for improvement]

Severity Levels

• Critical: Security vulnerabilities, data loss risk, crashes. Must fix.
• Major: Bugs, missing error handling, performance issues. Should fix.
• Minor: Style issues, naming, minor improvements. Nice to fix.