code-reviewer

Savant verdict: Unsafe

Savant's security policy blocks importing this skill.

Live evaluation

Not evaluated yet. Workspaces can request a live evaluation.

Security assessment

3 patterns found

• analysis-evasion: scripts/review_checklist.py (partial)high · SKILL.md:222 · Referenced artifact was not completely inspected
• MCP Least Privilege: Code capability 'file_write' detected in scripts/review_checklist.py but not covered by declared permissions.high · scripts/review_checklist.py:1 · The skill uses 'file_write' capability that is not listed in its permissions. This may indicate deceptive intent or missing permission declarations.
• Dangerous Code Execution: subprocess.run( ["git", *args], capture_output=True, text=True, check=True )medium · scripts/review_checklist.py:16 · subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Structure

• Ships 1 executable scriptscripts/review_checklist.py. Review what they do before enabling the skill for agents with tool access.
• No license declaredConfirm you may reuse this skill before importing it into your repository.

SKILL.md

---
name: code-reviewer
description: Reviews pull requests and code changes for quality, security, and best practices. Use when user asks for code review, PR review, or mentions reviewing changes.
allowed-tools: Read, Grep, Glob, Bash, WebFetch, WebSearch
metadata:
  hooks:
    after_complete:
      - trigger: self-improving-agent
        mode: background
        reason: "Learn from review patterns"
      - trigger: session-logger
        mode: auto
        reason: "Log review activity"
---

# Code Reviewer

A comprehensive code review skill that analyzes pull requests and code changes for quality, security, maintainability, and best practices.

## When This Skill Activates

This skill activates when you:
- Ask for a code review
- Request a PR review
- Mention reviewing changes
- Say "review this" or "check this code"

## Review Process

### Phase 1: Context Gathering

1. **Get changed files**
   ```bash
   git diff main...HEAD --name-only
   git log main...HEAD --oneline
   ```

2. **Get the diff**
   ```bash
   git diff main...HEAD
   ```

3. **Understand project context**
   - Read relevant documentation
   - Check existing patterns in similar files
   - Identify project-specific conventions

### Phase 2: Analysis Categories

#### 1. Correctness
- [ ] Logic is sound and matches requirements
- [ ] Edge cases are handled
- [ ] Error handling is appropriate
- [ ] No obvious bugs or typos

#### 2. Security
- [ ] No hardcoded secrets or credentials
- [ ] Input validation and sanitization
- [ ] SQL injection prevention
- [ ] XSS prevention (for frontend)
- [ ] Authentication/authorization checks
- [ ] Safe handling of user data

#### 3. Performance
- [ ] No N+1 queries
- [ ] Appropriate caching
- [ ] Efficient algorithms
- [ ] No unnecessary computations
- [ ] Memory efficiency

#### 4. Code Quality
- [ ] Follows DRY principle
- [ ] Follows KISS principle
- [ ] Appropriate abstractions
- [ ] Clear naming conventions
- [ ] Proper typing (if TypeScript)
- [ ] No commented-out code

#### 5. Testing
- [ ] Tests cover new functionality
- [ ] Tests cover edge cases
- [ ] Test assertions are meaningful
- [ ] No brittle tests

#### 6. Documentation
- [ ] Complex logic is explained
- [ ] Public APIs have documentation
- [ ] JSDoc/TSDoc for functions
- [ ] README updated if needed

#### 7. Maintainability
- [ ] Code is readable
- [ ] Consistent style
- [ ] Modular design
- [ ] Separation of concerns

### Phase 3: Output Format

Use this structured format for review feedback:

```markdown
# Code Review

## Summary
Brief overview of the changes (2-3 sentences).

## Issues by Severity

### Critical
Must fix before merge.

- [ ] **Issue Title**: Description with file:line reference

### High
Should fix before merge unless there's a good reason.

- [ ] **Issue Title**: Description with file:line reference

### Medium
Consider fixing, can be done in follow-up.

- [ ] **Issue Title**: Description with file:line reference

### Low
Nice to have improvements.

- [ ] **Issue Title**: Description with file:line reference

## Positive Highlights
What was done well in this PR.

## Suggestions
Optional improvements that don't require immediate action.

## Approval Status
- [ ] Approved
- [ ] Approved with suggestions
- [ ] Request changes
```

## Common Issues to Check

### Security Issues

| Issue | Pattern | Recommendation |
|-------|----------|----------------|
| Hardcoded secrets | `const API_KEY = "sk-"` | Use environment variables |
| SQL injection | `\"SELECT * FROM...\" + user_input` | Use parameterized queries |
| XSS vulnerability | `innerHTML = user_input` | Sanitize or use textContent |
| Missing auth check | New endpoint without `@RequireAuth` | Add authentication middleware |

### Performance Issues

| Issue | Pattern | Recommendation |
|-------|----------|----------------|
| N+1 query | Loop with database call | Use eager loading or batch queries |
| Unnecessary re-render | Missing dependencies in `useEffect` | Fix dependency array |
| Memory leak | Event listener not removed | Add cleanup in useEffect return |
| Inefficient loop | Nested loops O(n²) | Consider hash map or different algorithm |

### Code Quality Issues

| Issue | Pattern | Recommendation |
|-------|----------|----------------|
| Duplicate code | Similar blocks repeated | Extract to function |
| Magic number | `if (status === 5)` | Use named constant |
| Long function | Function >50 lines | Split into smaller functions |
| Complex condition | `a && b || c && d` | Extract to variable with descriptive name |

### Testing Issues

| Issue | Pattern | Recommendation |
|-------|----------|----------------|
| No tests | New feature without test file | Add unit tests |
| Untested edge case | Test only covers happy path | Add edge case tests |
| Brittle test | Test relies on implementation details | Test behavior, not implementation |
| Missing assertion | Test doesn't assert anything | Add proper assertions |

## Language-Specific Guidelines

### TypeScript
- Use `unknown` instead of `any` for untyped values
- Prefer `interface` for public APIs, `type` for unions
- Use strict mode settings
- Avoid `as` assertions when possible

### React
- Follow Hooks rules
- Use `useCallback`/`useMemo` appropriately (not prematurely)
- Prefer function components
- Use proper key props in lists
- Avoid prop drilling with Context

### Python
- Follow PEP 8 style guide
- Use type hints
- Use f-strings for formatting
- Prefer list comprehensions over map/filter
- Use context managers for resources

### Go
- Handle errors explicitly
- Use named returns for clarity
- Keep goroutines simple
- Use channels for communication
- Avoid package-level state

## Before Approving

Confirm the following:
- [ ] All critical issues are addressed
- [ ] Tests pass locally
- [ ] No merge conflicts
- [ ] Commit messages are clear
- [ ] Documentation is updated
- [ ] Breaking changes are documented

## Scripts

Run the review checklist script:
```bash
python3 scripts/review_checklist.py --base main --output review-checklist.md
```

## References

- `references/checklist.md` - Complete review checklist
- `references/security.md` - Security review guidelines
- `references/patterns.md` - Common patterns and anti-patterns