code-review

name	code-review
description	Quality and semantic review — catches what automated tools miss
version	0.1.0
level	3
triggers	["review this","code review","review the code","pre-merge review","/code-review"]
context_files	["context/security-standards.md"]
steps	[{"name":"Scope","description":"List files under review. State what this review covers and what it does not."},{"name":"Semantic Review","description":"Check for semantic anti-patterns — code that is syntactically correct but logically wrong"},{"name":"Logic Review","description":"Trace the critical paths. Does the code actually do what it claims to do?"},{"name":"Error Handling","description":"What happens on every failure path? Are errors silenced, swallowed, or lost?"},{"name":"Test Coverage","description":"Do the tests actually exercise the behavior, or do they just cover lines?"},{"name":"Readability","description":"Will the next developer understand this code without asking the author?"},{"name":"Security Pass","description":"Flag anything that warrants a full security-gate run (do not duplicate security-gate)"},{"name":"Verdict","description":"APPROVE / REQUEST CHANGES / BLOCK — with specific, actionable feedback. Then write the current ISO timestamp to `.claude/context/.review-done` (signals stop-review-gate that review completed)."}]

Code Review Skill

Quality and semantic review. Separate from security-gate (which is an OWASP pass) — this reviews logic, correctness, and maintainability.

What Claude Gets Wrong Without This Skill

Without explicit semantic review, Claude's code review focuses on what it can see at a glance — naming, formatting, obvious bugs. It misses logical errors that are invisible unless you trace execution, tests that assert the wrong thing, and anti-patterns that only become problems under load or edge cases.

Semantic Anti-Patterns to Actively Check

These are the patterns that pass linting, pass type checking, and still cause production incidents:

Silent failure

# WRONG — exception swallowed, caller never knows it failed
try:
    result = process(data)
except Exception:
    pass

# RIGHT — at minimum, log and re-raise or return an error

Boolean parameter flags

# WRONG — caller has no idea what True means
render_page(user, True)

# RIGHT — use explicit keyword args or separate functions
render_page(user, include_draft=True)

Mutable default arguments

# WRONG — default list is shared across all calls
def append_item(item, items=[]):
    items.append(item)
    return items

# RIGHT
def append_item(item, items=None):
    if items is None:
        items = []

Late error detection Code that validates input halfway through execution after already modifying state. Validate first, act second.

Asymmetric error handling Some code paths return None on failure, others raise exceptions, others return False. Callers must handle all three.

Test that tests the mock