tim-hub/reviewer

Reviewer

Review code changes from git history, then challenge every flaw using the challenger methodology.

Inputs

The user may provide:

• Two commit hashes: review changes from <start_hash> to <end_hash>
• One commit hash: review that single commit
• No commit hashes: review the last commit (HEAD~1..HEAD), stashed uncommited changes or unstashed changes

Workflow

Copy this checklist and track progress:

Review Progress:
- [ ] Step 1: Resolve commit range
- [ ] Step 2: Gather change context
- [ ] Step 3: Read changed files for pattern context
- [ ] Step 4: Analyze changes
- [ ] Step 5: Produce challenge report

Step 1: Resolve Commit Range

Determine the commit range based on user input:

| Input | Git range | |-------|-----------| | Two hashes: <start> <end> | <start>..<end> | | One hash: <hash> | <hash>~1..<hash> | | No hashes | HEAD~1..HEAD |

Run: git log --oneline <range> to confirm the commits exist and list them.

Step 2: Gather Change Context

Run these commands to collect the full picture:

# List all changed files
git diff --name-status <range>

# Get the full diff with context
git diff <range>

# Get commit messages for intent
git log --format="%h %s%n%b" <range>

Step 3: Read Changed Files for Pattern Context

For each modified file (not deleted), read the full current version to understand:

• Existing code style and conventions
• Patterns used in the surrounding code
• How similar functionality is implemented elsewhere in the same file

For new files, find similar files in the same directory or module to establish expected patterns:

# Find sibling files for pattern reference
ls <directory_of_new_file>/

Read 1-2 sibling files to understand local conventions.

Step 4: Analyze Changes

Review each change against these criteria:

Pattern Adherence (primary focus alongside challenger dimensions):

• Does the change follow the existing code style in the file?
• Are naming conventions consistent with the codebase?
• Does it reuse existing utilities rather than reinventing?
• Does it follow established architectural patterns in the module?
• Are imports organized consistently with the rest of the file?
• Does error handling follow the existing pattern?

Step 5: Produce Challenge Report

Apply the Challenger methodology from /Users/hbai/.cursor/skills/challenger/SKILL.md. Read that skill and follow its challenge dimensions and output format.

Add one extra dimension to the challenger report:

8. Pattern Adherence

• Deviations from existing code style
• Inconsistent naming with surrounding code
• Reinvented utilities that already exist
• Architectural pattern violations
• Import style inconsistencies

Output Format

Structure the final output as:

## Code Review: <short description of changes>

### Commits Reviewed
- `<hash>` <message>
- ...

### Files Changed
- A: <new files>
- M: <modified files>
- D: <deleted files>

## Challenge Report

### Critical (must fix)
- **[DIMENSION]**: Description. Why it's dangerous. Attack/failure scenario.

### High Risk (strongly recommend fixing)
- **[DIMENSION]**: Description. Impact. Scenario.

### Medium Risk (should consider)
- **[DIMENSION]**: Description. Impact. Scenario.

### Low Risk (nitpick / hardening)
- **[DIMENSION]**: Description.

### Summary
X critical, Y high, Z medium, W low issues found.
Verdict: SAFE / RISKY / DANGEROUS

Rules

1. Always read the actual changed code — never guess from file names alone.
2. Always read surrounding code — pattern adherence requires full file context.
3. Be specific — cite exact files, lines, and functions.
4. Never say "looks good" — there is always something to challenge.
5. Prioritize ruthlessly — critical issues first, nitpicks last.
6. Challenge assumptions — if the author assumes X, ask "what if not X?"
7. Question missing things — missing validation? missing tests? missing error handling?