follow-up-on-pr

PR のフォローアップ

既存の PR を引き継ぎ、最新の状態に更新し、すべてのフィードバックに対応して、マージ可能な状態にします。このスキルは言語やフレームワークに依存しません。例として示されているコマンドは、プロジェクトで実際に使用しているビルド、リント、テスト、フォーマットのコマンドに置き換えてください。

入力

• PR の URL または番号（必須）：例：https://github.com/<owner>/<repo>/pull/9996 または #9996
• ブランチ名（任意）：指定されていない場合は、PR のメタデータから取得します

ワークフロー

1. PR を調べる

FetchUrl（または gh pr view）で PR を取得し、以下を確認します。

• ファイルの変更（差分）
• レビュアーのコメント（インラインおよび全般）
• CI ワークフローのステータスとログ
• PR の説明と、関連付けられたチケット

変更されたすべてのファイルを詳しく読みます。変更の意図と範囲を把握します。

PR が特定の問題を修正する場合（例：エラーレポート、ユーザーから報告されたバグ）は、コードをレビューする前に根本原因を調査します。修正が実際の問題に対処していることを確認します。ほかの修正によって、すでに解決済みの PR である場合もあります。

2. ブランチを取得してチェックアウトする

git fetch origin <branch-name> <base-branch>
git checkout <branch-name>

ブランチがローカルに存在しない場合、git checkout は origin/<branch-name> から追跡ブランチを作成します。

3. 最新のベースブランチにリベースする

git pull origin <base-branch> --rebase

コンフリクトが発生した場合：

1. コンフリクトしている各ファイルを読み、双方の変更内容を把握します
2. PR の意図を保ちながらベースブランチの変更を取り込み、コンフリクトを解決します
3. git add <resolved-files>
4. git rebase --continue

リベースでコンフリクトが発生しなかった場合： git log --oneline -5 と git diff --stat origin/<base-branch>..HEAD を実行し、状態を確認します。

4. レビュアーのコメントに対応する

レビューコメントは手順 1 ですでに取得しています。未解決のコメントごとに、以下を行います。

1. コメントを読み、求められている内容を理解します
2. コードを変更する（または変更が不要な理由を説明する）
3. 求められている場合はテストを追加する
4. 内容がわかるメッセージを付けて、修正をコミットする

すでに対応済みのコメント： 返信がすでにあるか（in_reply_to_id フィールド）を確認します。解決済みのコメントはスキップします。

5. ローカルで CI チェックを実行する

影響範囲に対して、プロジェクトのリント、フォーマット、型チェック／コンパイル、テストのコマンドを実行します。リポジトリのルート（例：Makefile、package.json、pyproject.toml、Cargo.toml、go.mod、build.gradle、mix.exs、Gemfile、composer.json、justfile、Taskfile.yml、README.md、CI ワークフローの設定）を確認し、コマンドを特定します。

影響範囲に絞るには、フィルターやターゲット指定のフラグを優先してください。リポジトリ全体を実行するより高速です。一般的なパターンは次のとおりです。

• JS/TS モノレポ：npm run test -- --filter=<workspace>、pnpm -r --filter <pkg> test、nx test <project>
• Python：pytest <path>、tox -e <env>
• Rust：cargo test -p <crate>、cargo clippy -p <crate>
• Go：go test ./<pkg>/...、golangci-lint run ./<pkg>/...
• Java/Kotlin：./gradlew :<module>:test、./mvnw -pl <module> test
• Bazel：bazel test //path/...

一般的な CI チェックに対応するローカルコマンドのテンプレートについては、create-pr スキルの「CI Checks Reference」セクションを参照してください。

既存の失敗と PR による問題を見分ける： ベースブランチにも存在し、PR と無関係な CI の失敗もあります。PR で変更されていないファイルで失敗が発生した場合、修正に時間をかける前に、その失敗がベースブランチでも起きることを確認します。よくある既存の問題には、新しく追加された依存関係に関するモジュール／パッケージ解決エラーなどがあります。

E2E テスト： PR にユーザー向けの動作（UI フロー、デフォルト値、キーボード操作、CLI の出力）の変更が含まれる場合、コードが正しくても E2E テストが失敗することがあります。失敗したテストを読み、何を期待しているのかを把握してから、新しい動作に合わせて更新します。失敗を不安定なテストによるものと決めつけず、まず内容を確認してください。

6. コミットしてプッシュする

git add -A
git commit -m "<type>(<scope>): <description>"

git push origin <branch-name> --force-with-lease

コミットスキャンボットにプッシュをブロックされた場合（Droid-Shield、GitGuardian、TruffleHog など）：無関係なテスト用フィクスチャに、シークレットのように見える文字列が含まれていると発生することがあります。エージェント側ではこれを回避できません。手動でプッシュするか、組織のドキュメントに従ってスキャナーを一時的に無効にするようユーザーに伝えてください。

7. レビュアーのコメントに返信する

対応したコメントごとに PR で返信し、フィードバックに対応したことをレビュアーに伝えます。

インラインのレビューコメントの場合（最も一般的な種類）：

# Reply to a specific inline comment thread
gh api repos/<owner>/<repo>/pulls/<N>/comments/<COMMENT_ID>/replies \
  -X POST \
  -f body="<explanation of what was done>"

PR 全体に関する概要の場合：

gh pr comment <N> --body "<summary of all changes made>"

スレッドの解決状況を確認する場合（任意）：

gh api graphql -f query='{
  repository(owner: "<owner>", name: "<repo>") {
    pullRequest(number: <N>) {
      reviewThreads(first: 20) {
        nodes {
          isResolved
          comments(first: 3) { nodes { body author { login } } }
        }
      }
    }
  }
}'

8. PR の説明を更新する

フォローアップ中に行った変更が重要な場合（新しいテスト、アーキテクチャの変更、スコープの追加など）は、PR の説明を更新します。

gh pr edit <N> --body "<updated description>"

組織の PR テンプレートの形式を使用します。テストのセクションを更新し、追加したテストを反映させます。

検証

作業を完了とする前に、次の項目を確認してください。

• ブランチが最新のベースブランチにリベースされている
• すべてのレビュアーコメントにコード変更で対応している
• 対象パッケージのローカルの lint、型チェック／コンパイル、テストが成功している
• 変更がリモートにプッシュされている
• すべてのレビュアーコメントに、実施した内容を説明する返信がある
• PR の説明が最新の状態になっている