القائمة
Local code review with Gemini CLI for pre-commit reviews. Use when user says review code, code review, check my changes, or review before commit.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Execution trace capture and token baselining. Use when user says trace, extract trace, count tokens, token baseline, or /harness-trace. Not for harness optimization (use harness-mechanic).
Release prep and tagging with pre-flight verification. Use when user says release, tag, ship it, push to production, create release, or bump version. Not for editing a version string outside a release, a lockfile or a changelog entry by hand, and not for reading what changed in a past release: those are ordinary edits, just do them.
Mine LEARNING.md retrospectives across all repos for recurring failure-modes, then propose harness changes (hooks, rules, skills, checklist items) with falsifiable change-contracts. Also runs the doc-gardening pass over the governance docs (stale rules, dead cross-references, skill-table drift). Use when user says learning loop, mine learnings, recurring failures, what should I fix in my process, cross-repo retrospective, doc gardening, stale docs, or run learning-loop. Runs on human schedule, never autonomously. Not for single-project retrospectives (use learning-docs) or trace/token analysis (use harness-mechanic).
Full contractor-mode loop: sub-protocols (LOCALIZE, BENCH-BASELINE, REPRODUCE, DRIFT), review routing by file pattern, blast radius, UAT, parallelism and effort caps, escalation, just-do-it, goal-backed runs. Load it to RUN that loop, once you have an approved plan and are entering step 1, or when a step needs its detail. It is a protocol, not a way to do the work: it never replaces the language, review or planning skill the task itself calls for, and a task small enough to just edit (SKIP_SET) needs none of it. The always-on spine lives in rules/orchestrator-protocol.md. Not for trace capture (harness-trace) or harness optimization (harness-mechanic).
Ruby on Rails with service-oriented architecture, Dry-validation, Sidekiq/Solid Queue, Hotwire. Use for Rails API, Rails services, Rails forms, RSpec, ActiveRecord, Rails migrations. Not for standalone Ruby gems (use ruby skill), and not for judging whether a migration is safe to run in production (that is the database-reviewer agent).
Get three independent second opinions (isolated Claude + isolated Gemini + isolated DeepSeek) on a problem Claude is analyzing. Use when user says second opinion, another perspective, challenge this approach, or asks gemini/deepseek about a decision, approach, or diagnosis. Also invoke on your own initiative, without being asked: on a complex task before planning, after 2 failed root-cause attempts, on a 🔴 decision (rewrite, core logic, security), or when the review loop is stuck below 80 after 2 fix rounds. Gathers context, writes a focused prompt, calls all reviewers in isolated Docker containers, and synthesizes all viewpoints. Not for reviewing code or changes, even phrased as 'ask gemini to review' (use gemini-review).
| name | gemini-review |
| description | Local code review with Gemini CLI for pre-commit reviews. Use when user says review code, code review, check my changes, or review before commit. |
| allowed-tools | ["Read","Bash"] |
| compatibility | Requires Gemini CLI installed and GEMINI_API_KEY in environment. |
MANDATORY: Always use --model gemini-3.1-pro-preview. No other model. No fallback. No substitution.
Activate when user says: "gemini review", "review with gemini", "local review", or /gemini-review.
| Option | Description | Default |
|---|---|---|
--all | Review all uncommitted changes | staged only |
--branch [base] | Review current branch vs base | main |
--prompt <name> | Use specific prompt template | default |
--extension | Use Gemini's built-in /code-review | custom prompt |
# Default: staged changes
git diff --cached
# With --all: all uncommitted
git diff HEAD
# With --branch [base]: branch vs base (default base: main)
git diff main...HEAD
# Check if diff is empty
git diff --cached --quiet && echo "No staged changes" || echo "Has changes"
If no changes, inform user and suggest:
git add <files> to stage changes--all flag for uncommitted changes--branch flag for branch reviewPrompt templates are in ~/.claude/skills/gemini-review/prompts/:
default.md - Concise review focused on bugs/security/performanceci-style.md - Detailed review matching CI pipeline styleOption A - Using built-in extension (with --extension flag):
cd <project_root>
gemini --model gemini-3.1-pro-preview --yolo "/code-review"
Option B - Using custom prompt (default):
cd <project_root>
# Generate diff
DIFF=$(git diff --cached)
# Read prompt template
PROMPT=$(cat ~/.claude/skills/gemini-review/prompts/default.md)
# Invoke Gemini with prompt and diff
gemini --model gemini-3.1-pro-preview --yolo <<EOF
$PROMPT
## Code Changes to Review
\`\`\`diff
$DIFF
\`\`\`
EOF
Gemini's output will appear in the terminal. Summarize key findings for the user.
--branch with specific files| Issue | Solution |
|---|---|
| "No staged changes" | Run git add <files> or use --all |
| "gemini: command not found" | Install Gemini CLI: see https://github.com/google-gemini/gemini-cli |
| API errors | Check GEMINI_API_KEY is set |
| Timeout on large diffs | Split into smaller reviews or use --extension |