review-spec

Provide the spec path and the reviewer reads the document, then independently greps the repository to verify every referenced file, function, flag, and command exists and behaves as described. The report rates five dimensions and ends with a Mergeable or Needs revision verdict.

Blocking findings are defects that would mislead implementation, such as nonexistent referenced files, behavior contradicting the code, unsafe designs, or internal contradictions. Wording issues, structural preferences, and hypothetical concerns are logged as non-blocking deferred findings.

Use spec review before implementation to validate the design document itself. Use code review after code exists, and general document review for non-spec documents. Each targets a different artifact and review depth.

The review auto-detects a target by checking git-modified spec files under docs/features, then staged markdown files, then the newest tech spec. If multiple candidates exist, it lists them and asks which to review.

Yes. After fixing blocking findings, the re-review continues on the same review thread using the saved thread identifier, preserving context from the previous round until the spec passes or the round cap is reached.