Second Opinion

Second Opinion

Run an independent code review without changing the repo.

When to use it

• non-trivial code changes
• risky refactors
• security, performance, or concurrency-sensitive edits
• schema or API changes
• before opening or merging a PR
• when the user explicitly wants another model's view

When to skip it

• docs-only or formatting-only changes, unless the user still wants it
• repos or diffs that must not be sent to external services
• empty diffs

If repository guidance or user instructions forbid sending code to third-party tools, stop and ask before proceeding.

Infer the request first

Infer as much as possible from the user's message:

• tool: codex, gemini, or both
• scope: uncommitted, branch diff, commit, or PR
• focus: general, security, performance, error handling, architecture, or a custom concern

Ask one concise follow-up only if a missing detail blocks the run.

Read only what you need

• Read references/workflow.md for scope detection, diff sizing, review-brief construction, and synthesis rules.
• Read references/codex.md only if running Codex.
• Read references/gemini.md only if running Gemini.

Core workflow

1. Detect the scope and compute diff stats. 2. Stop on empty diffs. 3. Warn on large diffs and suggest narrowing scope before spending tokens. 4. Build a short review brief that tells the reviewer:

• what changed
• what to focus on
• how to inspect the diff locally
• that the review is read-only
• what output format to return

5. Run the selected tool or tools in parallel if independent. 6. Present findings first, then agreement and disagreement across tools. 7. Never auto-apply suggested fixes unless the user explicitly asks.

Safety defaults

• Keep the review read-only.
• Do not commit, push, stage, or edit files as part of the second opinion run.
• Prefer tool-native review commands over manual diff pasting when the tool can inspect the repo directly.
• Prefer prompt files or stdin over fragile one-line shell quoting for long review briefs.
• Use explicit timeouts and capture output cleanly when automating external review CLIs.
• Clean up temporary prompt and output files after reading them.

Review result format

Present results in this order:

1. Findings by tool, highest severity first. 2. Explicit No findings if a tool returns nothing substantive. 3. A short synthesis:

• where the tools agree
• where they disagree
• what looks worth acting on first

Keep the synthesis separate from the raw reviewer output so the user can distinguish the outside opinion from your judgment.

Codex CLI

Current local verification snapshot:

• CLI: codex-cli 0.114.0
• Built-in non-interactive review commands exist:
• codex review
• codex exec review

Relevant official sources:

• Codex CLI docs
• Codex non-interactive mode docs
• Codex prompting guide
• AGENTS.md guidance

Preferred path

For headless second-opinion reviews, split the Codex path in two:

• generic scoped review: prefer codex exec review
• focused or highly customized review: prefer plain codex exec

Why:

• current CLI has first-class review scope flags
• avoids manual diff assembly for common cases
• keeps the review flow closer to the tool's native behavior

Scope mapping

# uncommitted changes, including untracked files
codex exec review --uncommitted

# branch diff
codex exec review --base <branch>

# specific commit
codex exec review --commit <sha>

Safe defaults

For generic scoped review, use:

codex exec review \
  -c sandbox_mode='"read-only"' \
  -c approval_policy='"never"' \
  --ephemeral \
  -o "$output_file" \
  --uncommitted

Notes:

• prefer --ephemeral
• explicitly force read-only with -c sandbox_mode='"read-only"'
• do not use --dangerously-bypass-approvals-and-sandbox
• use -c approval_policy='"never"' for non-interactive review runs
• do not use manual diff pasting unless the built-in review command cannot support the requested workflow
• let Codex read AGENTS.md automatically; do not paste its contents into the prompt

Current local behavior on codex-cli 0.114.0:

• codex exec review with scope flags works
• codex exec review --uncommitted [PROMPT] is rejected even though help still shows [PROMPT]

Because of that, do not rely on exec review for a custom focus prompt when also using --uncommitted, --base, or --commit.

Model selection

Best practice:

• prefer the local CLI default model unless the user explicitly asks for a specific one
• if you must pin a current Codex-tuned model, gpt-5.3-codex is the current tested pin from OpenAI's prompting guide

Focused review path

When the user wants a custom focus such as performance, security, architecture, or special output constraints, use plain codex exec with a review brief.

Example:

codex exec \
  -c sandbox_mode='"read-only"' \
  -c approval_policy='"never"' \
  --ephemeral \
  -o "$output_file" \
  - < "$prompt_file"

The prompt file should tell Codex exactly which git command to run for the requested scope.

Prompting style

Codex already knows it is reviewing code. Keep custom instructions short:

• focus area
• scope clarification if needed
• output format
• explicit read-only constraint

Example custom prompt body:

Review for correctness, performance regressions, security issues, maintainability risks, and missing tests.
Keep the review read-only. Do not modify files, commit, push, or stage changes.
Read AGENTS.md if present. If not, read CLAUDE.md if present.
Findings first. If no substantive issues are found, say so explicitly.

Fallback

Only fall back to plain codex exec when:

• the installed CLI lacks review
• you need a custom workflow the review subcommand cannot express

If you fall back, still keep the task read-only and prefer giving Codex the git command to inspect, not a giant pasted diff.

Gemini CLI

Current local verification snapshot:

• CLI: gemini 0.33.0
• Installed review-related extensions:
• code-review
• gemini-cli-security
• CLI supports:
• --approval-mode
• --extensions
• --output-format

Relevant official and current sources:

• local Gemini CLI help
• local code-review extension metadata and commands
• Gemini prompting guidance
• Gemini model docs

Safety default

For second-opinion reviews, prefer:

--approval-mode plan

Do not default to --yolo. A second opinion should be read-only.

Model selection

Best practice:

• prefer the local CLI default model unless the user asked to pin one
• if you need a current tested pin, use gemini-3.1-pro-preview
• do not use gemini-3-pro-preview; Google's model docs mark it deprecated and shut down as of 2026-03-09

Extension usage

Current branch review

The installed code-review extension provides /code-review and is the preferred path when the user wants review of the current branch change set.

Use:

gemini \
  --approval-mode plan \
  -e code-review \
  -p "/code-review"

Important:

• the extension reviews current branch changes, not an arbitrary commit or uncommitted-only scope
• keep it for branch-level review

Pull request review

Use /pr-code-review only when:

• the user asked for a PR review
• GitHub PR context is available
• the needed GitHub MCP setup exists

Custom scope review

For uncommitted changes, branch diffs against a chosen base, or specific commits, use a short review brief and tell Gemini the exact git command to run.

Prefer prompt files or stdin for the brief:

gemini \
  --approval-mode plan \
  -e code-review \
  -p "$(<"$prompt_file")"

The prompt file should:

• state the focus area
• define the scope
• tell Gemini which git command to run
• instruct it to read AGENTS.md or CLAUDE.md if present
• require findings-first output
• restate the read-only rule

Security focus

For a light second-opinion security review, use a security-focused brief.

Do not default to the heavy /security:analyze workflow from the security extension inside this skill. That command is its own deeper audit flow and creates artifacts. Use the dedicated security skill if the user wants a full security analysis rather than a lightweight second opinion.

Output handling

Prefer text output for human review summaries unless you are explicitly building machine parsing around Gemini:

• --output-format text for normal use
• --output-format json only if you are actually parsing it

For automation:

• use an explicit timeout around the Gemini process
• capture stdout and stderr separately or with a bounded wrapper
• treat silent hangs or auth prompts as operational failures and report them clearly

Review Workflow

Source snapshot: refreshed 2026-03-12 from official and current tool sources

• OpenAI Codex CLI docs and changelog
• OpenAI Codex prompting and non-interactive guidance
• OpenAI AGENTS.md guidance
• Gemini CLI local help and installed extension metadata
• Gemini prompting guidance

Scope detection

Default branch

Use:

git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'

Fallback to main, then master, only if detection fails.

Uncommitted scope

Show both tracked changes and untracked files:

git diff --stat HEAD
git diff --name-only HEAD
git ls-files --others --exclude-standard

Branch diff scope

git diff --stat <base>...HEAD
git diff --name-only <base>...HEAD

Specific commit scope

git diff --stat <sha>~1..<sha>
git diff --name-only <sha>~1..<sha>

GitHub PR scope

Use PR-aware tooling only when the user actually asked for a PR review and the local environment has the needed GitHub context.

Empty and large diff handling

Stop if the diff is empty.

Warn before running an expensive second opinion when the diff is large. Good default warning thresholds:

• more than 40 changed files
• more than 2000 changed lines

When warning, recommend narrowing to:

• a specific file set
• a single commit
• a branch diff against the real base
• one focus area at a time

Review brief

Do not paste the full diff if the external reviewer can inspect the repo locally. Give a short brief plus the exact git command to run.

Use this structure:

Review this code change set in read-only mode.

Focus:
- [general | security | performance | error handling | architecture | custom]

Scope:
- [uncommitted | branch diff vs <base> | commit <sha> | PR <id>]

What changed:
- [1-3 sentence summary]

Review constraints:
- Do not modify files.
- Do not commit, push, or stage changes.
- Prioritize correctness, security, performance, maintainability, and test gaps.
- Skip style-only comments unless they block understanding.

Repository guidance:
- Read AGENTS.md if present.
- If AGENTS.md is absent but CLAUDE.md exists, read CLAUDE.md.

Diff access:
- Run: [exact git diff command]
- For untracked files, also inspect: [file paths or `git ls-files --others --exclude-standard`]

Output format:
- Findings first, grouped by severity.
- For each finding: title, file:line if available, why it matters, and a concrete fix direction.
- If no substantive issues are found, say so explicitly.

Best-practice prompts

• Keep the brief short and operational.
• Tell the reviewer how to inspect the diff instead of flooding it with raw patch text.
• Separate focus, scope, constraints, and output contract with labels.
• Use one reviewer per concern when the user wants multiple perspectives.

Synthesis rules

After collecting outputs:

• findings first
• agreement summary second
• disagreements third
• your recommended next actions last

Do not collapse disagreements into false consensus.