tim-hub/role-based-skills/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:

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?