gemini-style-review

name	gemini-style-review
description	Reviews GitHub Pull Request changes locally with behavior aligned to Gemini Code Assist on GitHub. Reads PR metadata, diffs, `.gemini/config.yaml`, `.gemini/styleguide.md`, and relevant repository context to infer PR intent, inspect affected contracts, and produce high-quality severity-filtered review findings with commit-ready suggestions. Keeps the workflow local to avoid GitHub App/bot quota limits; applying approved suggestions to local files is an optional local extension. Triggers: /gemini review, /gemini-style-review, gemini-style review, gemini-code-assist style review, high-signal PR review.
user-invocable	true
argument-hint	[PR number] [--lang <language>] [--deep] [--apply]

gemini-style-review

Orchestrates a local review workflow that approximates Gemini Code Assist on GitHub while avoiding GitHub App/bot quota limits. It should match the public GitHub PR review behavior as closely as possible, except that it never posts to GitHub and only applies suggestions locally after explicit approval.

Runtime Compatibility

• Target runtime: Claude Code-compatible plugin/skill runtime with Markdown skills and subagents.
• Requires subagent frontmatter support for model aliases such as opus, sonnet, or inherit, and Claude Code tool names such as Read, Grep, Glob, and Bash.
• Requires orchestration tools for Agent, AskUserQuestion, and local-file Edit application.
• Requires a local git worktree and an authenticated GitHub CLI (gh) for PR metadata, configuration, and diff retrieval.
• For Codex, Gemini CLI, GitHub Actions, or other runtimes, adapt model aliases, tool names, approval UI, and edit primitives before use.
• gemini-style describes an unofficial review-style target, not affiliation with Google or Gemini Code Assist.

1. Constants

Name	Value
REVIEW_CATEGORY_ENUM	correctness, efficiency, maintainability, security, miscellaneous
CONFIG_SEVERITY_ENUM	LOW, MEDIUM, HIGH, CRITICAL
RENDERED_SEVERITY_LABELS	Low, Medium, High, Critical
DEFAULT_COMMENT_SEVERITY_THRESHOLD	MEDIUM
DEFAULT_MAX_REVIEW_COMMENTS	-1 (unlimited)
GEMINI_CONFIG_PATH	.gemini/config.yaml
GEMINI_STYLEGUIDE_PATH	.gemini/styleguide.md
HARD_EXCLUDE	.github/workflows/**
ARTIFACT_LANGUAGE_PRIORITY	PR body, PR title, human PR comments, explicit --lang, repository default
REVIEWER_AGENT	agents/gemini-style-reviewer.md

2. Execution Phases

Phase 1: Intake

• Parse optional PR number and local flags. If the PR number is omitted, select the pull request associated with the current local branch using gh pr view; otherwise use the provided PR number. Default behavior should correspond to /gemini review; --deep and --apply are local-only extensions.
• Treat --deep as an expanded context-retrieval mode: broaden reference searches, inspect more comparable local patterns, and include adjacent docs/tests/mocks beyond the immediate changed-file neighborhood when they clarify the changed contract.
• Store explicit --lang <language> only as a fallback. User-facing review artifacts should use the reviewed PR's body language whenever it can be inferred.
• Identify current repository context.

Phase 2: Fetch PR State

• Fetch PR metadata with gh pr view {pr_number} --json number,title,body,baseRefName,baseRefOid,headRefName,headRefOid,isDraft,author,changedFiles,files,additions,deletions,url,comments,reviews,latestReviews.
• Fetch the full patch with gh pr diff {pr_number} --patch --color never.
• Fetch PR head/base objects into the local git object database without changing the worktree when possible, then read file context from the PR head SHA. Do not analyze stale local working-tree files as if they were PR head content.
• Do not require local HEAD to match PR head and do not require a clean worktree for read-only review generation. Those checks apply only before optional local edits.

Phase 3: Load Gemini Configuration

• Read .gemini/config.yaml if present; otherwise use Gemini Code Assist-style defaults:
  • code_review.disable: false
  • code_review.comment_severity_threshold: MEDIUM
  • code_review.max_review_comments: -1
  • ignore_patterns: []
• If code_review.disable: true, stop and report that repository configuration disables review unless the user explicitly requests an override.
• Apply ignore_patterns to changed files before context loading or comment generation.
• Always exclude .github/workflows/** from summaries, review comments, and code suggestions to match Gemini Code Assist's documented GitHub behavior.
• Read .gemini/styleguide.md if present and treat it as the primary repository-specific review guide. Enterprise/group style guides are not available locally unless the user provides them.

Phase 4: Build PR Understanding

• Load PR title, body, changed-file list, diff stats, and relevant PR conversation context when available.
• Resolve artifact_language for user-facing output:
  • infer from the PR body first
  • if the PR body is empty, boilerplate-only, or language cannot be inferred, fall back to PR title and human PR comments
  • use explicit --lang <language> only when PR-authored text does not provide a reliable language
  • use the repository default only as the final fallback
  • keep code, identifiers, product names, severity labels, file paths, and GitHub syntax in their original form
• Build a concise change map before reviewing individual hunks:
  • intended user-visible or system-visible behavior
  • touched entrypoints, public APIs, data models, migrations, config, permissions, async flows, and tests
  • changed invariants, defaults, error paths, and dependency boundaries
  • files intentionally excluded by .gemini/config.yaml or .github/workflows/**
• Classify the PR shape, for example bug fix, feature, refactor, dependency update, migration, UI change, test-only change, or configuration change.

Phase 5: Context Retrieval

• Read 50+ lines around each changed hunk from PR head content to provide logical context.
• For every changed exported symbol, route, schema field, command, config key, migration, or non-private function, search direct references with rg.
• Search for adjacent tests, mocks, examples, docs, serializers/deserializers, validators, authorization checks, feature flags, telemetry, and error handling paths that depend on the changed behavior.
• Compare similar existing patterns in the repository before recommending a fix.
• Root-level agent instruction files such as AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md, and docs/**/*.md may be used as secondary local context, but do not treat them as Gemini Code Assist style guides unless the user explicitly asks. Prefer .gemini/styleguide.md for review-style enforcement.

Phase 6: Analyze and Filter

• Spawn Agent(gemini-style-reviewer) with pr_metadata, change_map, diff_text, file_contexts, reference search results, gemini_config, styleguide_text, relevant secondary context, and artifact_language.
• Analyze modified portions of the PR using Gemini Code Assist's public review categories: correctness, efficiency, maintainability, security, and miscellaneous topics such as testing, scalability, modularity, reusability, error logging, and monitoring.
• Require every candidate finding to pass a quality gate:
  • anchored to a modified line
  • evidence from the diff plus repository context
  • concrete failure mode or maintenance risk
  • no reliance on generic best practices alone
  • safe literal replacement suggestion
  • severity at or above code_review.comment_severity_threshold; normalize configured values case-insensitively and render visible labels as Low, Medium, High, or Critical
• Rank by real review value, not by quantity. Prefer one high-confidence issue over many plausible but weak comments.
• Apply code_review.max_review_comments after ranking.

Phase 7: Render Gemini-style Artifacts

• Render a Conversation-tab summary comment with:
  • Summary of Changes
  • a short greeting to the PR author
  • a one-paragraph PR intent summary
  • Highlights
  • Changelog grouped by changed path
• Render a short Code Review body.
• Render inline comments separately under Inline Comments. Each inline comment must include:
  • local path and line envelope for the terminal output
  • severity label using Critical, High, Medium, or Low
  • category label using correctness, efficiency, maintainability, security, or miscellaneous
  • concise feedback
  • a literal GitHub suggestion block that can be committed directly from GitHub
  • a style guide reference only when the comment relies on .gemini/styleguide.md
• Inline comment ranges must be inside modified portions of the PR diff.
• If there are no inline comments at or above the configured threshold, still render the summary and Code Review section with No review comments.
• Do not post comments to GitHub.

Phase 8: Optional Local Apply

• Only enter this phase when the user has explicitly requested local application, for example with --apply or by approving suggestions after review.
• Before any Edit, re-run the Phase 2 safety check because the worktree may have changed during approval: verify local HEAD still matches the fetched PR HEAD, and verify PR-touched files are still clean. Abort without edits if either check fails.
• For each approved suggestion, verify the candidate path is included in the PR diff and its [start_line, end_line] range is fully inside an added/modified hunk. Skip and report any candidate that fails these guards.
• Apply approved suggestions by parsing the local inline-comment envelope and suggestion block, using Edit only after the safety, path, and hunk guards pass.
• Sort edits bottom-up (descending start_line) per file to maintain line number integrity.
• Final report: Print a summary and prompt the user to verify with git diff.

3. Operational Guards

• No Remote Mutation: Forbidden to post comments to GitHub via gh.
• Gemini Configuration Fidelity: Respect .gemini/config.yaml, .gemini/styleguide.md, severity thresholds, max comments, and ignore patterns before local preferences.
• Changed-Line Anchoring: Every review comment must target an added or modified hunk line.
• Workflow Exclusion: Never generate summaries, comments, or suggestions for .github/workflows/**.
• Quality Over Format: Matching Gemini Code Assist quality matters more than copying surface formatting. Do the context work needed to find real PR risks.
• Artifact Fidelity: Prefer rendered GitHub-style review artifacts over internal tables or diagnostic reports.
• Atomic Edits: Suggestions must be literal replacements for specific line ranges.
• Local Extension Boundary: Local file edits are not part of Gemini Code Assist's GitHub App behavior; keep them opt-in and guarded.

4. References

• Read references/review-categories.md when category boundaries are unclear.
• Read references/comment-template.md when shaping inline comment wording or suggestion blocks.