mcpField
A
answer-pr-reviews

answer-pr-reviews

github.com/ismail9kテスト・品質3042 回インストール1 週間前に更新
リポジトリ

answer-pr-reviews について

answer-pr-reviews は、GitHub のプルリクエストにある未回答のレビュー指摘を扱うスキルです。対象 PR とコメントを集め、ブランチのチェックアウトから修正・返信までを進めますが、各指摘への対応判断は receiving-code-review に委ねます。

主な機能

  1. 01指定 PR または未回答の自分の PR を選択
  2. 02未回答のレビュー指摘を収集
  3. 03指摘ごとの対応に向けてブランチをチェックアウト
  4. 04検証後に修正をプッシュして返信
  5. 05スレッドを未解決のままにし PR をマージしない

活用シーン

  1. 01自分のオープン PR 全体の指摘対応
  2. 02レビューに基づく修正とコミット
  3. 03修正や異議の内容をレビュアーに説明
  4. 04チェック失敗時にプッシュを止める

インストール

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

$npx skills add https://github.com/ismail9k/skills --skill answer-pr-reviews

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

詳細

PR レビューに回答する

Superpowers の receiving-code-review をプルリクエストに適用します。このスキルは各レビューコメントへの対応を判断します。妥当な指摘は修正し、妥当でない指摘には反論します。ただし、プルリクエストを受け取ったり、何かを取得したりすることはありません。このスキルは残りを補います。対象のプルリクエスト、それぞれに寄せられた未回答のフィードバック、そのブランチのチェックアウト、そして一連の対応を完了するためのプッシュと返信です。

ユーザーが指定したプルリクエスト、または未回答のフィードバックがあるユーザー自身のオープンなプルリクエストすべてに回答します。各コメントに返信しますが、スレッドは解決しません。

このスキルはツールではなく、実行するアクションを示します。お使いのプラットフォームに相当するものを使用してください。

要件

  • Superpowers(receiving-code-review、verification-before-completion)。いずれかがない場合は、その名前を示して停止します。
  • GitHub リポジトリと gh があり、gh auth status が成功すること。そうでない場合は、理由を伝えて停止します。

ステージ 1 — プルリクエストを選ぶ

  1. リポジトリ:ユーザーが指定したもの、指定がなければ現在のチェックアウトの GitHub リポジトリ(gh repo view --json nameWithOwner)を使用します。どちらを使用したか伝えます。
  2. プルリクエスト:ユーザーが指定したもの。「すべて」または「自分の PR」の場合は、gh pr list --repo <owner/repo> --state open --author "@me" --limit 1000 --json number,title,url を実行し、ステージ 2 で未回答のフィードバックがあるものを残します。ユーザーが指定した場合に限り、他の作成者のプルリクエストにも回答します。
  3. 各プルリクエストの未回答項目数とともに一覧を表示し、それぞれのブランチに修正をプッシュして返信を投稿することを伝えます。ユーザーの確認を開始の合図とします。ただし、implement-issues のように、開始の合図がすでに与えられた状態で処理を依頼された場合は、一覧を表示して続行します。

ステージ 2 — 未回答のフィードバックを集める

  1. プルリクエスト、そのレビューのスレッド、レビュー、会話コメントを取得します。

    gh api graphql -f owner=<owner> -f repo=<repo> -F number=<number> -f query='
    query($owner: String!, $repo: String!, $number: Int!) {
      repository(owner: $owner, name: $repo) {
        pullRequest(number: $number) {
          title body url headRefName
          reviewThreads(first: 100) {
            nodes {
              isResolved isOutdated path line
              comments(first: 100) { nodes { databaseId author { login } body } }
            }
          }
          reviews(first: 100) { nodes { author { login } body url } }
          comments(last: 100) { nodes { body } }
        }
      }
    }'
    
  2. 回答する項目:

    • 最後のコメントが `` で終わっていない、未解決のスレッドすべて。古いスレッドも含めます。コードが変更された箇所に指摘が残っている可能性があるためです。
    • レビュー本文に書かれたすべての指摘。ただし、そのレビューの url を示すマーカー付きの会話コメントがある場合を除きます。重大度の集計や「指摘なし」という要約は指摘に含めません。

    回答済みかどうかは作成者ではなくマーカーで判断します。implement-issues のように、1 つの gh アカウントがレビューと返信の両方を投稿する場合があるためです。

  3. docs/agents/issue-tracker.md が存在し、タイトルまたは本文にその Linking セクションの参照(GitHub では Closes #<number> または Relates to #<number>)が含まれる場合は、Reading method で意図を示す Issue を読み、その Constraints を保持します。

ここからは、プルリクエストを 1 つずつ処理します。回答する項目が残っていないものは完了です。その旨を伝えます。

ステージ 3 — ブランチをチェックアウトする

  1. worktree で作業するよう依頼された場合は、そこで作業します。

  2. 未コミットの変更がない場合は、headRefName の既存のチェックアウトを使用します(git worktree list)。未コミットの変更がある場合は、そのプルリクエストの処理を停止し、理由を伝えます。誰かの変更を stash、破棄、またはコミットしてはいけません。

  3. チェックアウトがない場合は、新しく作成します。gh pr checkout は、フォークのブランチを含め、ブランチのプッシュ先も設定します。

    git check-ignore -q .worktrees || echo ".worktrees/" >> "$(git rev-parse --git-common-dir)/info/exclude"
    git worktree add --detach ".worktrees/pr-<number>"
    cd ".worktrees/pr-<number>" && gh pr checkout <number> --repo <owner/repo>
    

ステージ 4 — receiving-code-review で回答する

チェックアウト内で receiving-code-review を実行します。フィードバックはステージ 2 の項目を使い、それぞれにパス、行番号、スレッド全体を含めます。意図を示す Issue の Constraints は、ユーザーが以前に下した判断として扱います。

  • ユーザーが実行している場合:質問はユーザーに尋ねます。
  • 開始の合図が与えられた状態で処理を依頼された場合:質問に答えられる人はいません。質問する、または停止して相談するよう記載されている箇所では、判断を下し、その項目への返信に理由を記載します。

修正ごとに個別にコミットし、返信でそのコミットを示せるようにします。各項目の結果(修正済みとそのコミット、理由を添えた反論、または失敗した内容を添えた修正不可)を記録し、それをもとに返信を作成します。

ステージ 5 — プッシュしてから返信する

  1. AGENTS.md またはプロジェクトのマニフェストに記載されたプロジェクトのテスト、lint、型チェックのコマンドを、verification-before-completion のもとで実行します。失敗した場合は、失敗の原因となった修正を元に戻し(その項目は修正不能になります)、再度実行します。それでも失敗する場合は、プッシュせず、何にも返信せず、その旨を報告します。
  2. 新しいコミットがある場合は、git push を実行します。強制プッシュはしません。プッシュが拒否された場合は、このプルリクエストへの対応を中止し、何にも返信せず、その旨を報告します。
  3. プッシュが反映されたら、すべての項目に返信し、各返信の末尾に `` を付けます。
    • インラインスレッド — スレッド内の最初のコメントに返信します。

      gh api --method POST repos/<owner>/<repo>/pulls/<number>/comments/<first comment databaseId>/replies -F [email protected]
      

      Fixed in <sha> — <what changed>.、または反論する理由、あるいは試したことと修正できなかった理由を記載します。

    • レビュー本文の指摘 — レビューの url へのリンクを含め、各指摘に順番に回答するコメントを1つ投稿します。 gh pr comment <number> --repo <owner/repo> --body-file reply.md。

ステージ 6 — 報告

1つの表に、プルリクエスト、回答した項目、修正済み/反論済み/修正不能、チェック結果、プッシュしたヘッドを記載します。プッシュしなかった場合はその理由を記載します。その後、対応対象外としたすべてのプルリクエストと、その理由を記載します。

してはいけないこと

  • 自分で項目への対応を決めてはいけません。receiving-code-review が決定します。このスキルは取得、プッシュ、返信を行います。
  • コミットをプッシュする前に「修正済み」と返信してはいけません。
  • チェックに失敗した場合はプッシュしてはいけません。また、強制プッシュは絶対にしないでください。
  • スレッドを解決したり、レビューを却下したり、承認、マージ、プルリクエストをレビュー可能な状態にしたりしてはいけません。作業を受け入れるかどうかはユーザーが判断します。
  • インラインコメントに会話コメントで返信してはいけません。
  • ユーザーが指定していない他の作成者のプルリクエストに返信してはいけません。
  • チェックアウトするために、他人の未コミット変更を stash、破棄、またはコミットしてはいけません。
  • このスキルの返信がすでに付いている項目には回答してはいけません。

コメント