helix4u/code-review

Code Review Skill

Use this skill when reviewing code changes, pull requests, or auditing existing code.

Review Checklist

1. Security First

• [ ] No hardcoded secrets, API keys, or credentials
• [ ] Input validation on all user-provided data
• [ ] SQL queries use parameterized statements (no string concatenation)
• [ ] File operations validate paths (no path traversal)
• [ ] Authentication/authorization checks present where needed

2. Error Handling

• [ ] All external calls (API, DB, file) have try/catch
• [ ] Errors are logged with context (but no sensitive data)
• [ ] User-facing errors are helpful but don't leak internals
• [ ] Resources are cleaned up in finally blocks or context managers

3. Code Quality

• [ ] Functions do one thing and are reasonably sized (<50 lines ideal)
• [ ] Variable names are descriptive (no single letters except loops)
• [ ] No commented-out code left behind
• [ ] Complex logic has explanatory comments
• [ ] No duplicate code (DRY principle)

4. Testing Considerations

• [ ] Edge cases handled (empty inputs, nulls, boundaries)
• [ ] Happy path and error paths both work
• [ ] New code has corresponding tests (if test suite exists)

Review Response Format

When providing review feedback, structure it as:

## Summary
[1-2 sentence overall assessment]

## Critical Issues (Must Fix)
- Issue 1: [description + suggested fix]
- Issue 2: ...

## Suggestions (Nice to Have)
- Suggestion 1: [description]

## Questions
- [Any clarifying questions about intent]

Common Patterns to Flag

Python

# Bad: SQL injection risk
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# Good: Parameterized query
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

JavaScript

// Bad: XSS risk
element.innerHTML = userInput;

// Good: Safe text content
element.textContent = userInput;

Tone Guidelines

• Be constructive, not critical
• Explain why something is an issue, not just what
• Offer solutions, not just problems
• Acknowledge good patterns you see