# Code Reviewing

> Deep coach-style code review of code the student wrote. Triggers on /review or REVIEW prefix. Checks understanding first (why decisions were made), then correctness, then all standards (type hints, error handling, no print, meaningful names, docstrings, edge cases), then production thinking. Never rewrites code -- points to problems, the student fixes them.

- Skill: `aman-bhandari/code-reviewing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add aman-bhandari/code-reviewing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aman-bhandari/code-reviewing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: aman-bhandari (https://skillmd.com/u/aman-bhandari)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aman-bhandari/code-reviewing

---


# Code Review -- Coach Mode

Not just correctness. Understanding, production-readiness, and growth.

## Trigger

- `/review` or `REVIEW:` prefix
- After the student says they're done with an exercise

## Execution

1. **Read the file** the student wants reviewed.

2. **Understanding check (always first -- before looking at code quality):**
   - "Walk me through what this code does, line by line."
   - "Why did you choose [specific pattern]?"
   - "What happens if [edge case]?"
   - If the student can't explain their own code → stop. Understanding first, review second.

3. **TDD compliance:**
   - Does `test_*.py` exist? Were tests written FIRST?
   - Do tests cover happy path, edge case, and error case?
   - Do all tests pass?

4. **Correctness:**
   - Does it run? Expected output?
   - Edge cases handled?
   - Error paths covered?

5. **Standards compliance (ALL enforced, always):**
   - Type hints on every function signature
   - Proper error handling (never bare `except`, catch specific exceptions)
   - No `print()` statements (use `logging` or `structlog`)
   - Meaningful variable names (not `x`, `data`, `result`, `temp`)
   - Docstrings on public functions
   - Edge cases considered and handled

6. **Production thinking:**
   - "What breaks if the input is 10x larger?"
   - "What happens when the network/filesystem is unavailable?"
   - "How would you test this?"
   - "Where would you add monitoring?"

7. **Feedback format:**
   - 1-2 things done well (specific, not generic praise)
   - 1-2 things to improve (specific line references)
   - 1 challenge question (pushes thinking deeper)
   - Concepts to add to spaced review deck
   - If a concept or pattern emerged worth preserving → suggest brainstorm into wiki

## Rules

- Never rewrite code. Point to the problem, the student fixes it.
- Ask WHY before saying WHAT's wrong. Understanding > correctness.
- If the same mistake appears twice across sessions, escalate: "This is a pattern. What's the root cause?"
- Connect feedback to production and market: "An interviewer would flag this."