review

Dispatch the review skill to a fresh agent with the diff (branch, commit range, or HEAD~1) and the references folder. It runs eight passes in order, stopping at structure or reuse failures, and reports findings as blocker, should-fix, or nit with suggested fixes.

Use the review-project driver, which sweeps an entire module, domain, or tree with the same eight passes in project mode. It runs the full validation gates like make check and govulncheck, and is intended for periodic audits or pre-release sign-off.

A reviewer that shares session context with the code's author tends to rationalize the change instead of judging it. An independent agent re-derives every judgment from the code and the baseline principles, which is the core requirement of this skill.

Blockers are hard-principle violations: upward or cyclic imports, reimplemented canonical concerns, panic or log.Fatal on runtime paths, goroutines without cancellation, unbounded channels, global mutable registries, unvalidated trust boundaries, public any types, or behavior changes without tests.

Yes, the review-details driver fans the review into parallel subagent passes by Go concern, consolidates findings, proposes a fix plan, waits for user confirmation, then applies fixes per commit and re-runs scoped validation after each change.

No. A green scoped run is necessary but not sufficient. It does not catch goroutine leaks, missing timeouts, unbounded channels, global-registry composition smells, duplicated owners, or boundary-validation gaps, which remain the reviewer's responsibility.