respond-to-pr-comments-in-blocklist

Name: respond-to-pr-comments-in-blocklist
Author: warpdotdev

github.com/warpdotdev開発63625.1k 回インストール1 週間前に更新

respond-to-pr-comments-in-blocklist について

respond-to-pr-comments-in-blocklist は、現在の PR ブランチにある対応が必要なコメントを扱うスキルです。コメントごとに判断を促し、依頼された変更を適用・検証したうえで、承認後に返信やスレッド解決を行います。

主な機能

01対応が必要なコメントの選別
02コメントごとの判断支援
03依頼されたコード変更の適用
04返信前の変更検証
05承認後の返信・スレッド解決

活用シーン

01PR レビューコメントへの対応
02判断前にコメントの意味を確認
03コード修正後の返信準備
04レビュースレッドを解決するか判断

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist

インストール後、Claude Code で/respond-to-pr-comments-in-blocklistを入力して読み込まれたか確認します。

詳細

ブロックリスト内の PR コメントへの返信

このスキルは、現在のブランチに関する PR コメントに返信するために使用します。コメントがすでに会話内に表示されている場合（通常は組み込みの /pr-comments スキルによって表示されています）は、そのコンテキストから続行してください。コメントがまだ表示されていない場合は、まずコメントを取得して表示してから、対応が必要なコメントを一つずつユーザーと確認し、明示的な判断を集め、依頼されたコード変更を行います。その後で初めて、GitHub への返信投稿やレビュースレッドの解決について承認を求めてください。

このスキルを使用しない場合

ユーザーが PR コメントの取得または表示のみを希望している場合（代わりに pr-comments を使用してください）、あるいは GitHub への返信投稿やスレッド解決を行わず、関連するコード変更のみを希望している場合は、このスキルを使用しないでください。返信の投稿またはスレッドの解決を希望することをユーザーが確認してから、このスキルを読み込んでください。

前提条件

PR ブランチのリポジトリのチェックアウト内で作業してください。
コメント本文、作成者、URL、パス、行のメタデータなどの必須フィールドが読み込まれたコンテキストに不足していない限り、コメントを再取得しないでください。
ユーザーが最終プレビューを承認するまで、GitHub への返信投稿、レビューの送信、スレッドの解決を行わないでください。

コンテキストに PR コメントがない場合は、続行する前に取得して表示してください。利用可能な場合は、組み込みの /pr-comments ワークフローを優先して呼び出してください。そうでない場合は、同等の GitHub CLI を使用して現在の PR を特定し、PR レベルのコメント、レビューコメント、レビュー本文を取得してから、insert_code_review_comments を使って表示してください。取得したコメントを表示した後、変更を行う前に、この返信ワークフローを続行するかどうかユーザーに尋ねてください。

コメントのフィルタリング

返信方法を尋ねる前に、読み込まれたコメントを、まだユーザーの対応が必要なコメントに絞り込んでください。

次のコメントは、ユーザーに尋ねずにスキップしてください。

Warp／Oz／code-review ボットによる自動生成の PR レベルの概要またはステータスコメント。特に、ファイル位置が添付されておらず、レビュー状況やチェックの進捗を要約しているもの、またはコード変更は不要と述べているもの。
現在の GitHub ユーザーがすでに返信しているコメント。

現在の GitHub ユーザーを特定するには、次を優先してください。

GH_PAGER="" gh api user --jq .login

レビュースレッドについては、利用可能な場合、読み込まれたコンテキストの reply_metadata.parent_comment_id、スレッドのメタデータ、解決状態、コメントの順序を使用してください。スレッドがすでに解決済みの場合、またはそのスレッド内の最新の関連返信が現在のユーザーによるものの場合に限り、元のコメントとスレッドをスキップしてください。現在のユーザーの返信後にレビュー担当者が新しいフォローアップを追加している場合は、そのスレッドを確認対象に残してください。明示的なスレッドメタデータのない PR レベルのコメントについては、直接の返信、引用、リンク、またはそのコメントに言及した直後の返信など、読み込まれたコンテキストから現在のユーザーがその特定のコメントに返信したことが明確に分かる場合に限り、スキップしてください。

自動生成のコメントまたはすでに回答済みのコメントをスキップする場合は、コメントの URL と理由を記載した簡潔な内部スキップリストを保持してください。スキップしたコメントについて判断記録を作成せず、コメントごとの確認手順にも、最終的な GitHub 返信／解決のプレビューにも含めないでください。ただし、スキップした件数の簡潔な概要は含めてください。

コメントが自動生成か、すでに回答済みか、またはまだ対応が必要か判断できない場合は、スキップせず確認対象に残してください。

ユーザーへの質問に関する要件

このスキル内の ask_user_question の呼び出しには、すべてツールの自由入力用「その他」フィールドを使用する Other... オプションを含めてください。このオプションを使って、カスタムのモード、返信、理由、投稿指示、または次の手順をユーザーが入力できるようにしてください。カスタムテキストを集めるためだけに通常のチャットへ制御を戻してはいけません。

最初のモード選択

個々のコメントについて話し合う前に、ask_user_question を呼び出し、モードに関する質問を一つだけ行ってください。

Respond one-by-one
Collect all decisions, then address in a batch
Other...

以降のワークフローでは、選択されたモードを使用してください。

1件ずつ処理するモード

各コメントについて、次のコメントに進む前にユーザーの判断を確認し、依頼されたコード変更があれば直ちに実施します。各変更の後、以下を記録します。

対応中のコメント
変更したコードまたはドキュメント
実施済み、または今後実施が必要な検証
GitHub への返信案と、スレッドを解決済みにするかどうか

一括処理モード

各コメントについて、コードを編集する前にユーザーの判断を対話形式で確認します。一括処理モードでも、情報収集の段階をまとめたり省略したりはしません。ユーザーは各コメントについて、判断を下す前に追加の背景情報を求めたり、説明を依頼したり、該当コードを確認したり、独自の対応方法を提示したりできる必要があります。すべてのコメントについて判断が決まったら、依頼されたコード変更をまとめて適用し、その後に検証を行い、最終的な GitHub 返信のプレビューを作成します。

コメントごとの確認手順

表示された順にコメントを処理します。各コメントについて、次の手順に従います。

関連する背景情報を簡潔に説明します。
- 投稿者
- ファイルと行、または PR 全体に関するコメントの位置
- 位置情報がある場合は、1行のコメントには path:line、範囲指定コメントには path:start-end の形式でクリック可能なファイル参照
- コメントの簡潔な要約
- 理解に必要な明らかなコードの背景情報
読み込まれた情報だけでは修正方法が明らかでない場合は、選択肢を提示する前に該当ファイルを確認します。
コメントごとに適切な選択肢を用意し、ask_user_question を呼び出します。

コードに付いたコメントの場合は、ユーザーが該当箇所をすぐに開けるよう、質問の前にファイル参照を表示します。例として、リポジトリ相対パス src/lib.rs:42 や src/lib.rs:40-48 を使用します。ファイル位置が指定されていない PR 全体に関するコメントの場合は、コード位置が付いていないことを伝えます。

次の意味を持つ選択肢を必ず含めます。

このコメントに対して、エージェントが推奨する修正を適用する
判断する前に、このコメントの意味を説明してもらう
コメントを認識したことを伝えるが、コード変更はしない
Other...

独自の回答や対応方法には、Other... の自由記述欄を使用します。自由記述を集めるためだけに通常のチャットでユーザーに対応を返してはいけません。

ユーザーが「説明」を選んだ場合は、コメントの背景、そのコメントをレビュー担当者が指摘したと思われる理由、関連するトレードオフを簡潔に説明します。その後、同じコメントについて、選択肢を更新して再度質問します。判断を省略してはいけません。

この説明の繰り返しは、1件ずつ処理するモードと一括処理モードの両方に適用されます。一括処理モードでは、コード編集と GitHub コメントの更新のみを後回しにします。コメントごとの情報収集は、引き続き対話形式で行います。

ユーザーが「変更せずに認識する」を選んだ場合は、コードを変更しない理由について、追加情報を提示するかどうかを確認します。提示された理由は、最終的な GitHub 返信案に反映します。

判断記録

各コメントについて、内部の判断記録を保持します。記録には以下を含めます。

コメントの識別子または URL
コメントの種類：レビューのスレッドコメント、スレッドへの返信、PR 全体に関するコメント、またはレビュー本文
選択した対応：修正、説明後に修正、変更せずに認識、独自の対応、または対応なし
コード変更がある場合は、その内容
必要な検証
返信案
レビュースレッドを解決済みにするかどうか

返信案は簡潔かつ具体的にします。変更内容、または意図的に対応しない理由を記載する返信を優先します。GitHub に投稿する可能性がある返信案の先頭には、必ず [Warp Agent] を付け、エージェントが作成した返信であることをレビュアーに示します。返信を投稿する前に修正がコミットおよびプッシュされている場合は、コメントへの対応を確認できるよう、その返信に修正したコミットへのリンクを含めます。

修正の適用

ユーザーが選択したモードに従います。

個別モードでは、承認された修正を1件ずつ編集して検証してから、次のコメントに進みます。
一括モードでは、すべてのコメントに対する判断がそろってから、承認された修正をまとめて行います。

変更を加える際は、次の点に従います。

選択されたPRコメントに関連する変更のみを適用します。
関連のないローカル変更は保持します。
リポジトリ固有のコーディング、テスト、スタイルのルールに従います。
個別モードでは各修正の後に、必要最小限の有用な検証を実行し、すべての修正の適用後に最終検証を実行します。
要求された修正が安全でない、曖昧、または別のコメントと競合する場合は、編集を中止してユーザーに確認します。

最終検証

承認された修正をすべて適用した後、次の手順を実行します。

git diffを確認し、変更内容が収集した判断と一致していることを確かめます。
リポジトリの規約と変更したファイルに応じて、関連するフォーマット、リンティング、型チェック、ビルド、またはテストを実行します。
検証を実行できない場合は、その理由を最終サマリーで説明し、プレビューにもその旨を含めます。

ユーザーから明示的に依頼されない限り、変更をコミットしないでください。

GitHubへの返信前のコミットとプッシュ

検証後、GitHubへの返信を投稿したりレビューのスレッドを解決したりする前に、変更をコミットしてoriginにプッシュするかユーザーに確認します。この順序により、レビュー担当者はエージェントがコメントへの返信を投稿する前に、プッシュされたコードを確認できます。

コメントへの対応による作業ツリーの変更がない場合は、コミット／プッシュの確認を省略し、GitHub返信のプレビューに進みます。

次のような選択肢を指定してask_user_questionを呼び出します。

返信を投稿する前に、変更をコミットしてoriginにプッシュする
コミットもプッシュもせず、GitHub返信のプレビューに進む
GitHubへの返信を投稿する前に停止する
その他...

ユーザーがコミットとプッシュを選択した場合：

git statusと最終差分を確認し、コメントへの対応に必要な変更のみが含まれていることを確かめます。
コミットメッセージがまだ明確でない場合は、簡潔なコミットメッセージをユーザーに尋ねるか提案します。カスタムのコミット指示を入力できるよう、その他...の選択肢を残します。
対象の変更をステージし、非対話型コマンドでコミットして、現在のブランチをoriginにプッシュします。
コミットメッセージにCo-Authored-By: Warp Agent <[email protected]>を含めます（PRの説明には含めないでください）。すでにコミットに含まれている場合は、重複して追加しないでください。
コミットまたはプッシュに失敗した場合は、GitHubへの返信を投稿する前に停止し、失敗を報告します。

GitHubへの返信と解決のプレビュー

コミット／プッシュの判断が完了した後、GitHubに何かを投稿する前に、コメントごとにまとめたプレビューを表示します。各コメントには次の情報を含めます。

コメントのURLまたは短い識別子
アクション：返信のみ、解決のみ、返信して解決、またはGitHub上での対応なし
返信文
修正に対応するプッシュ済みのコミットがある場合は、そのコミットへのリンク
そのコメントに関連する検証

その後、続行するかどうかを尋ねるためにask_user_questionを呼び出します。

返信を投稿し、承認されたスレッドを解決する
返信の草案を先に編集する
何も投稿しない
その他...

ユーザーが編集を選んだ場合は、編集内容を収集してプレビューを更新し、再度承認を求めます。ユーザーが承認の選択肢を選ぶまで、投稿しないでください。

GitHub CLI で投稿する

GitHub CLI は承認を得てから使用してください。すべての gh コマンドでページャーを無効にしてください。

返信または PR コメントを投稿する GitHub CLI コマンドを実行する前に、送信する本文が [Warp Agent] で始まっていることを確認してください。始まっていない場合は、投稿前にこのプレフィックスを追加してください。

レビューコメントには、REST API エンドポイントを使って返信を投稿してください。返信本文は一時的な JSON ファイルに書き込み、応答テキストをコマンドライン引数に直接指定するのではなく、--input で渡してください。

REPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
REPLY_PAYLOAD_FILE="$(mktemp)"
python3 - "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE" <<'PY'
import json
import sys
from pathlib import Path

body_file = Path(sys.argv[1])
payload_file = Path(sys.argv[2])
payload_file.write_text(json.dumps({"body": body_file.read_text()}))
PY
GH_PAGER="" gh api \
  --method POST \
  /repos/{owner}/{repo}/pulls/{pull_number}/comments/{comment_id}/replies \
  --input "$REPLY_PAYLOAD_FILE"
rm -f "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE"

PR レベルのコメントや、直接スレッドに返信できないレビュー本文コメントには、通常の PR コメントを投稿し、元のコメントを引用するか、そのコメントへのリンクを記載してください。

REPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"
rm -f "$REPLY_BODY_FILE"

レビュースレッドを解決するには、GraphQL を使用してください。スレッドのノード ID がすでにわかっていない場合は、PR のすべてのレビュースレッドをクエリし、読み込んだコメント ID とそれを含むスレッドを対応付けてください。最初の 100 件以降のスレッドも解決できるよう、ページネーションを使用してください。

GH_PAGER="" gh api graphql --paginate \
  -f owner="{owner}" \
  -f repo="{repo}" \
  -F number={pull_number} \
  -f query='
    query($owner: String!, $repo: String!, $number: Int!, $endCursor: String) {
      repository(owner: $owner, name: $repo) {
        pullRequest(number: $number) {
          reviewThreads(first: 100, after: $endCursor) {
            pageInfo {
              hasNextPage
              endCursor
            }
            nodes {
              id
              isResolved
              comments(first: 100) {
                nodes {
                  databaseId
                  url
                }
              }
            }
          }
        }
      }
    }'

承認済みのスレッドを解決するには、次を実行してください。

GH_PAGER="" gh api graphql \
  -f threadId="$THREAD_ID" \
  -f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { id isResolved } } }'

利用可能なメタデータではコメントに返信できない、または解決できない場合は、その制限を報告し、推測するのではなく手動で GitHub を操作する方法を提案してください。

最終回答

承認済みの返信を投稿し、承認済みのスレッドを解決した後、次の内容をまとめてください。

対応したコメント
変更したファイル
検証結果
変更をコミットして origin にプッシュしたかどうか
投稿した GitHub への返信または解決
ユーザーに残された作業

Markdown 対応

ログインしてコメント

基本情報

作者: warpdotdev
リポジトリ: warpdotdev/common-skills
カテゴリ: 開発
インストール数: 25,149
GitHub スター: 636

問題を報告