pr-comments

PR コメント — トリアージと修正

未解決の PR レビュースレッドをすべて取得し、ボット間で重複を排除して、重大度別にトリアージし、人間による承認用の修正計画を作成します。承認後、無視するスレッドを解決し、サブエージェントを起動して実際の問題を修正します。

実行方法

• /pr-comments — 現在のブランチから PR を自動検出します
• /pr-comments 608 — 特定の PR 番号を指定します

フェーズ 1：未解決のスレッドを取得

1a. PR を特定する

# Auto-detect from current branch, or use the provided PR number
gh pr view --json number,headRepositoryOwner,title,headRefName,baseRefName

1b. GraphQL ですべてのレビュースレッドを取得する

スレッドの解決状況を取得するには GraphQL を使用します。これが唯一信頼できる情報源です。

gh api graphql -f query='
{
  repository(owner: "{OWNER}", name: "{REPO_NAME}") {
    pullRequest(number: {PR_NUMBER}) {
      reviewThreads(first: 100) {
        nodes {
          id
          isResolved
          isOutdated
          path
          line
          comments(first: 20) {
            nodes {
              databaseId
              author { login }
              body
              path
              line
              originalLine
              createdAt
              url
            }
          }
        }
      }
    }
  }
}'

hasNextPage が true の場合はページネーションします。すべてのスレッドを収集します。

1c. 未解決のスレッドだけに絞り込む

• isResolved == false のスレッドを残します
• isOutdated を確認します。差分が移動している可能性があるため、該当するスレッドは特に注意して確認します

1d. issue レベルのコメントも取得する（PR の会話タブ）

gh api --paginate "repos/{OWNER}/{REPO_NAME}/issues/{PR_NUMBER}/comments?per_page=100"

人間のレビュアーのみからのコメントに絞り込みます（ボットは除外）。これらは多くの場合、最も重要なコメントです。

フェーズ 2：重複を排除して分類する

複数のボットが、同じファイルや行にある同じ根本的な問題を指摘することはよくあります。まとめてください。

2a. ファイルと行範囲でグループ化する

同じファイル内の 5 行以内を対象とするスレッドは、同じ問題を指摘している可能性が高いです。1 つの論理的な問題にまとめます。

2b. ボットのコメントから重大度を解析する

ボットによって重大度のマーカーは異なります。

ボット	形式	例
coderabbitai[bot]	本文内の絵文字バッジ	🟠 Major、🟡 Minor、🔴 Critical
gemini-code-assist[bot]	SVG 画像の alt テキスト	![medium]、![high]、![low]
chatgpt-codex-connector[bot]	シールドバッジ	P1、P2、P3
devin-ai-integration[bot]	HTML コメントのメタデータ	devin-review-comment の JSON を解析して重大度を取得

すべてを共通の尺度に対応付けます：Critical > Major > Medium > Minor > Nitpick

複数のボットが同じ問題を異なる重大度で指摘した場合は、最も高い重大度を採用します。

2c. 各問題を分類する

重複排除した各問題について、以下を判断します。

1. カテゴリ：security | bug | correctness | performance | accessibility | style | config | docs
2. 重大度：Critical / Major / Medium / Minor / Nitpick
3. 確信度：誤検知ではなく、実際の問題である可能性はどの程度か
   • 人間のレビュアーによるコメント → 常に確信度が高い
   • 複数のボットが同じ内容を指摘 → 確信度が高い
   • コードベースのパターンに関する文脈がない単一のボット → 確信度が低い
   • ボットが SKILL.md または設定ファイルを指摘 → 多くの場合、ノイズ

2d. 無視する候補を特定する

以下のいずれかに該当する場合は、無視候補としてフラグを付けます。

• セキュリティ上の影響がない、ソースファイル以外（.md、設定、マイグレーション）へのボットコメント
• プロジェクトの規約（AGENTS.md を確認）に反する、スタイルや細かな指摘レベルのフィードバック
• 意図的にそのように設計された内容へのボットの指摘（git blame / PR の説明を確認）
• isOutdated == true の古いスレッドで、コードがすでに変更されているもの
• 対応中の別の問題と重複するもの
• 読み込まれたスキルまたは AGENTS.md の規約に反するパターンをボットが提案しているもの

フェーズ 3：修正計画を作成する

計画を .claude/scratchpad/pr-{PR_NUMBER}-review-plan.md に書き込みます。

計画の形式

# PR #{PR_NUMBER} Review Plan — "{PR_TITLE}"

**Branch:** {branch_name}
**PR URL:** {pr_url}
**Threads fetched:** {total} total, {unresolved} unresolved, {outdated} outdated
**Bot breakdown:** {count per bot}

---

## Issues to Fix (ordered by severity)

Only include issues that will actually be fixed. Items classified as ignored in Phase 2 go EXCLUSIVELY in the Ignored section below — never list them here.

### 1. [{SEVERITY}] {Short description of the issue}

- **File:** `path/to/file.ts#L{line}`
- **Category:** {category}
- **Flagged by:** @bot1, @bot2
- **Comment URL:** {url to first comment}
- **What's wrong:** {1-2 sentence explanation in plain english}
- **Suggested fix:** {concrete description of what to change}

> Original comment (from @bot1):
> {relevant excerpt — strip boilerplate/badges}

---

### 2. [{SEVERITY}] ...

---

## Ignored (with reasoning)

Each ignored item appears ONLY here — not duplicated in the Issues to Fix section above.

### I1. @{bot} on `path/to/file.ts#L{line}`

- **Why ignored:** {specific reason — e.g., "contradicts project convention in AGENTS.md to not use explicit return types", "outdated thread, code already changed", "style nitpick on a config file"}
- **Original comment:** {link to comment}

### I2. ...

---

## Summary

- **{N} issues to fix** across {M} files
- **{K} comments ignored** ({reasons breakdown})
- Estimated complexity: {low/medium/high}

ユーザーに提示する

計画を書き込んだ後、ユーザーに次のように伝えます。

レビュープランを .claude/scratchpad/pr-{PR_NUMBER}-review-plan.md に書き込みました。 修正する問題は {N} 件、無視する問題は {K} 件です。続行するには、内容を確認して承認してください。

ここで停止してください。 ユーザーが内容を確認して承認するまで待ちます。承認されるまで先に進んではいけません。

フェーズ 4：実行（人間の承認後）

ユーザーが承認したら（先に計画を編集する場合があります。実行前に計画を読み直してください）：

4a. 無視したスレッドを解決する

無視した各課題について、理由を簡潔に説明するコメントを付けて GitHub のスレッドを解決してください。

# Post a reply comment on the thread
gh api -X POST "repos/{OWNER}/{REPO_NAME}/pulls/{PR_NUMBER}/comments" \
  -f body="Acknowledged — {reason}. Resolving." \
  -F in_reply_to={COMMENT_DATABASE_ID}

# Resolve the thread via GraphQL
gh api graphql -f query='
mutation {
  resolveReviewThread(input: { threadId: "{THREAD_NODE_ID}" }) {
    thread { isResolved }
  }
}'

簡潔で具体的な却下理由を使用してください。例：

• "確認しました — プロジェクトの規約では、戻り値の型を明示しません（AGENTS.md を参照）。解決します。"
• "確認しました — 古いスレッドで、コードはリファクタリング済みです。解決します。"
• "確認しました — これは意図した動作です。sessionStorage にアクセスするのはクライアント側だけです。解決します。"

4b. サブエージェントで実際の問題を修正する

同じファイルまたは論理単位に関係する課題をまとめます。その後、Task ツールを使用して、ファイルまたは論理グループごとに 1 つの並列サブエージェントを起動します。

Launch a Task subagent (subagent_type: "general-purpose") for each group:

Prompt template:
"Fix the following PR review issue(s) on branch {BRANCH}:

Issue: {description}
File: {path}#{line}
What's wrong: {explanation}
Suggested fix: {fix description}

Read the file, understand the surrounding context, and make the fix.
After fixing, verify the change is correct.
Do NOT touch unrelated code."

• 各グループに subagent_type: "general-purpose" を使用します
• 対象ファイルが異なるグループは並列で起動します
• 同じファイルに関係する場合は順番に実行します

4c. すべてのサブエージェントが完了した後

1. GitHub で修正済みのスレッドを解決します（4a と同じ GraphQL mutation を使用し、"Fixed in latest push." のようなコメントを付けます）
2. 結果をユーザーに報告します

既知のボットノイズのパターン

以下はほとんどの場合、無視できます。ただし、却下する前に確認してください。

1. SKILL.md / AGENTS.md ファイルに対する coderabbit の指摘 — Markdown の構造に関するもので、無関係です
2. 明示的な戻り値の型を提案する gemini — 採用する前に、プロジェクトの AGENTS.md または lint 設定を確認してください
3. devin の HTML コメントメタデータ — coderabbit がすでに指摘した内容と重複していることがよくあります
4. codex の P3 スタイルに関する提案 — 通常は好みの問題で、バグではありません
5. as キャストや非 null アサーションを提案するボット — 採用する前に、プロジェクトの規約を確認してください
6. vercel[bot] のデプロイに関するコメント — 完全なノイズで、対応が必要になることはありません
7. マイグレーションファイルに関するボットのコメント — ほとんどの場合、誤検知です（自動生成コード）