Skip to main content

/review — Universal Review Gate

Validate any artifact against its wish criteria. Always dispatched as a separate subagent — never review your own work inline.

When to Use

  • Before /work — validate a wish plan is ready for execution
  • After /work — verify implementation meets acceptance criteria
  • Before merge — check a PR diff against wish scope

Flow

  1. Detect target — determine what is being reviewed (wish draft, completed work, or PR diff).
  2. Select pipeline — match target to Plan, Execution, or PR checklist.
  3. Run checklist — evaluate each criterion, collecting evidence.
  4. Run validations — execute any validation commands; capture pass/fail output.
  5. Tag gaps — classify every unmet criterion by severity.
  6. Return verdict — SHIP, FIX-FIRST, or BLOCKED.
  7. Write next steps — exact fixes, files, and commands for each gap.

Pipelines

Plan Review (before /work)

  • Problem statement is one sentence and testable
  • Scope IN has concrete deliverables
  • Scope OUT is explicit
  • Every task has testable acceptance criteria
  • Tasks are bite-sized and independently shippable
  • Dependencies tagged
  • Validation commands exist for each group

Execution Review (after /work)

  • All acceptance criteria met with evidence
  • Validation commands run and passing
  • No scope creep — only wish-scoped changes
  • Quality pass: security, maintainability, correctness
  • No regressions introduced

PR Review (before merge)

  • Diff matches wish scope — no unrelated changes
  • No secrets, credentials, or hardcoded tokens in diff
  • Tests pass
  • Commit messages reference wish slug

Severity & Verdicts

SeverityMeaningBlocks?
CRITICALSecurity flaw, data loss, crashYes
HIGHBug, major perf issueYes
MEDIUMCode smell, minor issueNo
LOWStyle, naming preferenceNo
VerdictConditionNext step
SHIPZero CRITICAL/HIGH gapsProceed to next phase
FIX-FIRSTAny CRITICAL/HIGH gapAuto-invoke /fix
BLOCKEDScope or architecture issueEscalate to human

Auto-Fix on FIX-FIRST

  1. Auto-invoke /fix with the severity-tagged gap list.
  2. After fix, re-run /review (max 2 fix loops).
  3. If still FIX-FIRST after 2 loops, escalate as BLOCKED.

Task Lifecycle Integration

When a PG task exists for the reviewed work, the review verdict is logged as a task comment:
EventCommand
Review startgenie task comment #<seq> "Review: evaluating criteria..."
SHIP verdictgenie task comment #<seq> "Review: SHIP — all criteria met"
FIX-FIRST verdictgenie task comment #<seq> "Review: FIX-FIRST — N gaps found"
Council participation results are also logged when the council is consulted during review.

Rules

  • Never mark PASS without evidence
  • Never ship with CRITICAL or HIGH gaps
  • Never implement fixes during review — hand off to /fix
  • Every FAIL includes actionable fix (file, command, what to change)