spec-review

Review the change

spec-implement reviews each batch as it's built. This skill reviews the finished whole, the way a careful human reviewer would before merge: does it do what was asked, does it follow how this project works, and is the code sound? Every finding is checked against the code before it's reported. A short list of real problems beats a long list of guesses.

investigate → create → approve → implement → verify → review → checkpoint → ship

Project config (read first)

Load .spec-driven.yml: walk up from the current directory to the home folder, and the first one found wins (a multi-repo config only applies inside the repos it lists). If none is found, check ~/.spec-driven/workspaces.json, which maps each multi-repo config to its repo paths. Use the config whose repos contain the current directory. Its values beat anything you would detect or assume. This skill uses git (base branch, PR target), commands (lint/typecheck/test), models/effort, layout/repos, and specs_dir.

Multi-repo: review each listed repo that has changes on this branch, and write one review.md covering all of them. No config? Work from the repo itself and say what you assumed.

Step 1: Work out what to review

The user gave	Diff to review	Spec
nothing, on a spec's branch	git diff <merge-base with pr_target>...HEAD, plus uncommitted changes	{specs_dir}/{feature}/ matched by branch or ticket
a PR number or URL	gh pr diff <n> and gh pr view <n>	the PR's linked spec, if any
a branch, commit range, or paths	that diff	none, unless one matches

No spec? Review against the PR or commit description and the code alone, and say so in the report.

Step 2: Load only what the review needs

Keep it cheap, because the diff is the expensive part:

1. The README's Resume here block, requirements.md (requirements R1… and Coverage), and the investigation's Relevant Context. Without a spec, read {specs_dir}/CONTEXT.md and only the context/<area>.md files the diff touches. Never the archive.
2. git diff --stat first, then the diff itself. Open a full file only around a suspected finding, to confirm it.
3. Optional graph. If context.graph isn't off and graphify is available, use graphify query "callers of <changed function>" --budget 1000 to find callers the diff didn't update. Treat INFERRED edges as hints to check.