Gemini CLI: Summarize a Repo Before Code Review

Before reviewing a pull request, give yourself a smaller assignment: understand where the change belongs. Use this desk-side walkthrough to request a short repository map, connect it to the diff, and collect questions worth investigating. Keep the output as a navigation aid—not an approval recommendation.

1. Prepare Gemini CLI and your repository

If needed, install Gemini CLI with npm install -g @google/gemini-cli, then check the installation with gemini --version. The documented runtime requirement is Node.js 20 or newer. Complete authentication using your organization's approved method. ([geminicli.com](https://geminicli.com/docs/get-started/installation/?utm_source=openai))

Open a terminal in the repository root. Before sharing source code, confirm that your organization's policies permit the selected AI service. Keep credentials, production exports, and customer records out of the material you provide. For an unfamiliar repository, inspect its local configuration before launching an agent.

2. Establish the exact review boundary

Check out the pull request branch using your normal workflow. Run git status --short and record any existing local changes so you can distinguish them from the review target. ([git-scm.com](https://git-scm.com/docs/git-status))

Refresh the relevant remote references, then run git diff --stat origin/main...HEAD and git diff --name-only origin/main...HEAD. Replace origin/main with the pull request's actual target branch. The three-dot comparison shows changes from the branches' merge base to HEAD; it does not include uncommitted edits. ([git-scm.com](https://git-scm.com/docs/git-diff))

Keep the changed-file list beside your terminal. Set an initial scope: the affected package, its immediate callers, and its tests—not every directory in a large monorepo.

3. Launch Gemini CLI in Plan Mode

Run gemini --approval-mode=plan. Plan Mode is designed for read-only investigation rather than implementation, although it permits planning documents in its designated planning directory. Stay in this mode throughout the summary exercise. ([geminicli.com](https://geminicli.com/docs/cli/plan-mode/?utm_source=openai))

Give the session an explicit boundary: “Prepare a repository summary for a human code reviewer. Inspect files only. Do not modify source files, install dependencies, execute tests, or implement fixes. Ask before expanding beyond the affected package.”

4. Request a compact repository map

Start with this prompt: “Read the README, package or build manifests, and relevant entry points. In no more than 250 words, explain this package's purpose, runtime, main modules, data flow, and test layout. Support each factual claim with a file path and symbol or line range. Mark anything unverified.”

Check existing GEMINI.md instructions as well. Gemini CLI discovers these context files hierarchically, so instructions can come from more than the repository root. Inspect the loaded guidance rather than assuming every convention came from the files named in your prompt. ([geminicli.com](https://geminicli.com/docs/cli/gemini-md/))

If the answer is too broad, narrow it: “Describe only the package containing these changed files. List other packages as dependencies without exploring their internals.”

5. Connect the summary to the pull request

Paste the changed-file list and specify the comparison base. Ask: “Inspect this branch's diff against origin/main using the merge-base comparison. Group changes by behavior, not filename. For each group, identify the entry point, affected callers, changed assumptions, and relevant tests. Separate observed changes from possible consequences.”

Request a short list with a consistent structure:

• Behavior changed: what callers or users may experience differently.
• Evidence: changed file, symbol, and supporting test.
• Review question: the assumption a human should verify.

For a large patch, handle one behavior group at a time. Avoid requesting another full-repository summary.

6. Verify the highest-risk claims yourself

Ask for three review priorities, each with supporting evidence and an uncertainty statement. Then open the cited files yourself. Trace one affected call path and inspect the relevant assertions. Distinguish “a test exists” from “the changed behavior is tested.”

Run approved tests separately, and record their actual results. Do not let the summary imply that tests passed when the session only inspected their source.

7. Save a reusable review brief

Copy the verified output into your private review notes: package purpose, changed behaviors, three priorities, and unresolved questions. Keep speculative findings out of public review comments until you reproduce or substantiate them.

For recurring AI-assisted review preparation, consider RelayVano, a pay-as-you-go relay that works with Gemini CLI and other developer tools. Sign up when you are ready to add it to your workflow, and follow its setup instructions rather than assuming an API-base change alone configures the CLI.