qodo-review-resolver

指摘事項の読み取りと解決

説明

Qodo の管理ツールを使って、任意の PR（自分の PR でも他の人の PR でも）のプルリクエストのレビューセッションを読み取ります。レビューのステータス、レビュー対象のコミット、各指摘事項の解決状況を確認できます。引用を監査する場合や、指摘事項の根拠、場所、却下、レビュー実行履歴を調べる場合は、拡張結果をリクエストしてください。読み取りだけでも有効な使い方です。レビューの状況や指摘内容を報告するために読み取った後、そのまま終了してかまいません（たとえば、最新のコミットに未解決の問題がないことを条件にマージを許可する場合など）。さらに進める場合は、未解決の指摘事項をコード上で解決し、自分の判断で適用してください（レビューは有力なセカンドオピニオンですが、絶対的なものではありません）。ユーザーが許可している場合は、対応可能な修正を適用してください。それ以外の場合は、ユーザーが選択できるよう評価結果を提示してください。一度だけ実行して（報告と許可済みの修正）、または監視ループとして実行できます（解決 → 新しいコミットを Qodo に再レビューさせる → すべて解決するまで繰り返す）。別途許可を得た場合は、解決した指摘事項に結果を記録してください。修正した指摘には mark-implemented を、コードを変更せずに終了することにユーザーが同意した指摘には dismiss を使います。これにより、該当の指摘事項が課しているマージポリシー上のブロックが解除されます。これを省略すると、人が PR 上で操作するまでレビューは赤いままです。ただし、あなた自身がフォージに投稿することはありません。ステータスツールは Qodo のレビューデータベースに書き込み、Qodo が PR のコメントを整合させます。（git rev-parse HEAD や gh pr view --json headRefOid など、Git／フォージのメタデータを読み取ることは問題ありません。以下の最新状態チェックでも必須です。「スクレイピング禁止」のルールは Qodo に関するものであり、シェルに関するものではありません。）

前提条件

• 接続済みの QAR 管理ツール MCP サーバー、または認証済みの Qodo CLI から、レビューセッションツールを利用できます。
• 正確な PR URL と現在の head SHA を、レビューコメントをスクレイピングせずに特定できます。
• 指摘事項のステータスを書き込む場合は、ユーザーから明示的な許可を得ている必要があります。コード修正の許可や autofix だけでは、ステータスの書き込みは許可されません。

手順

実行方法を選択する

必要なレビューセッション機能を利用できる場合は、接続済みの QAR 管理ツール MCP ツールを使います。利用できない場合は、以下の CLI 方法を使ってください。MCP では、ホストから提供される説明、inputSchema、読み取り専用／変更を伴う操作の注釈を確認してください。ワイヤーツールは get-pr-review-findings（pr_url、任意の extended）、pr-review-dismiss、pr-review-mark-implemented です。呼び出す前に、現在のスキーマを確認してください。成功したトランスポート応答の場合も含め、structuredContent を参照する前に isError を確認してください。途中で切り詰められた指摘結果は不完全であり、レビューに問題がないことを意味しません。

MCP で書き込みを行うには、現在のスキーマの idempotency_key 引数に、指摘事項の処理内容を識別する安定したキーが必要です。リクエストメタデータに対応しているホストでは、代わりに _meta["io.qodo/idempotency-key"] を送信できます。両方を送信する場合は、値を一致させてください。結果が不確かな場合に再試行するときは、同じキーと同一の引数を使ってください。 以下の許可、最新状態、指摘事項のステータス、却下、読み戻しに関するルールは、どちらの方法にも適用されます。MCP 呼び出しを拒否された後、別の CLI アカウントやテナントに切り替えないでください。CLI のバージョン、ID、ヘルプ、カタログ更新に関する手順は、CLI を使う場合にのみ適用されます。

以下の詳細なワークフローに従ってください。構造化された状態を取得し、レビューが完了していて対象コミットと正確に一致することを確認し、未解決の指摘事項を提示し、承認された修正のみを適用して、実際に解決した結果のみを記録します。

レビューのステータスや指摘事項を確認するには、MCP の get-pr-review-findings、または CLI の qodo read pr-review-session findings を呼び出してください。gh／curl で表示された PR レビューのコメントを取得しないでください。UI の情報は欠落があり、プロバイダー固有で、head コミットに対して古い情報を読み取りやすいためです。構造化された読み取り結果には、レビュー対象の commit_sha が含まれます。最新状態かどうかを判断するには、この commit_sha と PR のhead を比較します。直前に自分がプッシュした PR なら git rev-parse HEAD で直接確認できます。それ以外の PR なら、フォージの通常のメタデータ（gh pr view <pr> --json headRefOid、git ls-remote）として読み取ってください。このルールはレビューの読み取りだけに適用されます（コメントをスクレイピングしないでください）。head SHA などのフォージのメタデータを読むことは禁止されていません。

スキル更新通知への対応

QODO_NOTICE の更新は、古い CLI が対応を求めている場合でも、受動的に扱ってください。在庫確認や更新について質問せずにタスクを続行し、各イベントへの言及はそれぞれ1回までにしてください。通知を閉じても、記録済みのメンテナンスポリシーとオプトアウトは変更されません。更新されたスキルは次のセッションで読み込まれます。このセッションを中断しないでください。 ユーザーが依頼した更新については、手動更新手順に従ってください。

実行

• MCP：ライブスキーマの引数を使用し、CLI のシェル手順は省略してください。
• CLI：BOM なしの完全な UTF-8 ファイルを使用してください（ツールには --args-file、レビューには --context-file を使用します）。例は POSIX 向けです。
• Windows CLI：最初の呼び出しの前にシェルのガイダンスを読み、呼び出しに失敗した場合に限りランチャーの復旧方法を参照してください。解決済みの呼び出し方法を再利用してください。

ランタイム互換性ゲート

まず、以下の qodo: command not found のフォールバックを使って実行ファイルを解決してください。他の Qodo コマンドを実行する前に、プロベナンスフラグを付けず、記載どおりに <qodo> --version を実行してください。 このフラグなしの確認は、古い Qodo CLI との互換性を意図したものです。このスキルには、Qodo CLI 2.0.0 以降と、レビュー API v2 を備えたランタイムが必要です。 Windows では、PowerShell または Git Bash で、最初に Windows シェルを読んでください。

バージョンが古い場合、または解析できない場合は、whoami、login、管理対象ツールを実行せず、認証の問題として失敗を説明しないでください。CLI の自動更新はメジャーバージョンの範囲内にとどまるため、qodo update では 1.x から 2.x へ移行できません。必要な明示的な 2.x のインストールについて説明し、Qodo または組織が提供するチェックサム固定インストーラーを実行する前に、1回だけ確認を求めてください。記録済みの配布元を維持し、エンタープライズ環境をパブリックサービスに切り替えたり、インストーラーのダイジェストをでっち上げたりしないでください。インストール後、フラグなしのバージョン確認を再実行してください。拒否された場合、またはインストールが成功しなかった場合は、スキルとユーザーファイルを変更せずに停止してください。

クイックスタート

qodo --version                                                       # compatibility probe — run this FIRST
qodo read whoami --json --skill qodo-review-resolver --skill-version 1.4.9 --distribution skills-sh
qodo read pr-review-session findings --pr-url <PR_URL> --json       # the review session for a PR
qodo read pr-review-session findings --pr-url <PR_URL> --extended --json # details, if advertised by tool help
qodo pr-review-session mark-implemented --finding-ids <id>,<id> --explanation "..." --json
qodo pr-review-session dismiss --finding-ids <id> --reason intentional --explanation "..." --json
qodo read tools pr-review-session --json                            # exact safe tools + flags (offline)

解析するすべてのコマンドに --json を追加してください。読み取り内容は qodo read tools pr-review-session findings --json で確認し、書き込み操作の入力スキーマは qodo tools help pr-review-session <tool> --json で確認してください。どちらもオフラインでの探索であり、変更操作ではありません。 読み取り専用カタログには意図的に書き込み操作が含まれていません。カタログにないからといって、利用できないとは限りません。

認証後に dismiss／mark-implemented で unknown command が表示される場合は、ローカルのツールカタログが古い可能性があります。以下の説明に従って、1回だけ更新してください。それでもコマンドが見つからない場合、現在のワークスペースでは PR レビューの書き込み操作が公開されていません。その機能上の制約を報告し、繰り返し試さないでください。

qodo: command not found と表示されますか？ POSIX では "${QODO_HOME:-$HOME/.qodo}/bin/qodo" を再試行してください。Windows ではリンク先のガイドに従ってください。解決済みの呼び出し方法を維持し、使用できないランチャーは報告してください。 インストールされていない場合は、Qodo または管理者からチェックサム固定インストーラーを入手してください。ダイジェストをでっち上げたり、スクリプトをシェルにパイプしたりしないでください。

サンドボックス認証の診断。 認証情報がない場合、キーチェーンにアクセスできないことが原因の可能性があります。その可能性がある場合は、ログインを勧める前に、ホストの承認フローを通じて読み取り専用の qodo read whoami を指定どおりに1回再試行するよう求めてください。拒否された場合は停止してください。この承認が対象とするのはそのコマンドだけです。同じ実行ファイル、ワークスペース、デプロイ環境、実行コンテキストで成功した確認は再利用してください。ホストが必要とする承認はそれぞれ求めてください。ネットワーク、TLS、サービス、明示的な認可の失敗は、それぞれ固有の原因として診断し、ログインを勧めたり、サンドボックスを自動的に回避したりしないでください。

事前確認

1. 認証とカタログ。 この実行コンテキストで有効な確認がすでに済んでいる場合を除き、qodo read whoami を実行します。該当する場合はサンドボックスの診断後に、認証情報が明示的に不足している場合に限りログインします。組織指定の正確なログインコマンド／エンドポイントをそのまま使用し、顧客環境を推測で Cloud に切り替えてはいけません。No tool catalog cached は認証情報が不足している証拠ではありません。qodo tools --refresh で一度更新してから、確認を再試行します。それ以外のエラーが発生した場合は、そのエラーを維持してこのワークフローを停止します。本人確認に成功した後、管理対象コマンドが不明な場合は、カタログを一度更新してスキーマを再確認できます。それでも見つからない場合、または tool_unavailable の場合は、利用できない機能を報告します。ログインや更新を繰り返してはいけません。
2. PR の特定。 ユーザーから指定された PR URL を使用します。指定がなく、git リポジトリ内にいる場合は、現在のブランチに対応するオープン中の PR を推定し、操作を行う前にユーザーに確認します。PR URL を推測してはいけません。
3. 編集対象をチェックアウトに紐付ける。 報告のみを行う読み取りでは、任意の PR を対象にできます。ローカルで修正を行う前に、プロバイダーメタデータから PR のリポジトリを特定し、現在のチェックアウトのリポジトリをその origin から特定して、両方を大文字と小文字を区別しない完全な owner/repo 識別子に正規化します。両者は完全に一致する必要があります。origin がない、または曖昧な場合や、一致しない場合は停止し、正しいチェックアウトを開くようユーザーに依頼します。あるリポジトリの指摘を別の作業ツリーに適用してはいけません。対象 PR のブランチ、またはその PR 専用の分離された作業ツリーを使用し、ローカル HEAD がレビュー対象のコミット（または、この修正ワークフローによって生成された、検証済みのその子孫コミット）にあることを確認します。リポジトリ内にコミットが存在するだけでは不十分です。ローカルの差分を確認し、無関係な編集を保持します。この確認を満たすために、変更のある作業ツリーをリセットしたり、ブランチを切り替えたりしてはいけません。対象 PR が変更された場合は、これらの確認を繰り返します。

レビューセッションの取得

qodo read pr-review-session findings --pr-url <PR_URL> --json は、次を返します。

• review_session — 最新のレビュー実行。status、commit_sha（レビューに含まれる最後のコミット。これらの指摘が対象とするコード）、started_at が含まれます。null = PR はまだレビューされていません。その旨をユーザーに伝え、停止します（解決する指摘はありません）。
• findings[] — 現在のすべての指摘。それぞれに id、title、description、category、action_level（action_required > remediation_recommended > informational）、attribution_status、git_sha、location（file_path、start_line、end_line、side）、evidence.citations（各引用の source_type と source）が含まれます。これは、ローカルレビューでも使用される同じ既定の Finding オブジェクトです。利用できない位置情報や証拠は null です。位置情報を使って該当コードを確認し、安定した ID を使って、許可された結果を記録します。プロバイダーのコメント ID、内部レビュアーの判定、修正指示は、どちらのモードでも含まれません。

指摘が 0 件であることが、クリーンとの判定を裏付けるのは、完全かつ完了済みのレビューが現在の PR の HEAD を対象としている場合に限られます。

監査と調査のための拡張結果

通常のステータスポーリングでは、コンパクトな読み取り結果を使用してください。ユーザーが根拠や詳しい情報を必要とする場合は、qodo read tools pr-review-session findings --json を確認してください。スキーマで extended ブール値が宣言されている場合に限り、qodo read pr-review-session findings --pr-url <PR_URL> --extended --json を使用してください。 ツール／API の入力は extended: true です。省略または false の場合は、コンパクトなレスポンスが返されます。 これは保存済みデータをより多く読み取るものであり、レビューを再実行したり、レビューをより詳細にしたりするものではありません。

拡張結果には、location.code_snippet、却下理由／説明、review_runs、 evidence.explanation、より詳細な引用文／コンテキストが追加されます。監査出力では、各引用のソースタイプ、ソース参照、テキスト、ソース固有のメタデータを保持してください。 根拠を、その指摘の id および git_sha と関連付けてください。 現在の指摘は、review_session より前の実行で見つかったものである場合があります。

根拠が null の場合は、根拠を利用できないことを意味します。引用リストが空の場合は、記録された引用がないことを意味します。根拠フィールドが存在しない場合は、バックエンドが古い可能性があります。その制限を報告し、指摘に裏付けとなる根拠がないとは主張しないでください。カタログに extended がない場合は、既存の1回の再取得による復旧手順に従って、もう一度確認してください。それでも存在しない場合は、拡張読み取りを利用できないことを報告し、コンパクトな読み取りを引き続き使用してください。対応していないカタログに --extended を送信しないでください。代わりのフラグを考案したり、スクレイピングしたコメントで代用したりしないでください。

結果の qar_operation_result_truncated: true が設定されている場合は、読み取りが不完全であると報告し、レビューに指摘がない、または問題がないとは報告しないでください。拡張結果が示すのは現在の指摘と記録された実行であり、すべての指摘の変更履歴を網羅した不変の履歴ではありません。対応する前に、以下の鮮度チェックを行ってください。

セッション状態を最初に読み取る（指摘を信頼する前に）

review_session は、指摘が実際に確定しているか、またどのコードを対象としているかを示します。対応する前に確認してください。

• レビューはまだ実行中ですか？ API は実行中のレビューを started として報告します。これはポーリング中の状態です。ステータスのみを求められた場合は、この状態を報告して終了してください。依頼されたタスクに待機が含まれる場合に限り、ポーリングします。 failed、aborted、skipped、superseded は成功ではない終了状態です。これらを報告してループを停止してください。不明なステータスは、成功を意味するものでも、無期限にポーリングしてよいことを意味するものでもありません。
• 指摘はどのコミットを対象としていますか？ review_session.commit_sha は、レビューに含まれた最後のコミットです。これが PR の最新コミットより前の場合、指摘は古いものであり、最新のコードを反映していません。新しいコミットでレビューがまだ実行されていない（その場合は待機する）か、古い実行を見ている可能性があります。セッションが completed であり、かつその commit_sha が対象とするコミット（監視ループでは最新コミット）と一致する場合に限り、指摘を信頼してください。

現在のコミットを対象とした、完了済みレビューに対してのみ対応してください。実行中または古いレビューを根拠に、指摘の解決を承認することはできません。監視モードでは、再試行の遅延を守り、クリーンと判断する前にリポジトリの最新コミットを再確認してください。レビューに進展がない場合は、無期限にポーリングせず停止してください。

レビュー状況の提示

自然な文章で、結果 → 変更と対応の背景説明 → 検証 → 残作業の順に伝えます。報告のみを求められた場合は、現在のレビュー状況と、残っている指摘の影響から説明します。レビューでQodoが明らかにした具体的な懸念については一度だけ功績を認め、最終的な評価と推奨する対応は自分の責任で示します。ブランド名を冠した見出し、絵文字のバナー、スローガン、フッター、繰り返しの要約ブロックは使いません。必要に応じて、短い問題タイトルやリストを使います。

各指摘について、何が起こり得るのか、どの条件で起こるのか、ユーザーが意図した変更にとってなぜ重要なのかを説明します。コードと、利用可能なコーディングセッションでの決定や制約に照らして評価します。必要に応じてPRの背景情報を取得し、存在しないセッションを捏造しないでください。根拠を示し、指摘の参照情報と報告されたカテゴリ／レベルは、推奨する対応とは分けて保持します。修正、却下、調査のいずれを選ぶかと、その理由は自分の責任で判断します。意図的な選択を却下の根拠にできるのは、実装がその前提を確実に満たしている場合に限ります。協調的かつ事実に即した口調を保ち、Qodoの能力を定型的に断り書きすることはしません。編集や対応状況の記録には、既存のスコープと承認ゲートに従います。技術的な評価を行っても、それによって作業の許可が与えられるわけではありません。

構造化された状態からPR名、レビュー状況、レビュー対象のコミットを特定し、作業に着手する前にForgeのヘッドと比較します。レビューが古い、実行中、失敗、または存在しない場合は、その事実を明示します。コードを変更済み、対応状況を記録済み、更新後のコードをレビュー済みを区別します。テストの成功やステータスの書き込み成功は、更新後のコミットが問題なくレビューされたことを意味しません。現在のヘッドを対象に完了したレビューだけが、その判定の根拠になります。残っている指摘や不足している検証は、正直に報告します。たとえば、「[変更]により、Qodoが指摘した[リスク]に対処し、[ユーザーの決定]を維持しました。[検証結果]。最新のレビュー対象は[古いSHA]であり、[ヘッドSHA]のレビューは未完了です。」のように伝えます。実際に得られた結果だけを使います。監視モードでは、意味のある状態変化を報告し、ポーリングやステータス書き込みのたびに評価を繰り返しません。

トリアージ

• 未対応か対応済みかはattribution_statusで判断します。 返された値を、デプロイごとにサポートされている表現も含めて分類します。
  • 未対応 — 対応するもの： pending、partial_implementation、not_implemented、focus_areas_edited。
  • 対応済み — そのままにするもの： implemented、full_implementation、dismissed、detected_after_merge、outdated。見慣れない値は、問題なしと判断する際に黙って除外せず、報告します。
  • action_levelは重要度であり、未対応か対応済みかを示すものではありません。対応済みの指摘でもaction_requiredの場合があります。
• action_levelの順に並べます： まずaction_required、次にremediation_recommendedとします。informationalは任意の対応として扱い、必ず修正する必要はありませんが、提示します。
• 未対応の指摘はファイルごとにまとめ、各ファイルを一度だけ編集します。

ユーザーの指示を尊重する（任意のスコープ）

ユーザーから指示がある場合は、未対応の指摘に対するフィルターとして扱い、一致するものだけに対応します。対象を広げてはいけません。

• 重要度別 — 「対応必須の指摘を解決して」→ action_level == action_requiredのみ。「対応可能なものをすべて」→ action_requiredとremediation_recommended。
• カテゴリ別 — 「セキュリティの指摘だけ」→ category == Security（正確性、パフォーマンスなども同様）。
• 特定の指摘別 — 「指摘#3を修正して」「SQLインジェクションの件」→ idまたはtitleで照合。
• 報告のみ — 「レビューで何が見つかった？」「問題ない？」→ 指摘とその状態を要約し、コードは変更しません。

修正の指示がない場合、または実装を変更する権限がない場合は、action_required、次にremediation_recommendedの順に、承認を得るため提示します。informationalは提示するだけとし、自動修正しません。指示が曖昧な場合は、作業に入る前に、選択したスコープを一行で伝え、ユーザーが修正できるようにします。対応を見送った指摘と、その理由（対象外／却下済み／情報提供のみ）は必ず報告し、黙って除外しません。

2 つのモード

各ラウンドでは 指摘事項を解決する ことを行います。既存のユーザー権限（autofix または明示的な修正依頼）の対象となる修正のみを評価して適用します。それ以外の場合は、内容を提示して確認を求めます。プッシュの権限は別です。

1 回のみ（デフォルト）。 取得 → 未解決の指摘事項をすべて評価（トリアージ — pending だけでなく、4 種類すべての OPEN ステータスを対象） → 権限がない場合は提示して確認 → 権限のある修正をコードに適用 → ユーザーの許可範囲内でのみコミット／プッシュ → 修正内容と残りの指摘事項を要約します。 ローカルのみの修正の場合は「プッシュ待ち」と報告し、指摘事項のステータスは変更しないでください。プッシュの検証後は、次のレビューで自動的に再帰属されることを優先してください。手動でステータスを書き込む場合は、結果を記録する に記載の確認事項に加えて、明示的な許可も必要です。停止します。依頼がない限り、ループしないでください。トリアージでは、未解決の指摘事項をすべて対象としますが、選択画面で提示するのは対応可能な項目、つまり action_required、続いて remediation_recommended のみです。デフォルトの対象範囲に合わせて、informational は別途提示します。ユーザーから依頼があった場合に限り、informational を選択画面に含めてください。 提示することと選択することは別です。チェックボックスはすべて未選択の状態から始まります。

解決するまで監視（ユーザーが「見守って」／「クリーンになるまで続けて」と言った場合）。明示された修正権限は、その範囲内で再利用します。監視するだけでは編集権限は付与されません。指摘事項を解決して修正コミットをプッシュした後、Qodo が 新しい コミットを再レビューするため、次の手順に従います。

1. PR の現在のヘッド SHA（プッシュしたばかりのコミットなら git rev-parse HEAD、自分がプッシュしていない PR ならフォージのメタデータから gh pr view <pr> --json headRefOid）を記録します。これはメタデータの読み取りであり、レビューコメントのスクレイピングではないため、問題ありません。
2. 読み取りのたびに セッション状態を最初に読む に従います。上限のある監視中に限り started をポーリングします。成功以外の終了状態や不明な状態は報告して停止します。以前に完了した実行は古いため、新しいヘッドのレビューが表示されるまで、上限を設けて待機します。レビューが completed であり、かつ commit_sha がそのヘッド SHA と一致する 場合に限り、対応してください。
3. 最新のレビューが確認できた場合、未解決の指摘事項（4 種類すべてのステータス。partial_implementation も未解決のままです）が残っていれば解決し、繰り返します。残っていなければ、レビューがクリーンであると報告して停止します。
4. 上限を設けます。進展のないラウンドが数回続いたら停止し、延々と繰り返すのではなく、ユーザーに引き継ぎます。

指摘事項を評価する

Qodo の指摘事項を、コード、PR の意図、利用可能なセッションコンテキストに照らして評価します。最終的な技術的推奨事項とその根拠を示し、以下のユーザーのスコープと承認に従います。

各指摘事項を評価し、実際のコードと PR の意図に照らして推奨事項をまとめます。

• 妥当でスコープ内 → 修正が必要です。変更内容を記載します（title と description を読み、コードの場所を特定します。対象コードがローカルにない場合は、 qodo-codebase-wisdom スキルの読み取りツールが役立ちます）。
• 根拠がない、または対応済み → コードを根拠に却下を推奨します。意図的な選択を却下の根拠にできるのは、実装がその前提を確実に満たしている場合に限ります。
• 判断できない → 判断する前に必要な根拠や確認事項を特定します。

報告のみです。 評価を返したら終了します。変更なしでレビューするという明示的な依頼に対して、編集の承認を求めてはいけません。

編集権限がない場合に限り、提示して尋ねます。 autofix、明示的な修正依頼、または実装を含む権限がすでに適用されている場合は、この選択プロンプトを省略し、以下の承認済みの修正に従います。それ以外の場合は、上記の評価に基づいて、未解決でスコープ内の各指摘事項について、action_level／category と推奨事項を維持したうえで、どの指摘事項を解決するか1つのプロンプトで尋ねます。ホストが提供する機能を使います。複数選択機能がある場合（たとえば Claude Code の AskUserQuestion）はそれを使い、ない場合は番号付きリストを表示して「解決する番号を返信してください」と伝えます。いずれの場合もプロンプトは1つだけにし、指摘事項ごとに尋ねてはいけません。何も事前選択しません。 推奨するものを示しますが、ユーザー自身が選択する必要があります。このプロンプトを通過しない限り、指摘事項を編集してはいけないため、何も選ばずに Enter を押した場合は、どの指摘事項も解決してはいけません。ユーザーが選んだものだけを解決し、周囲のコードに合わせて通常どおり編集します。残りは、理由を添えてスキップしたものとして報告します。この権限がない場合のフローでは、ユーザーが選択する前に編集してはいけません。

承認済みの修正。 autofix または「アクションが必要な指摘事項を修正して」のような明示的な依頼は、その範囲内で根拠のあるコード修正を行う権限を与えます。特別なトークンや再確認は不要です。既存の実装権限が修正に適用される場合もあります。修正を適用する前に評価を示します。ステータスのみを求める依頼は編集権限を与えません。スコープが曖昧な場合は、一度だけ尋ねてください。修正権限も監視も、指摘事項のステータスを書き換える権限（dismiss または mark-implemented）やプッシュする権限を与えません。修正した指摘事項とスキップした指摘事項を報告します。

ユーザーのワークフローに従ってコミット／プッシュします。プッシュするように指示されていない限り、プッシュの前に確認してください。

意図されたシグナルは attribution_status です — 修正された指摘事項は、次回のレビューで自動的に implemented または full_implementation に再帰属されるため、プッシュ後に再取得し、未解決のものだけに対応します。ただし、これはツールであり、不具合が起きることもあります。確信を持って修正したのに指摘事項が未解決のままの場合や、ステータスが明らかにコードと矛盾する場合は、修正を繰り返さず、その不一致をユーザーに伝えて次に進みます。（解決は複数のラウンドを通じて収束します。また、修正によって本当に新しい指摘事項が見つかることもあり、監視ループがそれを検出します。）

結果を記録する

特定のステータスを書き込むには、明示的な承認を必須にしてください。コードの修正やプッシュの許可は、指摘をクローズする許可にはなりません。修正をプッシュした後は、自動で再帰属させる方法を優先してください。

指摘のクローズは書き込みです。Qodo のレビュー DB を更新し、指摘の PR コメントのスタイルを変更し、レビューの概要を再生成し、その指摘が保持しているマージポリシーのブロックを解除します。コマンドは 2 つあり、その違いが重要です。一方はコードを変更したと伝え、もう一方はコードは変更しておらず、その理由はこうですと伝えます。一方を他方の意味で使ってはいけません。

qodo pr-review-session mark-implemented --finding-ids <id>,<id> --explanation "what you changed" --json
qodo pr-review-session dismiss --finding-ids <id>,<id> --reason <reason> --explanation "why" --json

• PR ごとにまとめて、1 回呼び出します。 調整は指摘ごとではなく、呼び出しごとに 1 回実行されます。そのため、実装した指摘はすべて 1 回の mark-implemented にまとめ、同じ却下理由を共有する指摘はすべて 1 回の dismiss にまとめてください。ID は最大 100 個です。
• 明示的に承認され、実際に変更してプッシュしたコードに限り、mark-implemented を使います。 レビューで修正が検証されていなくてもマージゲートが解除されるため、誤った申告をすると、未修正の指摘が修正済みとして出荷されます。いずれにせよ次のレビューが実行されるなら、レビューに修正を自動で再帰属させる方法を優先してください。マージ前に次のレビューが実行されない場合や、今すぐゲートを解除する必要がある場合に使います。
• dismiss には、指摘ごとに毎回ユーザーから明示的な許可を得る必要があります。autofix はこれを許可しません。 autofix はコードの編集への同意であり、次のレビューで再確認されます。一方、却下はレビューが依然として妥当だと考えている指摘をクローズします。チームにも表示され、再び開かれることはありません。却下を提案する指摘とその理由を提示し、ユーザーが指定したものだけを却下してください。
• --reason（必須）：false_positive（指摘が誤り）・intentional（コードは意図的で正しい）・deferred（実際の問題だが、この PR の範囲外）・rejected（内容を理解したうえで対応しない）。必ず --explanation も追加してください。レビュー担当者は後で、あなたの説明がない状態でこれを読みます。
• 指摘ごとに results を読み、呼び出し全体が成功したと思い込まないでください。 個々の ID が失敗しても HTTP 200 が返されます。not_found（ID が間違っているか、ワークスペースが違う）と conflict（すでにクローズされているか、PR にリンクされていない）は終端状態なので、再試行しないでください。reconciled: false は DB の変更は反映されたものの、PR 側の更新が完了していないことを示します。同じコマンドを再実行しても安全で冪等であり、いずれにせよ次回のレビュー時に PR は自動修復されます。already_dismissed／already_implemented は保存済みの理由を報告します。再実行しても元の理由は上書きされません。

例

ユーザー：「https://github.com/acme/api/pull/318 の対応が必要な指摘を解決してください」

1. qodo read whoami → ログイン済み。
2. qodo read pr-review-session findings --pr-url https://github.com/acme/api/pull/318 --json → review_session：status: completed、commit_sha: a1b2c3d（= PR の最新コミットなので、指摘は最新の状態です）； findings：未解決が 3 件（pending が 2 件、partial_implementation が 1 件）で、そのうち action_required が 2 件、informational が 1 件。
3. 指示の対象は action_required に限定されているため、その 2 件に対応します。informational の指摘は対象外です（報告はしますが、修正はしません）。
4. それぞれを評価します。「文字列補間で SQL を組み立てている」→ 実際の問題 → db/orders.py でクエリをパラメーター化することを提案します。「外部への呼び出しにタイムアウトが設定されていない」→ クライアントが上流ですでにデフォルトのタイムアウトを設定している → すでに対応済み → その理由を添えて対応を見送ることを提案します。
5. 明示的な依頼で許可されているのは、対応が必要な指摘の修正です。SQL クエリをパラメーター化して検証します。タイムアウトはすでに対応済みであること、情報提供のみの指摘は対象外であることを報告します。どちらも自動的に却下されることはありません。ローカルでの修正は、PR のレビュー状態とは分けて報告します。別途、適切な許可を得た場合に限ってプッシュし、その後、新しい最新コミットのレビューを確認します。

設定

--json を使用し、review_session.commit_sha を Forge のヘッドメタデータと比較してください。また、装飾のないバージョン確認の後、最初の認証済み Qodo 呼び出しで、正確なスキル／バージョン／配布元の情報を記録してください。読み取りおよび書き込み機能は、インストール済み CLI カタログから検出します。レンダリングされた Forge コメントをデータソースとして使用することはありません。

エラー処理

null セッション、実行中のレビュー（started）、古いコミット、書き込み機能の不足、レート制限、ツールループエラーを明示的な状態として扱ってください。これらをレポートに残し、レビューを問題なく見せるためだけに指摘事項をクローズしてはいけません。

ガードレール

• 鮮度とは、タイムスタンプではなく、レビュー対象のコミットに対する完了済みレビューのことです。 指摘事項はreview_session.commit_shaを対象とし、statusがcompletedになった場合にのみ最終確定します。プッシュ後は、完了済みレビューのcommit_shaがPRのヘッドに追いつくまで、指摘事項は古いものとして扱ってください。そうしないと、進行中のレビューに基づいて対応したり、指摘事項が対象としていないコミットを「修正」したりすることになります。
• Forge に自分で投稿してはいけません。 書き込みはdismiss／mark-implementedのみです。これらはQodo経由で行い、QodoがPRを調整します。指摘事項を「解決」するために、Forgeへの書き込みツール（コメント、承認、ラベル、説明）を呼び出してはいけません。指摘事項はコードで解決し、その結果を記録してください。
• 誤りだと判断した指摘事項には、異議を唱えてもかまいません（明確な理由を添えてください）。システム上で却下できるようになりましたが、それを判断するのはあなたではなくユーザーです。却下を提案し、その理由を明示したうえで、ユーザーから明確な指示があった場合にのみ対応してください。実際に意見が食い違う場合、裁定者はユーザーです。
• 解決していないものをクローズしてはいけません。 スコープの都合で見送った指摘事項は未解決のままにし、一覧をきれいに見せるためにdeferredとして却下するのではなく、見送りとして報告してください。
• PR の URL を推測してはいけません。まず特定してください。セッションがnullの場合、レビューはまだ行われていません。
• MT-TOOL-LOOPまたはMT-RATE-LIMITEDエラーが発生した場合は、停止または待機し、再試行ではなく別の方法に切り替えてください。

許可された変更を行った後は、何が改善したか、各判断の理由、何を検証したか、まだ対応が必要なことを報告してください。ローカルの編集、記録された処置、レビューの状態は、それぞれ区別して扱ってください。