review-work

Review Work — Automated Code Review

Review uncommitted code changes using Claude sub-agents as independent reviewers. The invoking agent (you) triages the diff and decides who reviews; reviewers self-prime via /prime, verify API/library claims via Context7, and report against progress.md intent.

This skill is run by an AI, not by a human — use judgment about the change you just made. Don't apply a fixed rubric mechanically. Zero external dependencies: reviewers are Claude sub-agents.

Process

Step 1: Capture the Diff (+ Tests)

Run these and save the output:

git diff --stat HEAD

git diff HEAD

git diff HEAD captures uncommitted work — the normal pre-commit flow. If the work was already committed (e.g. direct-to-main), review the last commit instead: git diff HEAD~1 HEAD (or git show HEAD).

If the project has a test command configured and relevant source changed, run it and capture the output:

# Use whatever test/build command is appropriate for this project's stack.
# e.g. npm test · pytest · cargo test · go test ./... · the test_command in
# hooks/config/pipeline.json if set.

Test/build failures are the #1 finding for every reviewer — include the failure output in each reviewer's prompt verbatim.

Step 2: Triage

Look at the changed file paths and produce two lists.

Impacted modules — by default the whole project is one scope (one project per repo). Only split into modules/components when the diff clearly spans distinct top-level areas (e.g. api/ vs web/, backend/ vs frontend/). If it's all one area, that's a single scope — don't manufacture splits.

Risk surfaces — flag the presence of any of these generic surfaces. For each one that fires, inject the matching focus-area line into reviewer prompts in Step 4:

Surface	Inject this focus-area line
Authentication / authorization	"Auth code touched — check for privilege escalation, missing access checks, and tokens/sessions handled correctly."
Database / schema migration	"Schema migration touched — check locking, backfills, NOT NULL on existing rows, and that access rules/constraints are preserved."
Configuration / secrets	"Config or secrets touched — confirm no secrets are hardcoded or logged, and environment-specific values aren't baked into source."
Dependency manifest	"Dependency manifest changed — confirm new deps are pinned, sourced legitimately, and not duplicating existing functionality."
Critical-path / user-facing flow	"Critical-path or user-facing flow touched — check error handling, input validation at boundaries, and that the happy path plus failure modes are covered."