gemini-style-review

GitHub App/ボット クォータ制限を回避しながら、GitHub 上の Gemini Code Assist に近いローカルレビューワークフローを調整します。公開されている GitHub PR レビュー動作にできるだけ近づける必要がありますが、GitHub に投稿することはなく、明示的な承認後にのみローカルでこのスキルが提案を適用します。

ランタイム互換性

• ターゲットランタイム: Markdown スキルと サブエージェント を備えた Claude Code 互換プラグイン/スキルランタイム。
• opus、sonnet、inherit などのモデルエイリアスのサブエージェント frontmatter サポート、および Read、Grep、Glob、Bash などの Claude Code ツール名が必要です。
• Agent、AskUserQuestion、およびローカルファイル Edit 適用用のオーケストレーションツールが必要です。
• ローカル git ワークツリーと、PR メタデータ、構成、差分取得用の認証済み GitHub CLI (gh) が必要です。
• Codex、Gemini CLI、GitHub Actions、またはその他のランタイムでは、使用前にモデルエイリアス、ツール名、承認 UI、および編集プリミティブを適応させてください。
• gemini-style は、Google または Gemini Code Assist との関連ではなく、非公式なレビュースタイルターゲットを説明しています。

1. 定数

名前	値
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 (無制限)
GEMINI_CONFIG_PATH	.gemini/config.yaml
GEMINI_STYLEGUIDE_PATH	.gemini/styleguide.md
HARD_EXCLUDE	.github/workflows/**
ARTIFACT_LANGUAGE_PRIORITY	PR body、PR title、人間による PR コメント、明示的な --lang、リポジトリのデフォルト
REVIEWER_AGENT	agents/gemini-style-reviewer.md

2. 実行フェーズ

フェーズ 1: 入力受け取り

• オプショナルな PR 番号とローカルフラグを解析します。PR 番号が省略されている場合、gh pr view を使用して現在のローカルブランチに関連付けられたプルリクエストを選択します。それ以外の場合は指定された PR 番号を使用してください。デフォルトの動作は /gemini review に対応する必要があります。--deep および --apply はローカル専用の拡張です。
• --deep を拡張されたコンテキスト取得モードとして扱います: 参照検索の範囲を広げ、より多くの比較可能なローカルパターンを検査し、変更されたコントラクトが明確になるように、変更されたファイルの近傍を超えた隣接するドキュメント/テスト/モックを含めます。
• 明示的な --lang <language> をフォールバックとしてのみ保存します。ユーザー向けレビュー成果物は、推測できる場合は常にレビュー対象 PR のボディー言語を使用する必要があります。
• 現在のリポジトリコンテキストを特定します。

フェーズ 2: PR 状態の取得

• gh pr view {pr_number} --json number,title,body,baseRefName,baseRefOid,headRefName,headRefOid,isDraft,author,changedFiles,files,additions,deletions,url,comments,reviews,latestReviews で PR メタデータを取得します。
• gh pr diff {pr_number} --patch --color never で完全なパッチを取得します。
• PR head/base オブジェクトを可能な限りワークツリーを変更することなくローカル git オブジェクトデータベースに取得してから、PR head SHA からファイルコンテキストを読み込みます。PR head コンテンツであるかのようにローカルワークツリーの古いファイルを分析しないようにしてください。
• レビュー生成用に HEAD がローカルで PR head と一致することを必須としないでください。また、クリーンなワークツリーを必須としないでください。これらのチェックは、オプショナルなローカル編集の前にのみ適用されます。

フェーズ 3: Gemini 構成の読み込み

• .gemini/config.yaml が存在する場合はそれを読み込みます。そうでない場合は Gemini Code Assist スタイルのデフォルトを使用します:
  • code_review.disable: false
  • code_review.comment_severity_threshold: MEDIUM
  • code_review.max_review_comments: -1
  • ignore_patterns: []
• code_review.disable: true の場合、ユーザーが明示的にオーバーライドをリクエストしない限り停止し、リポジトリ構成がレビューを無効にしていることを報告してください。
• ignore_patterns をコンテキスト読み込みまたはコメント生成の前に変更されたファイルに適用します。
• Gemini Code Assist の公開されている GitHub 動作と一致させるために、常に .github/workflows/** を概要、レビューコメント、およびコード提案から除外します。
• .gemini/styleguide.md が存在する場合はそれを読み込み、プライマリなリポジトリ固有のレビューガイドとして扱ってください。エンタープライズ/グループのスタイルガイドは、ユーザーが提供しない限りローカルでは利用できません。

フェーズ 4: PR 理解の構築

• PR タイトル、ボディ、変更されたファイルリスト、差分統計、および利用可能な関連 PR 会話コンテキストを読み込みます。
• ユーザー向けの出力に関して artifact_language を解決します:
  • 最初に PR body から推測します
  • PR body が空、ボイラープレートのみ、または言語が推測できない場合は、PR title と人間による PR コメントにフォールバックします
  • PR 作成者テキストが確実な言語を提供しない場合は、明示的な --lang <language> のみを使用します
  • リポジトリのデフォルトは最後のフォールバックとしてのみ使用します
  • コード、識別子、製品名、重大度ラベル、ファイルパス、および GitHub 構文はそれぞれの元の形式で保持します
• レビューを開始する前に簡潔な変更マップを構築します:
  • 意図されたユーザー側またはシステム側の可視動作
  • タッチされたエントリポイント、公開 API、データモデル、マイグレーション、構成、権限、非同期フロー、およびテスト
  • 変更された不変量、デフォルト、エラーパス、および依存関係の境界
  • .gemini/config.yaml または .github/workflows/** によって意図的に除外されたファイル
• PR の形態を分類します。たとえば、バグ修正、機能、リファクタリング、依存関係の更新、マイグレーション、UI の変更、テストのみの変更、または構成の変更など。

フェーズ 5: コンテキスト取得

• PR head コンテンツから変更されたハンクの周囲の 50 行以上 を読み込んで、論理的なコンテキストを提供します。
• 変更されたエクスポートされたシンボル、ルート、スキーマフィールド、コマンド、構成キー、マイグレーション、または非プライベート関数ごとに、rg で直接参照を検索します。
• 変更された動作に依存する隣接するテスト、モック、例、ドキュメント、シリアライザー/デシリアライザー、バリデーター、認可チェック、フィーチャーフラグ、テレメトリ、およびエラーハンドリングパスを検索します。
• 修正を推奨する前に、リポジトリ内の同様の既存パターンを比較します。
• AGENTS.md、CLAUDE.md、GEMINI.md、.github/copilot-instructions.md、および docs/**/*.md などのルートレベルエージェント命令ファイルは、セカンダリなローカルコンテキストとして使用できますが、ユーザーが明示的にリクエストしない限り、Gemini Code Assist スタイルガイドとして扱わないでください。レビュースタイルの強制には .gemini/styleguide.md を優先します。

フェーズ 6: 分析とフィルタリング

• pr_metadata、change_map、diff_text、file_contexts、参照検索結果、gemini_config、styleguide_text、関連するセカンダリコンテキスト、および artifact_language を使用して Agent(gemini-style-reviewer) をスポーンします。
• Gemini Code Assist の公開レビューカテゴリ(正確性、効率性、保守性、セキュリティ、およびテスト、スケーラビリティ、モジュール化、再利用性、エラーログ、監視などのその他のトピック)を使用して、PR の変更部分を分析します。
• すべての候補検出が品質ゲートを通過することを要求します:
  • 変更された行にアンカーされている
  • 差分とリポジトリコンテキストからの証拠
  • 具体的な障害モードまたは保守リスク
  • 一般的なベストプラクティス単独への依存なし
  • 安全なリテラル置換提案
  • code_review.comment_severity_threshold 以上の重大度。構成値を大文字小文字を区別せずに正規化し、可視ラベルを Low、Medium、High、または Critical としてレンダリングします
• 実際のレビュー価値によってランク付けします。量より多くの信頼度の低い多数のコメントより、信頼度の高い 1 つの問題を優先します。
• ランク付けした後、code_review.max_review_comments を適用します。

フェーズ 7: Gemini スタイルの成果物をレンダリング

• 以下を含む Conversation タブの概要コメントをレンダリングします:
  • Summary of Changes
  • PR 作成者への短い挨拶
  • 1 段落の PR 意図概要
  • Highlights
  • 変更されたパスでグループ化された Changelog
• 短い Code Review ボディをレンダリングします。
• インラインコメントを Inline Comments の下に別個にレンダリングします。各インラインコメントには以下を含める必要があります:
  • ターミナル出力用のローカルパスと行の範囲
  • Critical、High、Medium、Low を使用した重大度ラベル
  • correctness、efficiency、maintainability、security、miscellaneous を使用したカテゴリラベル
  • 簡潔なフィードバック
  • GitHub から直接コミットできるリテラル GitHub suggestion ブロック
  • コメントが .gemini/styleguide.md に依存している場合のみ、スタイルガイド参照
• インラインコメントの範囲は PR diff の変更部分内である必要があります。
• 構成されたしきい値以上のインラインコメントがない場合でも、No review comments. で概要と Code Review セクションをレンダリングします。
• GitHub にコメントを投稿しないでください。

フェーズ 8: オプショナルなローカル適用

• このフェーズは、ユーザーが明示的にローカル適用をリクエストした場合にのみ入ります。たとえば --apply を使用するか、レビュー後に提案を承認します。
• Edit 前に、ワークツリーが承認中に変更されている可能性があるため、フェーズ 2 の安全性チェックを再実行します: ローカル HEAD がフェッチされた PR HEAD と一致していることを確認し、PR タッチされたファイルがまだクリーンであることを確認します。いずれかのチェックが失敗した場合は編集なしで中止してください。
• 各承認された提案について、候補パスが PR diff に含まれていることを確認し、その [start_line, end_line] 範囲が追加/変更ハンク内に完全に含まれていることを確認します。これらのガードに失敗する候補をスキップして報告します。
• ローカルインラインコメント範囲と suggestion ブロックを解析し、安全性、パス、およびハンクガードが通過した後にのみ Edit を使用して、承認された提案を適用します。
• ファイルごとに 下から上へ(降順 start_line) でエディットをソートして、行番号の整合性を維持します。
• 最終レポート: サマリーを出力し、ユーザーに git diff で検証するよう促します。

3. 運用上のガード

• リモート変更なし: gh 経由で GitHub にコメントを投稿することは禁止されています。
• Gemini 構成の忠実さ: ローカル設定よりも前に .gemini/config.yaml、.gemini/styleguide.md、重大度しきい値、最大コメント数、および無視パターンを尊重してください。
• 変更行アンカリング: すべてのレビューコメントは、追加または変更されたハンク行を対象にする必要があります。
• ワークフロー除外: .github/workflows/** に関する概要、コメント、または提案を生成しないでください。
• 品質優先: Gemini Code Assist の品質の一致は、表面フォーマットのコピーより重要です。実際の PR リスクを見つけるために必要なコンテキスト作業を行ってください。
• 成果物の忠実さ: 内部テーブルまたは診断レポートより、レンダリングされた GitHub スタイルのレビュー成果物を優先してください。
• アトミックな編集: 提案は、特定の行範囲のリテラル置換である必要があります。
• ローカル拡張の境界: ローカルファイル編集は Gemini Code Assist の GitHub App 動作の一部ではありません。オプトインとガード付けで保持してください。

4. 参考資料

• カテゴリの境界が不明な場合は references/review-categories.md を読んでください。
• インラインコメントの文言または提案ブロックを作成する場合は references/comment-template.md を読んでください。