pr-review

PR レビュー — 適応型オーケストレーションプロトコル

6 つの専門サブエージェント（Task ツール経由）を連携させ、その結果を 1 つの要約にまとめます。このスキルはスタックに依存しません。独自のルールは持ちません。代わりに、テストランナー、要件仕様、アーキテクチャの規約、プロジェクト固有のレビュー用スキルなど、プロジェクトですでに文書化されている内容を見つけ、各サブエージェントがそのプロジェクトに実際にあるものを読み込んで適用します。スタック固有のルールを作り出したり、プロジェクトのドキュメントを重複させたりすることはありません。

実行契約（必須）

このスキルはオーケストレーション専用のプロトコルです。ほかのことをする前に、以下のルールを読んでください。

1. あなたはオーケストレーターです。差分を分析したり、ソースファイルを読んだり、レビューの指摘を自分で書いたりしてはなりません。あなたの仕事は、コンテキストの収集（ステップ 1）、サブエージェントの起動（ステップ 2）、統合サブエージェントの起動（ステップ 3）だけです。
2. 6 件のレビューは、汎用サブエージェント 6 つ（ツールセットに制限なし）としてそれぞれ別々に、1 回のバッチで並列に実行する必要があります。利用可能なサブエージェント／並列タスクの仕組みを使ってください（Claude Code では Task ツールを使います）。
3. レビューをインラインで行うことは、部分的であっても、「時間を節約するため」であっても、差分が小さくても、このスキルの失敗です。差分のサイズによる例外はありません。
4. 各サブエージェントへのプロンプトは、それだけで完結している必要があります。{REPO}、{PR}、{SHA}、差分、PR の意図、既存のコメント位置、DISCOVERY MAP を渡してください。サブエージェントはあなたのコンテキストを共有しません。

ホストの前提条件： gh CLI を使って GitHub のプルリクエストを操作します。以下の取得と投稿はすべて gh を使います。「スタックに依存しない」とは、言語やフレームワークに依存しないという意味であり、ホストに依存しないという意味ではありません。GitLab／Bitbucket がホストするリポジトリ（PR ではなく MR を使用するもの）は対象外です。

明示的な呼び出しのみ（disable-model-invocation: true）。コーディング中に自動で起動してはなりません。

ステップ 1：初期化

1a. PR のコンテキスト

1. ユーザーの依頼から PR 番号を特定します。指定されていない場合は確認してください。
2. リポジトリを特定します：gh repo view --json nameWithOwner -q .nameWithOwner → {REPO}。
3. 差分を取得します：gh pr diff {PR}。ヘッド SHA を取得します：gh pr view {PR} --json headRefOid -q .headRefOid → {SHA}（インラインコメントの位置を固定するために必要です）。
4. 既存のインラインコメントを読み込みます：gh api repos/{REPO}/pulls/{PR}/comments — {id, path, line} レコードのセットを作成します。再投稿を避けるために {path, line} を使い、解決済みの問題を検出できるよう各コメントの本文を保持し、スレッドへの返信に使うため各 id も保持します。
5. PR の意図を読み込みます：gh pr view {PR} --json title,body,headRefName。

1b. プロジェクトの調査（適応型の骨格）

リポジトリを一度調査し、すべてのサブエージェントにそのまま渡すプロジェクトプロファイル（以下のDISCOVERY MAP）を記録します。ここには十分な手間をかけてください。レビューをこのプロジェクトに適合させるうえで重要です。**推測よりも、プロジェクトが明示している根拠を優先してください。**存在するものだけを検出し、存在しないものは none と記録します。

• テストランナーと構成 — CIが実際に実行するコマンドを特定します。次の順で確認してください。まずCIワークフロー（.github/workflows/*、またはリポジトリで使用しているCI設定ファイル。例：.gitlab-ci.yml。実際のテストコマンドの特定に限って読み取ります）を正式な根拠とし、次にマニフェスト（package.json のスクリプト、pyproject.toml／tox.ini／pytest.ini、go.mod、Cargo.toml、Gemfile、Makefile、*.gradle）を確認します。既存のテストからテストファイルのグロブ（例：*.spec.ts、*_test.go、test_*.py、*_spec.rb）を割り出し、リポジトリで使用している単体テストと統合テスト／E2Eテストの区分も記録してください。
• 要件の参照元 — (A) ブランチ名またはPR本文にある課題管理ツールのキー（例：Jira／Linearの [A-Z]+-\d+、GitHub issueの #\d+ または owner/repo#\d+、チケットの完全なURL）。(B) リポジトリ内の仕様／要件ファイル：.specs/ ツリー、docs/、*-spec.md、*-tasks.md、PRDファイル、ADR／RFCディレクトリ。
• アーキテクチャ／規約のドキュメント — プロジェクトのルールを記載したもの：CONTRIBUTING*、ARCHITECTURE*、CONVENTIONS*、docs/** 内の規約ファイル、AGENTS.md、CLAUDE.md、およびリポジトリ内にあるコーディング／統合／セキュリティパターンのドキュメント。パスを記録してください。まだ中身は読まないでください。担当するサブエージェントが読みます。
• プロジェクト固有のレビュースキル — スキルのディレクトリ（.claude/skills/、.cursor/skills/、.codex/skills/、.github/）を調べ、テスト、アーキテクチャ／モジュール性、またはセキュリティを対象とするスキルを探します。サブエージェントが推測ではなくプロジェクト独自の資料を参照できるよう、各 SKILL.md のパスを記録してください。

マップを簡潔に記録し、すべてのサブエージェントにそのまま渡します。

TEST:          <command> | globs: <...> | unit vs e2e: <split | none> | none-found
REQS:          tracker=<Jira KEY-123 | GH #42 | Linear ABC-7 | none> ; specs=<paths | none>
CONVENTIONS:   <doc/skill paths that state rules | none-found>
REVIEW_SKILLS: <project-local test/arch skill paths | none>

各サブエージェントは、マップに記載されたものだけを読み込みます。カテゴリが none の場合は、そのセクションの汎用チェックリストを使い、その旨を伝えます。

ステップ2：サブエージェントを並列で起動する

Taskツール呼び出しを6件含むメッセージを1つ送り、同時に起動します。各サブエージェントは独立しており、このチャットの内容を参照できません。そのため、各プロンプトには {REPO}、{PR}、{SHA}、差分、既存の {id,path,line} コメント一覧、PRの意図、および**プロジェクトプロファイル（上記のDISCOVERY MAP）**を含めてください。6件すべての完了後、ステップ3を実行します。

---

重要度ラベル（すべてのサブエージェントが使用）

• 🚨 Critical — 障害を引き起こすバグまたはロジックエラー
• 🔒 Security — 脆弱性またはデータ漏えい
• ⚡ Performance — 重大なパフォーマンス上の懸念
• ⚠️ Warning — コードの問題または保守性の懸念
• 💡 Suggestion — 任意の改善案

---

共通ルール（すべてのサブエージェントと統合担当者が従うこと）

1. 投稿方法 — 壊れた本文は絶対に投稿しないでください。 複数行のコメントや要約は、本文を一時ファイルに書き込み、--body-file または -F body=@file を使って投稿してください。正確なコマンドは以下を参照してください。最もよくある失敗の原因です。正しく実行してください。
2. コメントの許可対象： インラインコメントは、+ で始まる差分行にのみ投稿してください（+++ は対象外です）。根拠となる正確な + 行にコメントを紐付けてください。
3. 重複を避ける： {path, line} の位置から±3行以内にコメントがすでにある場合は、スキップしてください。
4. 解決済みとマーク： 差分によって問題が修正された既存コメントには、[RESOLVED] This appears resolved by the recent changes. と返信してください。以下の返信エンドポイントを使って、そのコメントスレッドに投稿してください。Step 1a.4 のコメントの id を使用します。
5. 確信度の基準： 確信度が80%以上の場合にのみ指摘を報告してください。不確かな場合は、コメントしないでください。
6. 良い点を挙げる： 各サブエージェントは、問題を列挙する前に、適切にできている点を少なくとも1つ取り上げてください。
7. コメントのみ、変更は絶対にしない： --approve と --request-changes は使用せず、ファイルも変更しないでください。--comment のみ使用してください。
8. 帰属を示さない： コメント本文では、AI、アシスタント、モデル、ツールに言及しないでください。レビュアーとして記述してください。
9. マーカー： すべてのインラインコメント本文の先頭に `` を付けてください（表示上は見えません。統合手順で解析されます）。{type} は security | requirements | tests | architecture | regression | performance のいずれかです。
10. トーン： 具体的で、対応方法が明確で、協力的な表現にしてください。必ず理由を説明してください。

コメント投稿コマンド（そのままコピーしてください）

まず本文を一時ファイル（例：body.md）に書き込んでから、次のコマンドを実行します。

追加された行へのインラインレビューコメント：

gh api repos/{REPO}/pulls/{PR}/comments \
  -F [email protected] -f commit_id={SHA} -f path={path} -F line={N} -f side=RIGHT

line={N} は、ヘッドファイルの RIGHT 側における1始まりの行番号です。ハンクヘッダーの +c 開始位置から、追加行とコンテキスト行を数えます。差分内の相対位置ではありません。差分相対の位置を指定すると、422エラーが返るか、誤った行にコメントが付きます。

既存のコメントスレッドへの返信（ルール4の [RESOLVED] 用）。Step 1a.4 の {COMMENT_ID} を使用します。

gh api repos/{REPO}/pulls/{PR}/comments/{COMMENT_ID}/replies -F [email protected]

PRレベルの要約（要件サブエージェントと統合担当者用）：

gh pr review {PR} --comment --body-file body.md

-F／--field は @file をファイルの内容に展開し、数値を数値型として扱います。-f／--raw-field は展開しません — -f [email protected] を使うと、コメントの代わりに文字列 @body.md がそのまま投稿されます。そのため、本文には -F body=@file、行番号には -F line=N、文字列フィールド（commit_id、path、side）には -f を使ってください。-f body=@file は絶対に使わないでください。本文を指定する際に迷った場合は、--body-file を優先してください。

---

サブエージェント1：セキュリティ — ``

プロファイルにセキュリティ／統合規約のドキュメントや、セキュリティに特化したプロジェクトスキル（CONVENTIONS／REVIEW_SKILLS から取得）が記載されている場合は、それらを読み込み、まずそのルールに照らして差分をレビューしてください。その後、いずれの場合も以下の一般的な確認を行ってください：ハードコードされたシークレットや認証情報、新しいエンドポイントにおける認証／認可の欠如、ログ内の個人情報やシークレット、Webhook／コールバックの署名検証の欠如、過度に許容的なCORS、クエリ／コマンド／テンプレートに到達する未サニタイズの入力（インジェクション）、安全でないデシリアライズ、ユーザー所有リソースに対するアクセス制御の不備、レスポンスペイロードへの機密フィールドの漏えい、モジュール境界を越えて公開される内部クライアント／キー。

必須の第2パス： 差分全体を最初から最後まで読み直してください。コメントしなかったファイルまたはハンクをすべて列挙してください。それぞれについて、「担当範囲のセキュリティルールに違反していないか？」と確認してください。問題がない理由を明確に説明できる場合にのみ、そのファイルをスキップしてください。

コメント形式：

🔒 Security — [Short title]
[What the issue is and why it matters]
**Recommendation:** [Specific fix]

---

サブエージェント2：要件と完了の定義 — ``

PRレベルの要約コメントを1件だけ投稿してください。インラインコメントは禁止です。

プロファイルの REQS から、2つの方法で要件を調べてください。両方を実行し、内容が得られた方法を使用してください。

トラック A — 課題トラッカー

ブランチ名または PR の本文からチケット／課題の参照を抽出し、環境で利用できる方法で取得します。利用中のトラッカーに合わせてください。

• GitHub の課題 #N → gh issue view {N} --json title,body（または owner/repo#N 形式）。
• Jira の KEY-123 → プロジェクトで設定されている Jira CLI または Atlassian MCP（課題の概要 + 説明 + 受け入れ条件）。環境ですでに設定されているホスト／認証情報のみを使用してください。Jira のホストを推測したり、ハードコードしたりしないでください。
• Linear / その他 → プロジェクトのドキュメントに記載されている方法。

受け入れ条件、ユーザーストーリー、DoD 項目を解析します。参照情報や認証情報がない場合は、トラック A をスキップしてトラック B に進みます。

トラック B — リポジトリ内の仕様ファイル

PR のタイトル／本文から、参照されている仕様／タスクファイル（明示的なパス、Markdown リンク、spec:／tasks: の記載）を確認します。また、プロファイルに記載された .specs/、docs/、ADR/RFC ディレクトリも調べ、ブランチ、チケット、機能名に一致するファイル（ファイル名のベース部分によるあいまい検索）を探します。候補となる各ファイルを読み、受け入れ条件、タスクのチェックリスト項目、明記された目標／対象外事項を抽出します。ADR/RFC の「Decision」および「Consequences」セクションも要件として扱います。

解決ロジック

内容があるトラック	アクション
A と B の両方	要件を統合し、各項目の出典を記載する
A のみ	トラッカーの要件を使用する
B のみ	仕様ファイルの要件を使用する
どちらもなし	⚠️ No issue ticket or spec file found — requirements verification skipped. を投稿して終了する

ケースごとに、証拠に基づいて評価してください。 各要件について、実装コードを特定し、✅ 実装済み（path:line を引用）、🟡 一部実装（重要な節が欠けている）、または ❌ 未実装とします。証拠を特定できない場合は未実装です。PR の説明で意図が繰り返されているだけのものに、決して実装済みの評価を与えないでください。テストで動作が 実行されている だけで、アサーションされていない場合は、検証済みとはみなしません。

2 回目の確認（必須）： 統合した要件リストを一項目ずつ読み直し、「この項目を差分に照らして評価したか？」と確認します。未評価の項目があれば、実際の差分に基づいてすべて ✅／🟡／❌ で評価します。

要約の形式：

## 📋 Requirements Review
**Sources:** {e.g. "Jira: KEY-123" | "Spec: .specs/<feature>/spec.md" | "Both" | "None"}
### ✅ Implemented   — [criterion — `path:line`]
### 🟡 Partial       — [criterion — what's missing]
### ❌ Missing        — [criterion]
### 🔲 Definition of Done   — [x] covered / [ ] not covered
### 💬 Notes

---

サブエージェント 3：テストカバレッジ — ``

プロファイルの TEST ランナーとレイアウトを使い、テストを配置すべき場所と、このプロジェクトで「適切なテスト」がどのようなものかを把握します。REVIEW_SKILLS にプロジェクト固有のテストスキルが記載されている場合は、必ず読み込み、配置、命名、セットアップ／ティアダウン、アサーションのスタイルの参考にしてください。それ以外の場合は一般的な基準を適用します。プロジェクトで使用していないフレームワークを押し付けないでください。

差分を確認し、以下を特定します。対応するテストがない新規または変更された動作（公開／エントリーポイントの動作 — 新規エンドポイント、ハンドラー、エクスポートされた関数、イベント／キューのコンシューマー、ジョブ — では 🚨 重大）。必要なテストレベルが誤っているもの（純粋なロジックにはユニットテストが必要、観測可能な I/O — HTTP／永続化／キュー — には統合テスト／E2E テストが必要、両方を含む動作には両方が必要）。品質上の不足（プロジェクトのレイアウトに合わない配置、クリーンアップ／ティアダウンの欠落、フィクスチャ／ファクトリーの不在、ID のハードコード、負のケース／エラーケースの欠落、動作を実行するだけで結果をアサーションしていないテスト）。

2 回目の確認（必須）： 差分全体を読み直します。コメントしていない新規／変更エントリーポイント（エンドポイント、エクスポートされた関数、ハンドラー、コンシューマー）をすべて列挙します。それぞれについて、「正常系と少なくとも 1 つのエラーケースを、適切なレベルでカバーするテストがあるか？」と確認します。すでにカバレッジが存在する理由、または対象外である理由を説明できる場合に限り、スキップします。

コメント形式：

[🚨/⚠️/💡] — [Short title]
[The coverage gap or test anti-pattern]
**Recommendation:** [Test to add, at which level, following project patterns]

---

サブエージェント 4：アーキテクチャと規約 — ``

フェーズ 0 — プロジェクト独自の規約ドキュメントを読み込む

プロファイルに記載されたすべてのアーキテクチャ／規約ドキュメントと、プロジェクト固有のアーキテクチャスキル（CONVENTIONS ＋ REVIEW_SKILLS）を、末尾まで読み込んでください。省略したり、プロジェクトの文書化されたルールを一般的な技術知識で置き換えたりしないでください。プロファイルに何も記載されていない場合は、最小限の一般的な調査に切り替えてください（モジュールの境界を尊重し、レイヤー違反を避け、循環依存や境界を越えたインポートを避け、近接するコードと命名を一貫させます）。その場合は、各コメントにプロジェクトの規約ドキュメントが見つからなかったことを明記してください。

フェーズ 1 — ルール一覧を抽出する（ハードコードしない）

読み込んだ各ドキュメントを確認し、そこに明記されているすべてのルール（チェックリスト項目（□／- [ ]）、✅ 推奨／❌ 禁止の箇条書き、「必須」「決して〜しない」という記述、構造上の制約）を1つの番号付きリストに抽出してください。1から順に番号を付けてください。ドキュメントに記載されていない内容は追加せず、見つけた内容は省略しないでください。この番号付きリストが、プロジェクト独自のドキュメントから導き出した評価基準です。

フェーズ 2 — ファイルごとに評価する

変更された各ファイルについて、ルールごとに PASS / VIOLATION / N/A を判定してください。N/A が有効なのは、そのファイル形式に構造上適用されないルールに限ります。各 VIOLATION について、該当する + 行に、ルール番号と出典ドキュメントを示すインラインコメントを付けてください。

2回目のパス（必須）： 評価基準に沿った確認の後、差分全体を再度読み返してください。評価していないファイルをすべて列挙し、それらにも評価基準を適用してください。ルールが N/A であることと、その理由を明記した場合にのみ、そのファイルをスキップできます。

コメント形式：

[🚨/⚠️/💡] — [Short title]
Rule: [number + source doc, e.g. "Rule 8 — CONTRIBUTING.md Module Boundaries"]
[What in the diff violates it — quote the offending line]
**Recommendation:** [Exact fix; code snippet if < 6 lines]

---

サブエージェント 5：回帰とハルシネーションの検出 — ``

差分を確認し、PR の目的と無関係な変更や、機械生成の成果物と思われる兆候を調べてください。対象には、変更と無関係なコードの削除（🚨）、リポジトリに存在しないシンボルのインポート／参照（🚨）、誤ったシグネチャや引数の数での呼び出し（🚨）、本番パスに残された TODO／FIXME／スタブ、実際の型エラーを隠す型アサーションやキャスト、コードベースにすでにある処理と重複するロジック、弱められたエラー処理や検証、黙って握りつぶされるエラー、弱められた、または削除されたテストアサーション、実行されないデッドコードが含まれます。

2回目のパス（必須）： 差分全体を再度読み返してください。コメントを付けなかったファイルをすべて列挙し、次の点を確認してください。「無関係な削除、存在しない参照、重複ロジック、または弱められたアサーションはありませんか？」該当しない理由を述べられる場合に限り、スキップできます。

コメント形式：

[🚨/⚠️/💡] — [Short title]
Type: [unrelated-deletion | phantom-reference | wrong-signature | duplicate | weakened-check | dead-code]
[Specific description with quoted evidence from the diff]
**Recommendation:** [Exact fix]

---

サブエージェント 6：パフォーマンス — ``

プロファイルにデータアクセスやパフォーマンスの規約ドキュメントが記載されている場合は、プロジェクトで想定されるパターンの参考資料として読み込んでください。差分から明確に確認できる問題だけを指摘してください。推測はしないでください。次の点を確認してください。ループ内のクエリ／検索（N+1）、ページネーションや上限のない無制限の取得、行ごとの I/O を発生させる遅延ロードされたリレーション、並行実行可能な独立した処理に対する逐次的な await／ブロッキング呼び出し、ループ内で繰り返し計算される不変の値、同一のトランザクション／バッチにまとめるべき複数回の書き込み。

2回目のパス（必須）： 差分全体を再度読み返してください。コメントを付けなかった関数、クエリ、ループをすべて列挙し、次の点を確認してください。「ここに差分から明確に確認できるパフォーマンス上の問題はありませんか？」該当しない理由を述べられる場合に限り、スキップできます。

コメント形式：

⚡ Performance — [Short title]
[Description with estimated impact, e.g. "O(N) queries per request"]
**Recommendation:** [Fix with short code sketch if < 6 lines]

ステップ 3：集約

6 つのサブエージェントがすべて完了したら、集約するためにもう 1 つ Task サブエージェントを起動します。

1. gh api repos/{REPO}/pulls/{PR}/comments — すべてのインラインコメントを取得します。
2. 本文が `` summary: で始まるものを対象にします。Requirements サブエージェントは gh pr review --comment を使って投稿するため、これは レビュー 本文です。インラインの /pulls/{PR}/comments エントリー（ステップ 3.1）でも、/issues/{PR}/comments エントリーでもありません。マーカーを含むレビューを対象にします。
3. 指摘を重大度別に分類します：🔒 セキュリティ → 🚨 クリティカル → ⚡ パフォーマンス → ⚠️ 警告 → 💡 提案。
4. 同じ {path, line}（±3 行）の指摘を重複排除し、各エントリーに寄与したすべてのサブエージェントを記載します。
5. 各サブエージェントから肯定的なハイライトを 1 つずつ集めます。
6. ギャップ検出： gh pr diff {PR} --name-only を実行し、変更されたファイルの一覧全体を取得します。すべてのパスを、インラインコメントを受け取ったパスと照合します。インラインコメントが 0 件 の変更されたロジックファイルは、### 🔍 Files With No Inline Comments の下に列挙します。設定ファイル／ロックファイル（*.json、*.yaml、*.lock）と、ロジックを含まない純粋な型／宣言ファイルのみ省略します。
7. サマリーを一時ファイルに書き込み、gh pr review {PR} --comment --body-file summary.md で投稿します。

サマリー形式：

## 📋 PR Review Summary

| | |
|---|---|
| **Subagents** | 6 (Security · Requirements & DoD · Test Coverage · Architecture · Regression · Performance) |
| **Detected runner** | {TEST command, from the map — or "none found"} |
| **Requirements source** | {tracker / spec path / none} |
| **Project refs loaded** | {convention docs + project-local skills used, from the profile} |
| **Findings** | {N} across {M} files |

---
### 🔒 Security ({N})
- [`path/file:L42`] Finding title
### 🚨 Critical ({N})
### ⚡ Performance ({N})
### ⚠️ Warnings ({N})
### 💡 Suggestions ({N})

---
### 🔍 Files With No Inline Comments
- `path/to/file` — no findings from any subagent (verify manually or re-run a targeted review)

_(Omit this section if every logic file received at least one comment.)_

---
### ✅ Highlights
- [One positive highlight per subagent]

---
> See inline comments for details and recommendations.

すべてのサブエージェントで指摘がなかった場合は、✅ No issues found across all review dimensions. を投稿し、メタデータテーブルも必ず含めます。

---

例

A — Requirements はリポジトリの状況に応じて動作します。 ブランチ名が feat/PLAT-482-trial のリポジトリでは、Track A が PLAT-482 を抽出し、プロジェクトで設定された Jira CLI/MCP を使ってその課題を取得して、差分に対する受け入れ基準を評価します → Sources: Jira: PLAT-482。課題管理ツールがない別のリポジトリで、PR 本文から .specs/checkout/spec.md にリンクされている場合、Track B はその仕様を読み込み、要件 ID を評価します。さらに別のリポジトリで、課題管理ツールも仕様もないものの、PR から docs/adr/0007-rate-limits.md が参照されている場合、Track B は ADR の Decision／Consequences を基準として扱います。これらがどれも存在しない 4 つ目のリポジトリでは、スキップ行を投稿して終了します。同じサブエージェントでも、プロジェクトプロファイルによって 4 通りの結果になります。

B — Architecture は独自のマトリクスを抽出します。 リポジトリ X では、規約が CONTRIBUTING.md に記載されています。フェーズ 1 で「必須／禁止」の箇条書きからルール 1～12 を作成し、差分をそれらに照らして評価します。リポジトリ Y には、プロジェクト内の .cursor/skills/modular-architecture/SKILL.md があります。サブエージェントはこれを読み込み、そのスキルのチェックリストをマトリクスとして抽出します。リポジトリ Z に規約文書がない場合、サブエージェントはその旨を伝え、最小限の一般的な境界チェックのみを実行します。スタックのルールがハードコードされることはありません。

C — -F と -f による投稿の修正：正しい例と誤った例。

# ✅ posts the file's contents (uppercase -F expands @)
gh api repos/acme/app/pulls/12/comments \
  -F [email protected] -f commit_id={SHA} -f path=src/x -F line=88 -f side=RIGHT
# ❌ posts the literal string "@body.md" (lowercase -f does NOT expand @)
gh api repos/acme/app/pulls/12/comments -f [email protected] -f path=src/x ...

PR レベルのサマリーには、常に gh pr review 12 --comment --body-file summary.md を使用してください。インラインの複数行 --body は使用しないでください。