Skip to content

Phase 4: Review

Comprehensive code review using 6 parallel specialized reviewers.

Command: /vt-c-4-review [--scope path/to/review]

When to use

After completing implementation in Phase 3. The review runs in a forked context (context: fork) so it forms an independent assessment without being influenced by the build conversation.

What happens

  1. Test gate verification -- Reads .test-gate.md from the project root. If the file is missing, has status: FAIL, or was generated on a different branch, the review is blocked. Run the test-runner in full suite mode first.

    Gate State Result
    status: PASS, branch matches Review proceeds
    status: FAIL Blocked — fix failing tests
    File missing Blocked — run full test suite
    Branch mismatch Blocked — stale gate, re-run on current branch

  2. Checkpoint and focus -- Reads the build checkpoint for focus hints, but forms its own independent conclusions.

  3. Parallel reviewers dispatch simultaneously (framework-conditional):
Reviewer Focus
security-sentinel OWASP vulnerabilities, XSS, injection, auth
kieran-typescript-reviewer TypeScript quality, strict typing (default — skipped when framework detected)
angular-reviewer Angular 21 patterns, Signals, PrimeNG, zoneless (when angular.json exists — replaces TS reviewer)
nestjs-reviewer NestJS modules, controllers, DTOs, guards, pipes (when nest-cli.json exists — replaces TS reviewer)
julik-frontend-races-reviewer Race conditions, async/DOM state
code-simplicity-reviewer YAGNI, complexity, dead code
performance-oracle N+1 queries, memory leaks, bundle size
pattern-recognition-specialist Design patterns, anti-patterns
  1. Findings classification -- Issues are rated Critical, High, Medium, or Low.

  2. Auto-fix loop -- After classifying findings, the review automatically attempts to fix mechanical issues:

    • Each finding is tagged [AUTO-FIXABLE] or [HUMAN-REQUIRED] based on a deterministic heuristic (e.g., naming fixes and dead code removal are auto-fixable; architecture decisions are human-required)
    • All Critical findings are always [HUMAN-REQUIRED]
    • Auto-fixes run up to 2 iterations with a 60s per-fix / 120s total timeout
    • After each fix, only the affected reviewers re-run on the changed files
    • Findings that persist after 2 attempts are reclassified as [HUMAN-REQUIRED]
    • The review report includes an "Auto-Fix Summary" showing what was resolved

  3. Quality gate -- PASS requires all of:

    • .test-gate.md status is PASS
    • Zero Critical findings (auto-fixed findings marked [RESOLVED] don't count)
    • No more than 2 High findings
  4. Spec compliance (when SpecKit active) -- Validates implementation against the active specs/[N]-feature/spec.md requirements (see .design-state.yaml for the active spec) and .specify/memory/constitution.md principles.
  5. Documentation check (when docs/user-manual/ exists) -- Verifies feature documentation pages exist and are non-empty. Reported as Medium severity.

See Testing Procedures for details on running tests and the gate file format. See Documentation Guide for the documentation workflow.

Output

  • Review report with findings by category and severity
  • Quality gate decision (PASS or FAIL)
  • Spec compliance coverage percentage (when SpecKit active)
  • Specific fix guidance for any failed items

Next step