adk-bot-review

adk-bot（adk-bot-review）が提案した変更をレビューする

このスキルでは、adk-bot の変更を厳密にレビューします。Google の開発者向けドキュメントのスタイルに基づき、ドキュメントの更新が技術的に正確で、適切な規模であり、ADK ドキュメントの規約に従っていることを確認します。

Step 1: 提案された adk-bot の変更を確認し、調査する

• PR のタイトルが、課題だけでなく、更新対象のトピックを簡潔に説明していることを確認します。
• 変更が .md ファイルに直接加えられていることと、「do not merge」ステータスタグが時期尚早に削除されていないことを確認します。
• PR のマージ可能な状態と CI のステータスを確認します。Git の競合や失敗したチェックがあれば、修正すべき問題として、または統合 PR で修正する項目として記録します。
• 入力は adk-bot が作成した PR が 1 件、場合によっては数件です。PR から、元の課題と、その課題が扱う具体的な項目をたどって確認します。PR のタイトル（「Update ADK doc according to issue # - 」）と本文から項目を特定します。adk-bot は、同じ項目に対して複数の PR を作成することがあります。複数の PR が提示された場合は、それらがすべて同じ項目を扱っていることを確認し、1 つの統合対象としてまとめてレビューします。異なる項目を扱っている場合は、続行する前に、どの項目に焦点を当てるかユーザーに尋ねます。
• リポジトリ全体で、類似トピックを扱うクローズ済みの課題と、マージ済みまたは却下された PR を検索します。人間のメンテナーが過去に議論し、却下した変更、API、スタイル上の選択をボットが再導入していないことを確認します。
• 項目で意図されている変更と、その理由を要約し、次のステップで技術的な検証を行う際に、その意図を踏まえます。

Step 2: 更新基準とアーキテクチャを評価する

• 既存のドキュメントが全面的に不明瞭な場合を除き、包括的な見直しよりも、小規模で的を絞った更新を優先します。
• 更新によって有用な学習体験が得られ、開発者が実際に行動に移せる内容になっていることを確認します。
• 内容が ADK ドキュメントの情報アーキテクチャに適切に配置されていることを確認します。
• 更新の長さと優先順位が、対象となるコード変更に適していることを確認します（既存のドキュメントや API リファレンスですでに説明されていないか確認します）。

Step 3: 変更をソースと意図に照らして検証する

• AI エージェントのコードスニペットが正しいと決して思い込まないでください。
• すべてのコード例を、https://github.com/google/adk-python リポジトリと照合します。
• 関連するプルリクエストと、https://github.com/google/adk-python リポジトリにある実際の ADK コードに照らして情報を検証します。
• 変更によって、リンク先の課題と adk-bot の PR が意図したことが実際に実装され、参照されている課題の項目が解決されていることを確認します。
• 明示された意図から逸脱している変更や、変更で対応できていない意図があれば指摘します。

Step 4: 品質とスタイルを確認する

見出し

• 空の見出し（見出しの連続）を避け、h1、h2、h3 の階層を論理的に保ちます。
• 見出しに番号を付けないでください（## 1. This heading ではなく、## This heading を使います）。
• 命令形のタイトルを使います（例：「Build agents」。 「Building agents」ではありません）。
• 見出しにコマンド名を使わず、実行するタスクを示します。

言語

• 規約の基準として、Google の開発者向けドキュメントのスタイル（https://developers.google.com/style）に従います。ここに記載されていない事項については、同スタイルガイドを参照します。
• 能動態の表現を使います（例：「システムは X を実行します」。 「X が実行されます」ではありません）。
• 名詞を伴わずに「this」を使わないでください（例：「This function is used...」は可、「This is used...」は不可）。

コードスニペットと書式

• 長い URL、改行できないコードブロック、表を除き、一般的な Markdown テキストの行の長さを 80 文字以内にします。
• バッククォート（```）の前にスペースがあることで生じるレンダリングエラーがないか確認します。
• 注記や警告には、引用形式（>）ではなく、mkdocs-material の !!! warning/tip/note 警告表示形式を使います。
• コード構文を除き、すべて大文字の表記は使わず、強調には太字または斜体を使います。

ステップ 5：調査結果を報告し、推奨対応を決定する

まず、上記の検証手順で得られた調査結果を、ブロッカー、必須の修正、軽微な指摘の順にまとめます。次に、調査結果を根拠として、以下から対応方針を選択します。

• ボットの PR をクローズする。（場合による）変更が誤っている、古くなっている、非推奨または未リリースの API を対象としている、あるいは公開済みドキュメントまたはマージ済み PR で既に対応されている場合です。理由を記録し、置き換えとなるドキュメントまたは PR へのリンクを記載します。
• そのまま承認する（まれ）。ボットの PR が正しく、適切な場所にあり、編集が不要な場合です。
• その場で編集してから承認する（場合による）。既存のブランチは利用できますが、競合の解決、修正、内容の統合、文章の校正、または移動が必要な場合です。
• 統合用の新しい PR を作成する（最も一般的）。1～3 件のボット PR の変更を再構成し、コードの誤りや誤った内容を修正し、品質を高め、適切なファイルに配置する PR を 1 件作成します。その後、置き換えられたボットの PR をクローズします。

変更対象のファイルが適切であることも確認します（ファイルが移動または再構成されている場合や、別のページに変更を加えるべき場合があります）。

ステップ 6：実行計画を作成する

選択した対応方針に基づき、次に行う具体的な作業を出力します。

• 必要な具体的なローカル編集：ファイルパス、変更内容、コードの修正、1～3 件のボット PR の統合、適切な配置。
• 根拠となる検証結果の簡潔な一覧。ブロッカー（未検証／誤った内容のコード、誤ったファイル、失敗した CI チェック、表示の不具合）を最初にし、次に必須の修正、最後に軽微な指摘を記載します。
• クローズするボットの PR。
• リポジトリの慣例に沿った PR の説明：
  • 変更内容を箇条書きで簡潔にまとめる
  • Rendered page: <プレビューリンク>
  • Agent PR: <リンク>
  • Original issue: # - <項目>

適用するスタイルルール

• サンプルコードでは、特定のバージョン付きモデル文字列ではなく、gemini-flash-latest、gemini-pro-latest、またはその他の有効な *-latest エイリアスを使用してください。新しいモデルバージョンのリリース時に、メンテナンスの負担が増えるためです。
• インポート：from google.adk.agents import Agent。MCP には from google.adk.tools.mcp_tool import McpToolset を使用します。Python のエージェント変数は root_agent です。
• 長いダッシュや冗長な AI 生成コンテンツは使用しないでください。**用語**: 定義 の箇条書きではコロンを使用し、それ以外の説明文は文を分けてください。
• ADK を指す場合は「ADK」を使用し、「Google ADK」や「The ADK」は使用しないでください。
• インラインコードの語句で文を始めないでください。
• ADK ドキュメントへの内部リンクにはサイト相対パスを使用してください（例：`/sessions/memory/）。外部リンクは解決可能なものにしてください。リンクを創作しないでください。
• すべてのコードサンプルを、実際の API とライブラリのコードに照らして検証してください。正規のソースリポジトリは docs/community/contributing-guide.md に記載されています。