メインコンテンツまでスキップ

Review scope and use cases

River Review is not a tool that reviews only the PR diff.

In AI-assisted development, many decisions happen before any code is written. When the interpretation of requirements, design direction, implementation plan, test policy, and the granularity of the completion report stay ambiguous, reviewing only after implementation leads to large rework.

River Review receives these decisions as artifacts and reviews them with team-owned skills.

Implementation status

This page describes the conceptual review targets River Review aims for. The current CLI support status is as follows.

  • The CLI subcommands map to the three phases: upstream / midstream / downstream.
  • review plan and review exec --plan are available. review verify is not yet implemented (#802; it currently returns exit code 3).
  • Pre-execution requirements/design review and post-execution report review are achieved by passing artifact inputs (review-self / review-external / pbi-input / plan, etc.). There is, however, no dedicated "requirements review" or "report review" CLI mode.

The conceptual breakdown below remains valid; note that some targets do not map directly to a CLI command.

Review targets

TargetTimingWhat River Review checksTypical inputs
RequirementsPre-executionWhether goal, success criteria, scope, out-of-scope, and open questions are clearIssue, PBI, user request, acceptance criteria
DesignPre-executionWhether it is consistent with existing design, has proper separation, not over-builtADR, design memo, architecture direction
PlanPre-executionWhether work breakdown, blast radius, risks, and test policy are in placePlan, Work Packet, verification policy
DiffPost-executionWhether the implementation is consistent with requirements / design / planPR diff, changed files, test diff
ReportPost-executionWhether rationale, verification results, open items, and evidence remainFinal report, review results, verification logs

Pre-execution review

The goal of pre-execution review is to reduce ambiguity and risk before an AI agent or developer starts work.

Requirements Review

Requirements review checks whether what should be built is clear.

Key viewpoints:

  • Whether there is a correspondence to the user request or Issue
  • Whether the success criteria are concrete
  • Whether scope and out-of-scope are stated explicitly
  • Whether open questions are listed before implementation

Design Review

Design review checks whether the implementation direction is consistent with the existing design.

Key viewpoints:

  • Whether it conflicts with the existing architecture
  • Whether responsibilities are properly separated
  • Whether it is over-built
  • Whether future extensibility and implementation cost are balanced

Plan Review

Plan review checks whether the work is organized to the granularity needed to start implementation.

Key viewpoints:

  • Whether the work is broken into Work Packets
  • Whether the blast radius is stated explicitly
  • Whether risks and constraints are listed
  • Whether there is a test policy and verification commands
  • Whether the conditions requiring human approval are stated explicitly

Post-execution review

The goal of post-execution review is to check that what was built does not deviate from the plan or team standards.

Diff Review

Diff review checks the PR diff and changed files.

Key viewpoints:

  • Whether the implementation is consistent with requirements / design / plan
  • Whether it contains unnecessary or oversized changes
  • Whether it violates team standards such as security, accessibility, dependencies, or migration policy
  • Whether the test diff matches the change

Report Review

Report review checks the rationale and verification results at completion.

Key viewpoints:

  • Whether it explains what was changed
  • Whether it records which verification was performed
  • Whether open items and known constraints are stated explicitly
  • Whether information that can be traced later as evidence remains

Relationship with PlanGate

River Review and PlanGate do not compete; they have different roles.

ToolRole
River ReviewReviews requirements / design / plan / diff / report and points out issues, risks, and missing info
PlanGateBased on River Review results and plan info, decides go/no-go such as GO / NO-GO / NEEDS_REVISION

In other words, River Review reviews; PlanGate blocks / passes.

Even when PlanGate owns the pre-implementation gate, River Review can provide the requirements / design / plan review results upstream of it.

Examples of when to use each

What you want to doReview to use
Check whether an Issue is at an implementable granularityRequirements Review
Check whether the design direction conflicts with the architectureDesign Review
Check whether a plan handed to an AI agent is sufficientPlan Review
Check whether the PR diff deviates from the planDiff Review
Check whether the completion report retains verification and rationaleReport Review

Important premise

River Review is not meant to replace human judgment.

It is a review engine that makes the team's judgment criteria explicit as skills, reduces oversights, and lets humans focus on the more important judgments.