ai-diff-reviewer

AI Diff Reviewer — ローカルおよび CI の補助スキル

AI Diff Reviewer は、CI で各プルリクエストに対して LLM レビューを実行する GitHub Action です。このスキルはそのローカル版で、編集中のブランチに対し、コーディングエージェント（Cursor、Claude Code、Codex、Gemini、Copilot、Cline、Windsurf、Grok CLI、Pi、OpenCode）を使って同じレビューを実行します。また、リポジトリにまだ CI Action がない場合は、CI Action 自体のインストールと設定も行います。

対象は 2 種類ですが、スキルは同じです。

• リポジトリですでに CI Action を実行している場合 → CI で検出される内容をプッシュの数秒前に見つけられるよう、このスキルをローカルで使用します。CI が同じ拡張ファイル（prompt-extension-file: .review/extension.md）を参照するよう設定されていれば、ローカルと CI のレビューは一致します。ベースプロンプトとオーバーライドは同じです。設定方法については、以下の「パリティ保証（フロー B）」セクションを参照してください。
• リポジトリにまだ Action がない場合（または使いたくない場合）→ このスキルでローカルの完全なレビューを実行できます。さらに準備ができたら、厳格度、トリガー、外部コントリビューターのポリシーに適切なデフォルトを設定して、CI に Action をインストールする作業も支援します。

連携する 6 つの機能を、意図に応じて使い分けます。

#	機能	サブスキル	実行環境
1	現在のブランチでレビューを実行する	(デフォルトのフロー — このファイル)	🖥️ ローカル
2	リポジトリ固有のオーバーライド（.review/extension.md）を作成する	generate-extension	🖥️ ローカル + ☁️ CI（共有ファイル）
3	GitHub Action をインストールし、pr-review.yml を作成する	setup	☁️ CI
4	差分から PR のタイトルと本文を下書きする	open-pr	🖥️ ローカル → GitHub
5	PR 上の CI レビュー（まず v3 の構造化出力アーティファクトを確認し、なければレビューコメントを確認）を読み、指摘を適用・保留・スキップする手順を案内する	apply-review	☁️ CI → 🖥️ ローカル
6	1 回の実行で一連の作業を完了する：すべてのワークフローを確認して PR の実行結果をチェックし、現在のヘッドに対するレビューを待ち、その指摘に対応し（適用 → コミット → プッシュ）、失敗したワークフロー（codecheck、テスト、ブランチが最新でない状態）を修正し、このリポジトリのトリガー方式（ラベルの切り替えまたはプッシュ）に従ってレビューを再実行する。PR がトリガー用ラベルなしで作成されていた場合は、最初のレビューも実行する	address-review	☁️ CI → 🖥️ ローカル → ☁️ CI

サブスキル 3（setup）は、setup/reference.md にある、すべての action.yml 入力のリファレンスマニュアルも兼ねています。そのため、どのエージェントでも Action のソースを開かずに 「strictness は何をするのか？」 に回答できます。

バージョンの一致。 このスキルの prompt.md は、同じタグ付きリリースで Action に含まれるものとバイト単位で一致します（CI の Skills — prompt-sync invariant ジョブで確認されます）。両方の環境で @v2.1.0 を固定すると、同じ方法論と重大度モデルが保証されます（CI では Iteration-Aware Review によって 2 回目以降に重複が除去される場合がありますが、ローカルレビューは常に全件を確認します）。

ソース：https://github.com/DailybotHQ/ai-diff-reviewer · ライセンス：MIT

---

サポート対象の 2 つのフロー：ローカルのみ、または両方の環境

6 つのサブスキルはそれぞれ独立しています。順序の指定はなく、CI GitHub Action のインストールは、このスキルをローカルで使うための前提条件ではありません。利用するリポジトリは、次の 2 つのフローのいずれかに該当します。リポジトリの用途に合ったものを選んでください。

フロー	使用する場面	実行するサブスキル	スキップするサブスキル
A. ローカルのみ	現在作業中のブランチで、コーディングエージェントに同じレビュー手法を実行させたいものの、すべての PR で CI レビューを実行したくない場合に使用します。個人のリポジトリ、実験用のリポジトリ、チームがまだ自動 PR レビューを導入していないリポジトリでよく使われます。	任意ですが、推奨します： generate-extension（.review/extension.md を調整するため、1 回実行します）。その後、各ブランチで親の run a local review フローを実行します。拡張ファイルがある場合もない場合も動作します（ステップ 2.5 を辞退した場合は、同梱のベースプロンプトにフォールバックします）。最後に open-pr を任意で実行します。	setup — 実行しないでください。.github/workflows/pr-review.yml を書き込み、CI Action を有効にします。apply-review` — 適用するものはありません（Action をインストールしない限り、CI レビューは PR に投稿されません）。
B. 両方	プッシュ前のローカルレビューと、すべての PR での完全な CI レビューの両方を実行したい場合に使用します。両方で同じ手法と重大度モデルを共有します（CI では、以下で説明する IAR により、2 回目以降のラウンドで重複を除外する場合があります）。チームのリポジトリや、本番環境に関わるすべてのものに推奨されます。	setup（1 回実行して CI Action をインストールし、ステップ 5 で generate-extension への引き継ぎを受け入れます）。その後、各ブランチで親の run a local review フローを実行します。PR の準備ができたら open-pr を実行します。プッシュ後、CI がレビューを投稿したら、apply-review で指摘事項を読み取り、address-review で一連の作業を完了します（指摘事項を解決し、PR で実行されるほかの失敗したワークフローを修正し、コミットしてプッシュし、レビュアーを再実行します）。	なし — ライフサイクル全体を通じて、5 つの機能すべてを使用します。

同等性の保証（フロー B）。 setup が prompt-extension-file: .review/extension.md を設定したワークフローを書き込む場合（ステップ 5 で generate-extension への引き継ぎを受け入れたときのデフォルト）、CI Action はローカルエージェントが使用するものと同じファイルを読み取ります。同じベースプロンプトと同じ拡張ファイルにより、ローカルと CI の両方で同じレビュー手法と重大度モデルが使用されます。ただし、Iterative-Aware Review が重複を除外するため、CI では世代の 2 回目以降のラウンドで、指摘事項の数が少なくなる場合があります（ローカルレビューでは重複を除外しません。以下を参照）。ステップ 5 での引き継ぎを辞退した場合、setup は prompt-extension-file を省略し、ベースプロンプトのみが同等になります。後から手動で入力を追加するか、setup を再実行して引き継ぎを受け入れることができます。

CI のみの機能（ローカルでは再現されません）。 3 つの Action 機能は GitHub Actions でのみ実行され、このスキルのローカルレビューフローでは実行されません（ローカルでは、コーディングエージェントがすでに使用しているモデルでレビューが実行されます。Action のプロバイダー／api-base の選択と使用状況のテレメトリは適用されません）：

1. イテレーションを考慮したレビュー（IAR） — ラウンドをまたいでコンテンツを基準に重複を排除し、4 つの収束ポリシー（デフォルトは first-pass-exhaustive）、エスケープ用ラベル（full-review-please）、ユーザーによる強制リセット（applied-label を削除してから再トリガー）を備えています。ローカルレビューは常に、現在の差分全体を対象としたフルパスです。そのため、CI が同じ世代の 2 回目以降のラウンドですでに重複排除した指摘が表示される場合があります。仕様： docs/ITERATION_AWARENESS.md。 設定例： examples/iteration-aware.yml。
2. skip-review-label による緊急バイパス — 設定されたラベルが PR に付いている場合、CI は LLM を呼び出さず、成功として処理を短絡します。ホットフィックス／ロールバック専用です。このラベルはルールセットで保護してください。仕様： docs/TRIGGER_MODES.md § 緊急バイパス。 例： examples/skip-review-label.yml。
3. 差分レビューによる追加ラウンドと使用状況のテレメトリー（v2.1.0+） — 2 回目以降のラウンドでは、CI は前回のレビュー以降に変更された部分と、まだ未解決のまま残っている自身の指摘のみをレビューします（解決済みという申告は参考情報です。スレッドを解決するのはメンテナーです。ただし v2.3.1 以降、スレッドの collapse-previous によってすでに最小化された、裏付けのある修正はランタイムが終了扱いにします）。また、CI の各レビューの最後には **Usage:** 行（トークン数、キャッシュヒット率、ターン数、コスト）が表示されます。ローカルレビューはフルパスで、使用状況の行は表示されません。仕様： docs/ITERATION_AWARENESS.md § 14。

IAR のすべての設定項目と skip-review-label を含む入力リファレンス全体は、 setup/reference.md にあります。

エージェントへのフローの伝え方。 あいまいな依頼「レビュアーをセットアップして」が、どちらのフローを指すのか判断できない場合、エージェントが確認します。その質問を省くには、各リポジトリで初回にフローを明確に指定してください。

• フロー A：「ai-diff-reviewer をローカル専用でセットアップしてください — GitHub Action はインストールしないでください。」
• フロー B：「ai-diff-reviewer を完全にセットアップしてください — Action のワークフローをインストールし、拡張ファイルも生成してください。」

リポジトリ内での以降の依頼（「ブランチをレビューして」「PR を開いて」など）は、どちらのフローでも同じように機能します。フローの違いが関係するのは初回のセットアップ時だけです。

---

インストール

# Latest v2.x
npx skills add DailybotHQ/ai-diff-reviewer --skill ai-diff-reviewer

# Or pin to a specific tag for reproducibility
npx skills add DailybotHQ/[email protected] --skill ai-diff-reviewer

これにより、利用するリポジトリの .agents/skills/ai-diff-reviewer/ にスキルが格納され、ソースとコンテンツハッシュが skills-lock.json に記録されます。そのため、チームメイトは誰でも npx skills experimental_install で同一のバイト列を復元できます。最新バージョンに更新するには、npx skills update ai-diff-reviewer を実行してください。

Git リポジトリのスラッグに関する注意。 リポジトリのパスは DailybotHQ/ai-diff-reviewer のままです（歴史的な名称です。v1.0.0 以降の公開タグ、および現在のメジャーバージョン @v2 で使用されています）。--skill ai-diff-reviewer フラグは Marketplace の掲載名と一致しており、どちらも同じ製品を指します。

---

有効化

フロントマターの description には、コンパクトなルーティング概要のみが記載されています（ホスト側では 1,024 文字に制限されています）。トリガーの全一覧はここに記載されており、ルーティングの正式な情報源となります。

デフォルトフロー（レビューを実行）— トリガー：

• 「現在のブランチをレビューして」
• 「変更内容のコードレビューを実行して」
• 「プッシュ前に事前レビューをして」
• 「main との差分をコードレビューして」
• 「現在のコミットについて CI がどう判断するか教えて」
• 「<rev> と比較してレビューして」、「<rev> 以降の範囲をレビューして」、 /ai-diff-reviewer --base <rev>（ベースを明示 — ステップ 1）

拡張ファイル生成フロー — トリガー：

• 「このリポジトリ用に .review/extension.md を生成して」
• 「このプロジェクト向けにコードレビューをカスタマイズして」
• 「リポジトリ固有のレビュー規則を書くのを手伝って」
• 「この技術スタックに合わせてレビュアーを調整して」

セットアップフロー（GitHub Action をインストール）— トリガー：

• 「このリポジトリに AI Diff Reviewer をセットアップして」
• 「レビューアクションを設定して」
• 「AI Diff Reviewer GitHub Action をインストールして」
• 「pr-review ワークフローの作成を手伝って」
• 「このプロジェクトに AI Diff Reviewer を追加する方法を教えて」
• 「ai diff reviewer のセットアップ方法を教えて」（大文字・小文字は問いません）
• アクションに関するリファレンス形式の質問への回答としても起動します。たとえば 「strictness では何ができますか？」、「label-gate の使い方を教えて」 などです。setup/reference.md を参照してください。

Open-PR フロー（プルリクエストを作成する）— トリガー：

• 「PR を開いて」「このブランチのプルリクエストを作成して」
• 「PR のタイトルと説明文を下書きして」
• 「PR の本文を書いて」
• 「PR の説明文を更新して」「PR の本文を適切な形式に書き直して」
• 「ドラフト PR を作成して」（--draft を追加します）

Apply-review フロー（PR の CI レビューを読み、適用する）— トリガー：

• 「CI レビューには何と書かれていましたか？」
• 「この PR のレビューを読んで」「レビューの指摘事項を見せて」
• 「AI レビューの修正を適用して」「指摘事項を順に説明して」
• 「重大な指摘事項への対応を手伝って」「重大なものだけ」
• 「マージをブロックした指摘事項はどれですか？」
• 「ボットがレビューを投稿しました。対応を手伝ってください」

Address-review フロー（1 回の呼び出しで一連の処理を完了する）— トリガー：

• 「レビューに対応して再実行して」「レビューアーのコメントを解決して、準備完了に切り替えて」
• 「レビューの指摘事項を修正して CI を再実行して」「失敗しているワークフローを修正して」「CI をグリーンにしてレビューアーを再実行して」
• 「レビューをループして」／「レビューのループを実行して」
• 「PR はまだレビューされていません。レビューを実行してください」（コールドスタート — このアームは両方のトリガーモードに対応しています）
• 新しいコンテキストで単独で呼び出された場合 — PR 番号などを指定せず、単に「レビューをループして」とだけ指示された場合 — でも、必要な情報はすべてそろっています。対象は現在のブランチの PR で、レビューがまだ開始されていなければ、ループの一環としてレビューを開始します。直接 address-review にルーティングしてください。

トリガーが曖昧な場合（たとえば、.review/extension.md がまだないリポジトリで開発者が「レビューを手伝って」と言った場合や、PR にレビューが必要で、本文も 1 行しかないリポジトリで「PR を処理して」と言った場合）は、ルーティングする前に確認の質問を 1 つだけしてください。判断に役立つヒューリスティックは次のとおりです。

• リポジトリに .github/workflows/pr-review.yml（または同様のファイル）がすでにある場合 → セットアップフローではない可能性が高いです。
• リポジトリに .github/workflows/pr-review.yml（または同様の名前の AI Diff Reviewer ワークフロー — .github/workflows/ ツリーで DailybotHQ/ai-diff-reviewer または ai-diff-reviewer のアクション参照を grep してください）がなく、.review/extension.md もない状態で、開発者がスキルをインストールしたばかりの場合 → 2 つのフローのどちらを使うか確認してください（「フロー A：ローカルのみ」か「フロー B：デュアルサーフェス」か。「サポート対象の 2 つのフロー」セクションを参照してください）。setup をデフォルトにしてはいけません。フロー A（ローカルのみ）は正式にサポートされるユースケースです。依頼されていないのに setup を実行すると、.github/workflows/pr-review.yml が作成され、開発者が望んでいない可能性のある CI Action がリポジトリに強制的に追加されてしまいます。無関係なワークフロー（CI テスト、デプロイパイプライン、依存関係ボット）が存在していても、フロー B の根拠にはなりません。AI Diff Reviewer ワークフローだけが該当します。
• 開発者がコード変更のセッションを終えたばかりで、まだレビューを依頼していない場合 → デフォルトのレビューのフロー（ローカル）を使用します。
• 現在のブランチに PR がすでにあり、最近の CI 実行による `` コメントが反映されている場合、「レビュー」 という言葉は曖昧です。この場合、「レビューを読んで」 は通常、新たにローカルレビューを実行するのではなく、PR の CI レビューを意味します（apply-review フロー）。一度だけ確認してください。「PR #N に反映されたばかりの CI レビューを読みますか、それとも作業ツリーで新しいローカルレビューを実行しますか？」 — 「レビューをループして」／「レビューに対応して」 はこの曖昧さには当たりません。ループの明示的な意図があれば、確認せずに address-review にルーティングします。
• 開発者がローカルレビューの指摘事項を受け入れ、修正を適用したばかりの場合 → open-pr フローを使う可能性が高いです（自然な次のステップであり、このセッションで最初の PR です）。
• 開発者が CI レビューの修正を適用したばかりの場合 → 編集モードで open-pr を使い（範囲が変わっていれば PR 本文を更新するため）、その後 git commit + git push を実行する可能性が高いです（実際の操作は開発者自身が行います）。 一部のハーネス（Claude Code、Cursor）では、これらをスラッシュコマンド（/ai-diff-reviewer、/ai-diff-reviewer-generate-extension、 /ai-diff-reviewer-setup、/ai-diff-reviewer-open-pr、 /ai-diff-reviewer-apply-review）としても公開しています。ハーネスの スキル呼び出しに関するドキュメントを確認してください。

---

デフォルトのフロー：ローカルレビューの仕組み

以下のすべて（ステップ 0 から 5）は、上の表にある機能 #1のみを説明しています。つまり、現在のブランチでレビューを実行する方法です。 4 つの関連サブスキルには、それぞれ独自の手順があり、各自の SKILL.md ファイルに記載されています。

• generate-extension/SKILL.md — .review/extension.md を作成します
• setup/SKILL.md — GitHub Action をインストールします
• open-pr/SKILL.md — PR のタイトルと本文を作成します
• apply-review/SKILL.md — PR に投稿された CI レビューを読み取り、適用します（v3 以降は成果物が優先されます。review-output/3.0 ドキュメントには指摘事項、検証、反証された指摘事項、以前の台帳が含まれます。スレッドはフォールバックです）

---

専任のオーケストラレビュアー

リードから独立したレビュー担当を割り当てられた場合は、デフォルトのフローの前に orchestra.md を読んでください。別のベンダー／アカウントを ak pick で選ぶ方法、共有ベースチェックアウトで固定されたベース／ヘッド範囲をレビューする方法、herdr-peers を通じて指摘事項を返す方法、リードによるマージゲートについて説明しています。この割り当てによって、このスキルの書き込み範囲が広がることはありません。

---

ステップ 0 — 信頼境界

このスキルは作業ツリーに対してほぼ読み取り専用であり、リモート API を 呼び出しません。以下を行います。

• 現在の git チェックアウトからファイルを読み取ります（Read、Grep、Glob）。
• ローカルで git diff と git log を実行します（push、fetch は行いません）。
• エージェントのコンテキスト内でレビュー用プロンプトを組み立て、レビュー結果を ターミナル出力として生成します。

実行できる書き込みは、ステップ 2.5 で開発者から明示的な同意を得た場合に限り、以下のみです。

• 開発者がブートストラップの提案にはいと答えた場合、.review/ を作成し、.review/extension.md に書き込みます（generate-extension サブスキルを呼び出します）。
• 開発者がブートストラップの提案に今後表示しないと答えた場合、.review/ を作成し、.review/.skip-bootstrap（0 バイト）を作成します。

以下は行いません。

• GitHub にインラインコメントを投稿しません（これは CI アクションの役割です）。
• 作業ツリー内のソースファイル、ワークフロー、設定ファイルを変更しません。
• LLM プロバイダーを直接呼び出しません。すでに実行中のコーディングエージェントを使用します。
• マシン外にデータを送信しません。

コーディングエージェントにさらに広い権限（ファイルの書き込みや任意の bash の実行など）がある場合、それはハーネスによるものであり、このスキルによるものではありません。

---

ステップ 1 — コンテキストを検出する

レビューの入力を確定するため、以下を実行します。JSON を作業コンテキストに出力してください。ユーザーから求められない限り、ユーザーには表示しないでください。

明示的なベース（--base <rev>）。 リクエストでベースリビジョンが指定されている場合（--base <rev>、「<rev> を基準にレビューする」、「<rev> 以降の範囲をレビューする」など）、ブロックを実行する前に REVIEW_BASE をそのリビジョンに設定します。git がコミットとして解決できるリビジョンであれば使用できます。SHA、タグ、ブランチ、HEAD~5 などが該当します。ブランチ名のみを指定した場合はローカルブランチを意味します。リモートブランチを指定するには origin/<branch> を渡してください。git ≥ 2.24（--end-of-options）が必要です。これは追跡対象の upstream より優先されるため、Deep Work Plan Final Review では、ブランチが追跡しているものではなく、プランの範囲（開始コミット）を正確にレビューできます。デフォルトの検出を使用する場合は、REVIEW_BASE を空のままにしてください。

REVIEW_BASE="${REVIEW_BASE:-}"   # from --base <rev>; empty = detect from the upstream

if [ -n "$REVIEW_BASE" ]; then
  # Explicit base: must resolve to a commit — never fall back silently.
  # `--end-of-options` keeps a value starting with `-` from becoming an option;
  # DIFF_BASE is the resolved SHA, so the commands below never see raw input.
  if DIFF_BASE=$(git rev-parse --verify --quiet --end-of-options "${REVIEW_BASE}^{commit}"); then
    BASE_LABEL="$REVIEW_BASE"
  else
    echo "ERROR: --base '${REVIEW_BASE}' does not resolve to a commit in this repository" >&2
    DIFF_BASE=""
  fi
else
  # Base branch: prefer the tracked upstream's short name, fall back to `main`.
  BASE=$(git rev-parse --abbrev-ref --symbolic-full-name '@{u}' 2>/dev/null | sed 's|.*/||')
  BASE="${BASE:-main}"
  DIFF_BASE="origin/${BASE}"
  BASE_LABEL="$BASE"
fi

# Current branch + head SHA
HEAD_BRANCH=$(git branch --show-current)
HEAD_SHA=$(git rev-parse --short HEAD)

# The three artifacts the review needs
if [ -n "$DIFF_BASE" ]; then
  git diff --stat "${DIFF_BASE}...HEAD"    # summary of what changed
  git diff "${DIFF_BASE}...HEAD"           # the actual diff
  git log "${DIFF_BASE}..HEAD" --oneline   # the commit trail
fi
[ -n "$DIFF_BASE" ]   # block exit status: non-zero when --base did not resolve

--base が指定されていて解決できなかった場合は、開発者にエラーを報告して停止します。upstream に置き換えてはいけません。差分が空の場合は、開発者に「<BASE_LABEL> と比較して変更がありません。レビュー対象はありません」と伝えて停止します。デフォルトモードの場合のみ、origin/${BASE} が存在しない（新規クローン、リモートの欠落など）場合は、git merge-base main HEAD にフォールバックし、それと比較して差分を取得します。要約にはフォールバックしたことを記載してください。3 点リーダーの差分はマージベースと比較するため、HEAD の祖先である明示的なベース（プランの開始コミット）を指定すると、そのコミット以降に作成されたコミットだけが対象になります。

---

ステップ 2 — プロンプトを構成する（ベース＋拡張）

レビューの方法論は prompt.md にあります。CI アクションに含まれているものとまったく同じプロンプトです。ベースとしてコンテキストに読み込んでください。

次に、以下の優先順位に従ってリポジトリ固有の拡張を確認してください（一致した最初のものを採用し、残りは無視します）。

1. .review/extension.md（推奨される規約 — ランタイムに依存しません）
2. .github/ai-diff-reviewer/extension.md（ワークフローファイルと同じ階層の .github/ を好むチーム向けのフォールバック。v1.5 より前のスキル名との後方互換性のため、.github/ai-pr-reviewer/extension.md も受け付けます）

一致するファイルが見つかった場合 — それを読み込み、内容を変更せずにベースプロンプトへ追加して、ステップ 3 に進んでください。

一致するファイルが見つからない場合：

• .review/.skip-bootstrap が存在する場合 → 開発者は以前にブートストラップの提案を辞退しています。ベースプロンプトだけを使用し（通知は不要）、ステップ 3 に進んでください。
• それ以外の場合 → ステップ 2.5（初回のブートストラップ提案）に進んでください。

構成した設定を、次のように 1 行で通知します。 Reviewing feat/foo (a1b2c3d) against main. Base prompt + .review/extension.md. （--base の場合は、リビジョン名を指定します。… against 5c1eef0 (--base) …）。

最終的に構成されたプロンプトがレビューの基準となります。重要度の定義、「コメントしてはならない内容」のルール、出力形式が含まれます。

---

ステップ 2.5 — 拡張機能のブートストラップを提案する（初回のみ）

このステップは、ステップ 2 で拡張ファイルも .review/.skip-bootstrap マーカーも見つからなかった場合にのみ実行されます。このスキルが開発者に拡張規約を説明する唯一の機会です。生成した内容またはオプトアウトマーカーのいずれかが記録された後は、開発者がマーカーを削除しない限り、このリポジトリで再び確認することはありません。

開発者に質問を 1 つだけします。

このリポジトリに .review/extension.md が見つかりません。

配布されているデフォルトのプロンプトを使って、今すぐレビューを実行できます。一般的な問題（SQL インジェクション、未処理のプロミス、入力検証の不足、明らかなパフォーマンスの低下など）の約 90％を検出できます。

ただし、このリポジトリ固有の内容は見逃してしまいます。たとえば、金額処理の規約、console.log が禁止されているモジュール、RFC-014 のパターン、このリポジトリのスキーマに紐づく常に重大な SQL パターンです。.review/extension.md を作成すると、このコードベースに基づいた、ファイルを指定した重要度の上書き設定を追加できます。

今すぐブートストラップしますか？（Discovery に約 30 秒、具体的な上書き設定を記載した約 100 行のファイルにかかる時間です。）

• yes — generate-extension サブスキルに処理を引き継ぎ、完了後、新しい拡張を適用してレビューを実行します。
• no — 今回はベースプロンプトだけでレビューを実行します。次回このスキルが有効になったときに、もう一度確認します。
• never — このリポジトリでは今後確認しません。.review/.skip-bootstrap（追跡対象の 0 バイトマーカー）を作成します。チーム全員に同じ設定を適用できるよう、これをコミットしてください。後で提案を再び有効にするには、マーカーを削除します。

回答に応じて処理します。

• yes → 拡張モードで generate-extension サブスキルを実行します（generate-extension/SKILL.md を参照）。サブスキルが .review/extension.md を書き込んだら、ステップ 2 の最初から再開します。新しく書き込まれたファイルが検出され、ベースプロンプトに適用されます。サブスキルの Discovery フェーズ（ツール呼び出し 12 回以上）はスキップしないでください。価値があるのはこのフェーズです。
• no → ベースプロンプトだけでステップ 3 に進みます。何も保存しないでください。次回も提案を表示します。
• never → 次を実行します。

  mkdir -p .review
  touch .review/.skip-bootstrap
  

  その後、ベースプロンプトだけでステップ 3 に進みます。開発者にマーカーのコミットを提案してください：git add .review/.skip-bootstrap && git commit -m "chore(review): opt out of AI Diff Reviewer bootstrap offer"。

開発者の回答が曖昧な場合は、no（変更を最小限に抑える選択肢）をデフォルトにしてください。本人に知らせずにオプトアウトさせてはいけません。

---

ステップ 3 — レビューを実行する

作成したプロンプトを、コーディングエージェント自身のツール（Read、Grep、Glob）を使って差分に適用します。

• プロンプトで read_file／grep／glob を使うよう指示されている場合は、ハーネスが提供するプリミティブに読み替えてください。変更されたファイル全体を読みます。差分だけでは、コンテキストが足りないことがほとんどです。
• プロンプトで post_inline_comment(path, line, body, severity) を使うよう指示されている場合は、GitHub への書き込みアクセスなしでローカル実行しているため、各指摘を {path, line, severity, body} レコードの内部リストに収集し、ステップ 4 で表として出力してください。
• プロンプトで submit_review(summary) をちょうど 1 回実行するよう指示されている場合は、それがレビュー完了の合図です。この時点で最終的な要約を出力し、終了してください。

コスト管理： CI アクションと同じ回数（約 25 回）を上限として実行し、インラインコメント数も同じ上限（デフォルト 20 件）を守ってください。むやみに全体を grep せず、コメントするファイルとそのインポート先を grep してください。

---

ステップ 4 — レビューを出力する

レビューは、CI ボットが PR に投稿するものと同じ形式でターミナルに出力します。これが同等性の契約です。

## Verdict
<one sentence — "Looks good", "Blocking security fix needed", etc.>

## Findings

| # | Severity | File | Summary |
|---|----------|------|---------|
| 1 | 🚨 critical | `src/auth.ts:55` | SQL injection in raw-string login query |
| 2 | ⚠️ warning  | `src/cache.ts:120` | Unbounded cache key cardinality |
| 3 | ℹ️ info     | `tests/utils.ts:12` | Helper could be reused from existing fixture |

### 1. `src/auth.ts:55` — 🚨 critical
<the full finding body — 2-4 sentences + optional ```suggestion block```>

### 2. `src/cache.ts:120` — ⚠️ warning
<...>

### 3. `tests/utils.ts:12` — ℹ️ info
<...>

## Notes (no inline anchor)
- <cross-cutting concerns, architecture, test-strategy comments>

**Recommendation:** approve / request-changes / comment-only

推奨はチェック結果ではありません。 CI では、GitHub チェックはランタイムの厳格性ゲートによって判定されます。モデルが approve を推奨していても、厳格性ゲートが失敗していることがあります。インクリメンタルレビューでは、モデルが修正済みと判断した以前の指摘が、まだ未解決の場合もあります。そのため、v2.3.1 以降の CI レビューは、ランタイムが記述する > **Check status: …** ブロックで終了し、トラッキングコメントの **Strictness gate:** 行が常に正式な判定となります。推奨行だけを根拠にレビューが「合格した」と報告してはいけません。実際の結果の読み方については、apply-review のステップ 2f を参照してください。

この形式（判定 → 指摘事項の表 → 指摘ごとの本文 → 注記 → 推奨）を正確に再現することで、開発者は両方の環境で同じ手法と重大度モデルが使われていると信頼できます。CI の世代におけるラウンド 2 以降では、Iteration-Aware Review により、ローカルで全件を確認した場合には表示される指摘が重複排除されることがあります。この差は想定内であり、同等性の不具合ではありません（上記のCI 専用の動作を参照）。

次のステップのヒント（任意）。 レビューで問題が見つからなかった場合（🚨 重大または ⚠️ 警告の指摘がない場合）、または開発者がプッシュの準備ができたことを明示した場合は、兄弟サブスキルへの案内を 1 行添えて出力を締めくくります。

Next step: want me to open the PR? — I can draft the title + body from
this same diff (see the `open-pr` sub-skill). Or run `gh pr create`
yourself.

レビューでブロッキング問題が見つかった場合は、このヒントを出力しないでください。まず修正し、その後にリリースします。

---

ステップ 5 — 拡張ファイルの規約（利用者向け）

拡張ファイルを用意する方法は 3 通りあり、いずれも有効です。

1. 自動セットアップ — 新しいリポジトリで「review my branch」と伝え、ステップ 2.5 のプロンプトではいと答えます。generate-extension サブスキルが 12 回以上のツール呼び出しを伴う Discovery を実行し、.review/extension.md を作成します。最も簡単な方法であり、初回セットアップにおすすめです。
2. サブスキルを明示的に呼び出す — 「このリポジトリ用に .review/extension.md を生成して」と伝えます（または Activation に記載されている他のトリガーを使います）。(1) と同じ結果になりますが、セットアップ時のプロンプトは省略されます。既存のファイルを再生成または調整する場合に使います。
3. 手動で作成 — 以下のスキーマと例を使って、自分でファイルを作成します。上書きしたい内容が明確で、Discovery の手順が不要な場合に適しています。

どの方法を選んでも、レイアウトの選択肢は同じです。

オプション A — .review/extension.md（推奨）：

my-repo/
├── .review/
│   └── extension.md         ← auto-detected by this skill
└── .github/
    └── workflows/
        └── pr-review.yml    ← CI workflow uses the same file

オプション B — .github/ai-diff-reviewer/extension.md（ワークフローの近くにファイルを置きたい場合の代替）。v1.5 より前のパスである .github/ai-pr-reviewer/extension.md も、後方互換性のため引き続き認識されます。

ローカルと CI の設定を完全に同期させるため、同じファイルを CI ワークフローの prompt-extension-file: 入力から参照してください。

# .github/workflows/pr-review.yml
- uses: DailybotHQ/ai-diff-reviewer@v3
  with:
    api-key: ${{ secrets.ANTHROPIC_API_KEY }}
    github-token: ${{ secrets.GITHUB_TOKEN }}
    prompt-extension-file: .review/extension.md   # same file the skill auto-detects

.review/extension.md の例：

## Severity overrides for our codebase

- Any `SELECT * FROM users` in a request path is **critical** (PII exposure).
- Missing `AbortController` on a `fetch()` in `apps/frontend/` is **warning**
  (React 18 pattern we standardized on in RFC-014).

## Don't comment on

- Formatting in `apps/legacy/*` — that module is scheduled for a rewrite.
- Missing tests in `experiments/` — that folder is intentionally exploratory.

作成ガイド（構成、ヒント、詳しい例）： docs/PROMPTS.md.

---

注意事項

• このスキルはローカルのエージェントを実行します。別の LLM を呼び出すことはありません。 ハーネスに Cursor を使用していて、auto に設定している場合、レビュー費用は Cursor Pro サブスクリプションに請求されます。ハーネスに API キーを使って Claude Code を使用している場合は、Anthropic のトークンが使われます。どちらの場合も、もともとエージェントを使う予定であれば、ローカルレビューは「無料のおまけ」です。
• CI Action（フロー B）と併用する場合、このスキルは CI Action の代わりにはなりません。 CI Action はすべての PR で引き続き実行され、正式なレビュー（インラインコメント、重大度に応じた制御、マージのブロック）を投稿します。このスキルは「プッシュ前」の確認に使います。フロー A（ローカルのみ）では、ローカルスキルがレビューのすべてを担います。CI の処理も、プッシュ後の正式なレビューもありません。指摘事項はターミナルにのみ表示され、PR を作成する前に対応するかどうかを決めるのはユーザーです。
• 拡張機能との同等性はユーザー側で保証されますが、ツールによって強制されるわけではありません。 .review/extension.md の内容が、CI ワークフローの prompt-extension-file: で指定したファイルの内容と異なる場合、差異が生じます。同じパスを指定してください。
• オプトアウトマーカー（.review/.skip-bootstrap）。 スキルに「このリポジトリでは拡張機能のブートストラップをこれ以上提案しないでください。チームはこの選択肢を把握したうえで、ベースプロンプトを使い続けることにしました」と伝える、追跡対象の 0 バイトのマーカーファイルです。ステップ 2.5 のプロンプトで never を選ぶと作成されます。このファイルを削除すると、再び提案が表示されます。チーム全体が同じ操作感を引き継げるように、このファイルをコミットすることを想定しています。
• 不具合、機能リクエスト、スターターテンプレートに追加する拡張機能のパターンについては、こちらをご覧ください。 github.com/DailybotHQ/ai-diff-reviewer/issues。