qodo-pr-resolver

指摘の読み取りと解決

説明

qodo CLI を使用して、任意の PR（自分の PR でも他の人の PR でも）のレビューセッション（ステータス、レビューされたコミット、各指摘の解決状況）を読み取ります。読み取りだけでも有効な使い方です。レビューの状況や、指摘された内容（たとえば、最新のコミットに未解決の指摘がないことをマージ条件とする場合）を報告したら、そこで終了できます。さらに進める場合は、コード内の未解決の指摘を解決します。判断は自分で行ってください（レビューは強力なセカンドオピニオンですが、絶対ではありません）。デフォルトでは指摘を評価し、どれを適用するかはユーザーに選んでもらいます（直接適用するには autofix を渡します）。1 回だけ実行して（報告し、ユーザーが承認したものを解決する）、または監視ループとして実行します（解決 → Qodo に新しいコミットを再レビューさせる → すべて解決するまで繰り返す）。次に、解決した指摘の結果を記録します。修正した指摘には mark-implemented、コードを変更せずに閉じることにユーザーが同意した指摘には dismiss を使います。これにより、それらの指摘が課しているマージポリシーのブロックが解除されます。これを省略すると、人が PR 上でクリックして処理するまでレビューは赤のままです。自分で forge に投稿することはありません。ステータスツールは Qodo のレビュー DB に書き込み、Qodo が PR のコメントと同期します。（git rev-parse HEAD や gh pr view --json headRefOid など、通常の git／forge のメタデータ読み取りは問題ありません。実際、以下の最新状態チェックで必要です。「スクレイピングしない」というルールの対象は qodo であり、シェルではありません。）

前提条件

• Qodo CLI が認証済みで、構造化された PR レビューセッションツールを提供していること。
• 正確な PR URL と現在の head SHA を、レビューコメントをスクレイピングせずに解決できること。
• 指摘への書き込みには、ユーザーからの明示的な許可、またはスキルの明示的な autofix 範囲があること。

手順

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

レビューのステータスや指摘を確認するときは、必ず以下の qodo 読み取りコマンドを実行してください。gh／curl で表示済みの PR レビューコメントを取得してはいけません。コメント UI は情報が失われやすく、プロバイダー固有であり、head コミットに対して古い内容を読み取りやすいためです。このツールはレビュー対象の commit_sha を返します。最新かどうかを判断するには、その commit_sha を PR のheadと比較します。直前にプッシュした PR なら git rev-parse HEAD で直接確認できます。他の PR なら、通常の forge メタデータ（gh pr view <pr> --json headRefOid、git ls-remote）として読み取れます。このルールが対象とするのはレビューの読み取り（コメントのスクレイピングをしないこと）だけです。head SHA などの forge メタデータを禁止するものではありません。

スキル更新通知への対応

Qodo コマンドは、成功した場合でも stderr に QODO_NOTICE <json> を出力することがあります。code が qodo_skill_update_available の場合は、コマンドの結果を保持したまま、現在のタスクを完了してください。その後、通知の steps に従います。まず読み取り専用のインベントリを実施し、インストール済みの Qodo パッケージとスコープを特定し、正確なライフサイクルオーナーの更新コマンドまたは UI 操作を提示してから、変更を加える前に一度だけユーザーに確認します。ユーザーが拒否した場合は、現在のバージョンを引き続き使用できる状態に保ちます。

別のライフサイクルオーナーを呼び出したり、プレースホルダーを推測したり、任意のパッケージを暗黙的にインストールしたりしてはいけません。承認された更新後は、通知に記載されたホストの再起動を求めてください。現在のセッションでは、引き続き古いスキルが読み込まれている場合があります。

ランタイム互換性ゲート

まず、以下の「qodo: command not found」への対処に従って実行ファイルを特定します。ほかの Qodo コマンドを実行する前に、プロベナンスフラグを付けず、表示どおりに <qodo> --version を実行します。このオプションを付けないプローブは、意図的に古い Qodo CLI との互換性を確保しています。このスキルには、Qodo CLI 0.1.0-next.37 以降が必要です。

バージョンが古い場合、またはバージョンを解析できない場合は、whoami、login、管理対象ツールを実行しないでください。また、失敗を認証の問題として説明しないでください。このスキルがランタイムより新しいことを説明し、ランタイムにすでに記録されている配布元を使う更新コマンドとして qodo update を示し、実行前に一度だけ確認を求めます。顧客向けのデプロイでは、組織が指定した更新元を維持し、公開サービスに切り替えないでください。承認された更新の後、オプションを付けないバージョンプローブを再実行し、最小要件を満たしている場合にのみ続行します。ユーザーが更新を拒否した場合、または更新に失敗した場合は、現在のスキルとユーザーファイルを変更せずに停止します。

クイックスタート

qodo --version                                                       # compatibility probe — run this FIRST
qodo read whoami --json --skill qodo-review-resolver --skill-version 1.4.4 --distribution marketplace --host claude-code
qodo read pr-review-session findings --pr-url <PR_URL> --json       # the review session for a PR
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 [<tool>] --json を使って、正確なツール名、フラグ、読み取り／書き込みの区分を確認してください（オフラインで表示できます）。上記の名前は例示であり、現在の内容と一致する保証はありません。

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

qodo: command not found と表示されますか？ インストールされていないのではなく、PATH の問題です。GUI から起動したエージェント（Claude Code デスクトップアプリなど）は、最小限の PATH でシェルを実行します。絶対パス ~/.qodo/bin/qodo（または設定されている場合は $QODO_HOME/bin/qodo）で再試行し、ここで実行するすべての qodo コマンドでそのパスを使い続けてください。そのファイルも存在しない場合に限り、qodo は実際にインストールされていません。Qodo または組織の管理者から、チェックサムが固定されたインストーラーコマンドを入手するようユーザーに伝えてください。インストーラーは https://get.qodo.ai から提供されますが、ダイジェストを推測したり、インストーラーをシェルに直接パイプしたりしないでください。

サンドボックス認証の診断。 サンドボックス環境で qodo read whoami が何らかの理由（Not logged in を含む）で失敗した場合は、ログインやツールの更新を勧める前に、サンドボックス外で qodo read whoami を一度だけ読み取り専用で再試行することをユーザーに承認してもらってください。キーチェーンのエラーが一般的な認証エラーとして報告される場合があるため、サンドボックス内での結果だけでは診断できません。この承認が適用されるのは、この診断の再試行一度のみです。承認を再利用したり、継続的な承認を求めたり、その後の Qodo コマンドを自動的にサンドボックス外で実行したりしないでください。再試行が成功した場合は、通常のコマンドごとの権限確認を続けてください。それでも失敗する場合は、通常の認証トラブルシューティングに従ってください。

事前確認

1. まず認証します。 qodo read whoami を実行します。該当する場合は上記のサンドボックス再試行後、終了コードが 0 以外なら、ユーザーに qodo login を実行するよう伝えてから停止します。認証情報を推測してはいけません。ツールはログイン後にのみ利用できるため、Not logged in または No tool catalog cached は「qodo login を実行する」という意味として扱い、ログインが完了する前に再試行してはいけません。 whoami が成功した状態での unknown command／unknown option は認証エラーではありません。 qodo tools --refresh を一度実行し、qodo read tools pr-review-session --json で再確認します。書き込みコマンドが引き続き見つからない場合、このアカウント／ワークスペースでは現在、読み取り専用のレビュー機能のみ利用できると報告します。再ログインしたり、無期限に再試行したり、構造化された書き込みの代わりにフォージのコメントを使ったりしてはいけません。
2. PR を特定します。 ユーザーから指定された PR URL を使用します。指定がなく、git リポジトリ内にいる場合は、現在のブランチに対応するオープンな PR を推定し、操作する前にユーザーに確認します。PR URL を推測してはいけません。
3. 編集対象をチェックアウトに紐付けます。 報告のみを行う読み取りでは、任意の PR を対象にできます。ローカルで修正を行う前に、プロバイダーのメタデータから PR のリポジトリを特定し、現在のチェックアウトのリポジトリを origin から特定して、両方を大文字小文字を区別しない完全な owner/repo 識別子に正規化します。両者は完全に一致しなければなりません。origin が見つからない、または曖昧な場合、あるいは不一致の場合は停止し、正しいチェックアウトを開くようユーザーに依頼します。あるリポジトリの指摘を別のワークツリーに適用してはいけません。監視ループ中に対象 PR が変わった場合は、この確認を繰り返します。

レビューセッションを取得する

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

• review_session — 最新のレビュー実行：status、commit_sha（レビューに含まれる最後のコミット。指摘が対象とするコード）、started_at。null は PR がまだレビューされていないことを意味します。ユーザーに伝えて停止します（解決すべき指摘はありません）。
• findings[] — 現在のすべての指摘。それぞれに title、description、category、action_level（action_required > remediation_recommended > informational）、attribution_status、git_sha、review_run_id、comment_id／inline_comment_id が含まれます。

review_session が null ではなく、finding_count: 0 の場合は、問題のないレビューです。

指摘を信頼する前に、まずセッション状態を確認します

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

• レビューはまだ実行中ですか？ status が終端状態／completed 状態でない場合（例：started／進行中）、レビューは実行途中であり、指摘は暫定的で変更される可能性があります。まだ指摘を解決してはいけません。status が completed になるまで qodo read pr-review-session findings … --json をポーリングします。
• 指摘はどのコミットを対象としていますか？ review_session.commit_sha は、レビューに含まれる最後のコミットです。PR の HEAD より古い場合、指摘は古い情報であり、最新のコードを反映していません。新しいコミットを対象にしたレビューがまだ実行されていない（待機する）か、古い実行結果を見ている可能性があります。セッションが completed であり、かつその commit_sha が対象とするコミット（監視ループでは HEAD）と一致する場合にのみ、指摘を信頼します。

要するに、現在のコミットを対象とする完了済みレビューに対してのみ対応します。レビューが実行中、または commit_sha が遅れている場合は、修正せずに待機します。

レビュー状況の提示

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

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

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

トリアージ

• 未対応か完了かはattribution_statusで判断します。これは3種類の値に分類されるフィールドではなく、保存された値をそのまま持つため、pendingだけに一致させると未対応の作業を見落とします。
  • 未対応 — 対応してください： pending、partial_implementation、not_implemented、focus_areas_edited。最後の3つは、指摘がまだ解決していないことを示す再分類です（一部修正されていても、指摘は未対応です）。
  • 完了 — 変更しないでください： 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 は自動修正せずに提示します。指示が曖昧な場合は、対応を始める前に、選択したスコープを1行で示して、ユーザーが変更できるようにします。どの指摘をスキップしたか、その理由（スコープ外／却下済み／情報提供のみ）も必ず報告し、黙って除外してはいけません。

2つのモード

各ラウンドでは、「指摘の解決」にある提示と確認のゲートに従います。評価して提示し、ユーザーに解決する指摘を選んでもらいます。ただし、autofix が有効な場合は、確認を求めずに推奨される修正を適用できます。いずれの場合も、指示がない限り、プッシュの前に確認を求めてください。

1回のみ（デフォルト）。 取得 → 未解決の指摘をすべて評価（トリアージ。pending だけでなく、4つすべての OPEN ステータスが対象）→ 提示して確認（または autofix の場合は直接適用）→ 選択された指摘をコードで解決 → ユーザーのワークフローに従ってコミット／プッシュ → 結果を記録（修正したものは mark-implemented、変更なしで閉じることにユーザーが明示的に同意したものは dismiss）→ 解決したものと残っているもの（例：スキップ／却下済み／情報提供のみ）を要約します。終了します。求められない限り、繰り返してはいけません。トリアージでは未解決の指摘をすべて確認しますが、選択画面で提示するのは、対応可能なもの、つまり action_required、続いて remediation_recommended のみです。これは上記のデフォルトスコープに一致します。informational は別途提示し、ユーザーに求められた場合のみ選択画面に含めます。（提示は選択ではありません。すべてのチェックボックスは未選択の状態から始めます。）

問題がなくなるまで監視する（ユーザーが「見守って」／「問題がなくなるまで続けて」と言った場合）。このループを自動で進めるのは autofix が有効な場合です。有効でない場合は、各ラウンドで引き続き提示して確認を求めます。指摘を解決して修正コミットをプッシュすると、Qodo は新しいコミットを再レビューします。そのため、次の手順に従います。

1. PR の現在の head SHA、つまり直前にプッシュしたコミット（git rev-parse HEAD）を記録します。自分がプッシュしていない PR の場合は、forge のメタデータから読み取ります（gh pr view <pr> --json headRefOid）。これはメタデータの読み取りであり、レビューコメントのスクレイピングではないため、問題ありません。
2. レビューが completed であり、かつその commit_sha が head SHA と一致するまで、qodo read pr-review-session findings … --json をポーリングします。両方の条件を満たすまでは、指摘は古いか暫定的なものです（レビューがまだ実行中か、修正前のコミットを対象としている状態です）。これらに基づいて対応してはいけません。
3. 最新のレビューが得られたら、未解決の指摘（4つすべてのステータスが対象。partial_implementation も未解決です）が残っていれば解決して繰り返します。残っていなければ、レビューに問題がないことを報告して終了します。
4. 繰り返しには上限を設けます。進展がないまま数ラウンドを超えたら停止し、無限に続けるのではなくユーザーに引き継ぎます。

指摘への対応

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

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

• 妥当で、範囲内 → 修正が必要です。変更内容を記載してください（title と description を読み、コードの場所を特定してください。ローカルにない場合は、 qodo-codebase-wisdom スキルの読み取りツールが役立ちます）。
• 根拠がない、またはすでに対処済み → コード上の根拠を示して、却下を推奨してください。意図的な選択であることを理由に却下できるのは、実装によってその前提が保証されている場合に限ります。
• 判断がつかない → 決定前に必要な根拠や確認事項を示してください。

提示して確認する（デフォルト）。上記の評価に基づき、未解決で範囲内の各指摘について、action_level／category と推奨事項を維持したうえで提示し、どの指摘に対応するかを1 回のプロンプトで確認してください。ホストが提供する機能を使ってください。複数選択できる機能があれば（たとえば Claude Code の AskUserQuestion）、それを使い、なければ番号付きリストを提示して「対応する指摘の番号を返信してください」と伝えます。指摘ごとに確認してはいけません。最初から選択済みの項目はありません。 推奨する指摘にはその旨を示しますが、ユーザーが明示的に選ぶ必要があります。このプロンプトが、指摘に基づく編集を始める前の最後の確認です。何も入力せずに Enter を押した場合、指摘は一切解決してはいけません。ユーザーが選んだものだけを通常どおり編集し、周囲のコードに合わせてください。ユーザーが選ぶ前にコードを編集してはいけません。対応しなかった指摘は、その理由とともにスキップしたと報告してください。

自動修正（確認を省略）。呼び出しに autofix というトークンが明示的に含まれる場合に限り（例：qodo-review-resolver autofix）、プロンプトを省略します。「そのまま直して」「確認は不要」のように、明示的なオプトインに見えるだけの表現では不十分です。ここで意図を誤って読み取ると、ユーザーが承認していないコードを編集することになります。これこそ、この確認が防ぐべき事態です。意図を推測した場合は、適用する範囲を具体的に示して、確認を 1 回だけ求めてください。「autofix と解釈しました。推奨した N 件の指摘を解決しますか？」のように尋ね、「N 件すべてを解決しますか？」とは尋ねないでください。後者は全件を意味するように受け取られ、この確認が防ぐべき曖昧さによって範囲が広がってしまいます。いずれの場合も、評価で決めた内容だけを適用し、それ以外は変更しないでください（指摘はたいてい正しいものですが、あなたは人の判断を介さない承認係ではなく、対応に関わるエンジニアです）。解決した内容とスキップした内容を報告してください。

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

意図されたシグナルは attribution_status です。修正された指摘は、次回のレビューで自動的に 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 が失敗しても、ステータスコードは 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 の HEAD なので、指摘は最新です）； findings：未解決が 3 件（pending が 2 件、partial_implementation が 1 件）— action_required が 2 件、informational が 1 件。
3. 指示で action_required に絞り込まれているため、その 2 件に対応します。情報提供のみの指摘は対象外です（報告はしますが、修正はしません）。
4. それぞれを評価します。「文字列補間で SQL を構築している」 → 妥当 → db/orders.py のクエリをパラメーター化するよう提案します。「外部への呼び出しにタイムアウトが設定されていない」 → クライアントが上流ですでにデフォルトのタイムアウトを設定している → 対応済み → その理由でスキップするよう提案します。
5. それぞれの提案を添えて両方を提示し、どれを解決するか複数選択で尋ねます。どちらにもチェックを入れず、SQL の指摘には推奨マークを付けます。ユーザーが選んだ内容を適用した後、次のように報告します。「SQL の指摘を解決しました（db/orders.py のクエリをパラメーター化しました）。タイムアウトの指摘は上流ですでに設定されているためスキップし、情報提供のみの指摘 1 件は対象外として残しました。プッシュしていただければ再確認します。または、『watch』と言えば、レビューがクリーンになるまで確認を繰り返します。」 （ユーザーが resolve … autofix と指定していた場合は、確認を求めずに推奨する修正を直接適用していました。）

設定

--json を使い、review_session.commit_sha を forge の HEAD メタデータと比較して、最初の Qodo 呼び出しでスキル／バージョン／配布元の正確な由来情報を記録します。読み取りと書き込みの機能は、インストール済み CLI カタログから確認します。forge に表示されたコメントをデータソースとして使うことはありません。

エラー処理

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

ガードレール

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

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