code-review-graph

name	code-review-graph
description	Use the code-review-graph CLI for token-efficient code review, architecture exploration, impact analysis, caller/callee tracing, test coverage lookup, and code search. Before using graph features in a repository, check whether its graph has been built; if not, ask the user whether to build it.
compatibility	Requires code-review-graph 2.3.7 or newer on PATH and Python 3.10 or newer.

Code Review Graph

Use code-review-graph through Pi's bash tool. Pi does not provide the code-review-graph MCP tools directly, so do not attempt to call names such as query_graph_tool or detect_changes_tool.

Preflight

Before using graph-backed analysis in a repository:

1. Resolve the repository root with:

   git rev-parse --show-toplevel
   

2. Verify the CLI and its version:

   code-review-graph --version
   

   Continue only when stdout is exactly code-review-graph X.Y.Z and the semantic version is 2.3.7 or newer. If the version is older, missing, malformed, or a prerelease, stop CRG usage and ask the user to install or upgrade it.

3. Treat this command as the authoritative graph check:

   code-review-graph status --json --repo "<repo-root>"
   

Do not rely only on .code-review-graph/graph.db; CRG can store graph data in an external directory.

When the graph is missing

If status exits unsuccessfully because no graph exists:

1. Do not build automatically or run the build through bash.

2. Explain that this repository has not been indexed.

3. Ask the user to run the bundled Extension command:

   /crg-build
   

   That command jointly confirms the build and .gitignore mutation, rejects symlinked or non-regular .gitignore files, safely appends through a no-follow file descriptor without replacing existing content, rejects tracked CRG artifacts, and verifies the effective Git ignore rule before building.

4. If /crg-build is unavailable, explain that the Pi Package is incomplete or disabled; do not fall back to modifying .gitignore or building through bash.

5. If the user declines, continue with Pi's normal tools and do not ask again during the same task.

For a Pi-only workflow, do not run code-review-graph install or code-review-graph init. Those commands configure MCP clients and hooks for other platforms.

When the graph exists

Inspect the status before querying:

• If built_on_branch and current_branch differ, recommend /crg-build.

• For normal source changes, recommend the bundled incremental command:

  /crg-update
  

Do not run build or update through bash. Let the bundled Extension enforce version checks and report failures.

Query workflow

Prefer a compact graph query before broad file reads:

code-review-graph architecture --detail-level minimal --repo "<repo-root>"
code-review-graph search "<query>" --repo "<repo-root>"
code-review-graph query callers_of "<symbol>" --repo "<repo-root>"
code-review-graph query callees_of "<symbol>" --repo "<repo-root>"
code-review-graph query tests_for "<symbol>" --repo "<repo-root>"
code-review-graph impact --base HEAD~1 --repo "<repo-root>"
code-review-graph detect-changes --brief --repo "<repo-root>"

Use Pi's read, grep, and find tools to inspect only the source files identified by graph queries. Treat graph output as navigation and impact context, not as proof that the underlying source is correct.