Use this scenario for a pull request, commit range, staged change, or named file set. A useful review is tied to an exact base and head revision, puts actionable findings first, and separates verified evidence from degraded or unsupported analysis.
OpenCode workflow
Connect OpenCode to CodeGraph. Open the project workspace under review and confirm that .opencode/commands/review.md is available. In the installed client, run:
/review
The command checks project and graph readiness, then identifies the base revision and changed files. It investigates high-risk findings and collects code-quality and architecture-impact review results. The report links to the source and check results used in the review.
If the graph is stale or unavailable, the command reports the reason and the next action. The report identifies the checks performed and the available data.
CLI review
Prepare the environment using the CLI guide. Run from the CodeGraph repository root in PowerShell, with an accessible GoCPG gRPC service and a registered project CPG matching the revision under review. Replace the quoted placeholders before running:
python -m src.cli review --db "<cpg-path>" --base-ref "<git-ref>" --format json --output-file "<report.json>"
Alternative scopes supported by the same command are:
python -m src.cli review --db "<cpg-path>" --staged --format markdown
python -m src.cli review --db "<cpg-path>" --files "<file1>" "<file2>" --format sarif --output-file "<results.sarif>"
Choose one scope. --base-ref compares the base with HEAD, not uncommitted working-tree changes. The security scan runs only with --base-ref and without --no-security; staged or file-only review does not include it. Record which checks ran.
Create the output directory and use a new report filename. --output-file writes the structured report without the progress messages printed to standard output. When the main format is sarif, --sarif-file does not write a separate file.
Check the exit status, new report, warnings, and analysis coverage. Status 1 can mean an operational error or critical/high findings; status 0 can still accompany degraded analysis. For JSON, inspect metadata.status, metadata.degradation_reasons, metadata.changed_file_paths, metadata.freshness, and findings. Read the findings alongside the changed files and check status; metadata.degradation_reasons lists the reasons for incomplete analysis.
The review_pipeline.auto_reparse setting controls graph updates: the default prompt defers the update, while auto starts it when the graph is available and its lag exceeds review_pipeline.stale_threshold_commits (default: 0). Check the result in metadata.refresh and graph freshness in metadata.freshness.
Review order
- Confirm base, head, changed files and task scope.
- Check behavior and acceptance-criterion mismatches before style.
- Inspect public interfaces, serialization, persistence, authorization and failure paths.
- Follow changed symbols to high-risk callers and cross-boundary dependencies.
- Check tests for both the intended behavior and important negative paths.
- Record each finding with severity, location, evidence, consequence and smallest safe correction.
- Re-run focused checks after corrections and keep unresolved items explicit.
An empty report records no findings for the configured scope. Record approval after confirming scope, readiness, enabled checks, and the accountable review decision.
This page is the concise scenario. For the full review model, findings and integrations, use the canonical Code Review Guide.