iterate-pr について
CI チェックの通過とレビューコメントへの対応を目指して、GitHub のプルリクエストを反復的に処理するスキルです。`gh` を使う優先度付きの手順を示しますが、参照先の補助スクリプト 2 つは外部要件で、利用できない場合があります。
主な機能
- 01`gh` によるプルリクエスト情報の確認
- 02優先度に応じたレビューコメントの処理
- 03ログに基づく CI 失敗の診断
- 04修正の検証と変更のコミット
- 05チェックとフィードバックの反復確認
- 06記載された `gh` の代替手順
活用シーン
- 01オープン中のプルリクエストの CI 失敗修正
- 02マージ前のレビューコメントの分類と対応
- 03プッシュ後のチェック状況と新規フィードバックの監視
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill iterate-prインストール後、Claude Code で/iterate-prを入力して読み込まれたか確認します。
詳細
翻訳後に原文が更新されています。最新の内容は原文をご確認ください。
補足資料の入手について
このカタログの記載には、以下のインラインガイダンスが含まれていますが、次の補足パスは含まれていません。これらは外部の前提条件であり、同梱ファイルではありません。
<support-root>/scripts/fetch_pr_checks.py<support-root>/scripts/fetch_pr_feedback.py
これらのパスに依存する手順を実行する前に、元の補足資料または既存のインストール環境を入手してください。このカタログには、検証済みのダウンロード元は記載されていません。各パスをそのインストール環境を基準に解決し、内容を確認して、該当するライセンスと実行上の前提条件を検証してください。必要なファイルが存在することを確認するまでは、コマンドを実行したり、参照先の手順に従ったと主張したりしないでください。不足しているスクリプトを捏造したり、同じ名前の無関係なファイルを同等のものとして扱ったりしないでください。ここに完全に記載されている独立した手順は、ユーザーが許可した範囲内で進められます。依存する手順は利用できないものとして報告してください。
CI が通るまで PR を反復改善する
すべての CI チェックに合格し、レビューのフィードバックに対応できるまで、現在のブランチを継続的に反復改善します。
必要条件:GitHub CLI(gh)で認証済みであること。
重要:すべてのスクリプトは、スキルディレクトリではなく、リポジトリのルートディレクトリ(.git がある場所)から実行する必要があります。${CLAUDE_SKILL_ROOT} を使ってスクリプトのフルパスを指定してください。
同梱スクリプト
scripts/fetch_pr_checks.py
CI チェックのステータスを取得し、ログから失敗箇所の抜粋を抽出します。
uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py [--pr NUMBER]
JSON を返します:
{
"pr": {"number": 123, "branch": "feat/foo"},
"summary": {"total": 5, "passed": 3, "failed": 2, "pending": 0},
"checks": [
{"name": "tests", "status": "fail", "log_snippet": "...", "run_id": 123},
{"name": "lint", "status": "pass"}
]
}
scripts/fetch_pr_feedback.py
LOGAF スケールを使って、PR のレビューのフィードバックを取得し、分類します。
uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py [--pr NUMBER]
フィードバックを次のように分類した JSON を返します:
high- マージ前に必ず対応する必要があります(h:、ブロッカー、変更要求)medium- 対応が望まれます(m:、標準的なフィードバック)low- 任意です(l:、軽微な指摘、スタイル、提案)bot- 情報提供を目的とした自動コメント(Codecov、Dependabot など)resolved- すでに解決済みのスレッド
レビュー bot によるフィードバック(Sentry、Warden、Cursor、Bugbot、CodeQL など)は、review_bot: true として high/medium/low に表示され、bot の分類には入りません。
各フィードバック項目には、次の情報が含まれる場合もあります:
thread_id- インラインのレビューコメントに対する GraphQL ノード ID(返信に使用)
ワークフロー
1. PR を特定する
gh pr view --json number,url,headRefName
現在のブランチに PR が存在しない場合は中止してください。
2. レビューのフィードバックを収集する
${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.py を実行し、PR にすでに投稿されている分類済みのフィードバックを取得します。
3. LOGAF の優先度に応じてフィードバックに対応する
自動修正(プロンプト不要):
high- 必ず対応する必要があります(ブロッカー、セキュリティ、変更要求)medium- 対応が望まれます(標準的なフィードバック)
フィードバックを修正する際は:
- 表面的な症状だけでなく、根本原因を理解します
- 近くのコードや関連ファイルに同様の問題がないか確認します
- 指摘された箇所だけでなく、すべての該当箇所を修正します
これには、レビュー bot によるフィードバック(review_bot: true の項目)も含まれます。人間からのフィードバックと同様に扱います:
- 実際の問題が見つかった場合 → 修正します
- 誤検知の場合 → 対応を見送り、その理由を簡潔なコメントで説明します
- レビュー bot のフィードバックを確認せずに無視してはいけません。必ず指摘内容を検証してください
ユーザーに選択を求める:
low- 番号付きリストを提示し、どれに対応するか尋ねます:
Found 3 low-priority suggestions:
1. [l] "Consider renaming this variable" - @reviewer in api.py:42
2. [nit] "Could use a list comprehension" - @reviewer in utils.py:18
3. [style] "Add a docstring" - @reviewer in models.py:55
Which would you like to address? (e.g., "1,3" or "all" or "none")
通知せずにスキップする:
resolvedスレッドbotコメント(情報提供のみ — Codecov、Dependabot など)
コメントへの返信
各インラインレビューコメントを処理した後、PR スレッドに返信して、対応したことを伝えます。thread_id がある項目(インラインレビューコメント)のみ返信してください。
返信するタイミング:
highとmediumの項目 — 修正した場合も、誤検知と判断した場合も返信しますlowの項目 — 修正した場合も、ユーザーが対応しないと判断した場合も返信します
返信方法: pullRequestReviewThreadId と body の入力値を指定して、GraphQL ミューテーション addPullRequestReviewThreadReply を使用します。
返信形式:
- 1〜2 文で、変更内容、問題ではない理由、または対応しないと判断した項目への確認を伝えます
- すべての返信の末尾に
\n\n*— Claude Code*を付けます - 返信する前に、スレッドに
*- Claude Code*または*— Claude Code*で終わる返信がすでにないか確認し、再実行時の重複を避けます gh apiの呼び出しに失敗した場合は、ログに記録して続行します。ワークフローを停止しないでください
4. CI ステータスの確認
${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.py を実行して、構造化された失敗データを取得します。
保留中の場合は待機: レビューボットのチェック(sentry、warden、cursor、bugbot、seer、codeql)がまだ実行中の場合は、続行する前に待機してください。対応が必要なフィードバックが投稿されるため、評価が必要です。情報提供のみを行うボット(codecov)を待つ必要はありません。
5. CI の失敗を修正
スクリプトの出力にある失敗ごとに、次の手順を実行します。
log_snippetを読み、エラーから逆にたどって、何が失敗したかだけでなく、なぜ失敗したかを把握します- 関連するコードを読み、関連する問題がないか確認します(例:ある呼び出し箇所の型エラーなら、ほかの呼び出し箇所も確認します)
- 根本原因を、最小限かつ的を絞った変更で修正します
- 影響を受けるコードの既存テストを探して実行します。修正によって既存テストでカバーされていない動作が生じる場合は、テストを追加してカバーします(テストケースを追加し、テストファイル全体を新たに作成しないでください)
チェック名だけから失敗内容を推測しないでください。必ずログを読んでください。「とりあえず修正して様子を見る」のではなく、コードを変更する前に失敗の原因を十分に把握してください。
6. ローカルで検証してから、コミットしてプッシュ
コミットする前に、修正内容をローカルで検証します。
- テスト失敗を修正した場合:該当するテストをローカルで再実行します
- リントまたは型エラーを修正した場合:影響を受けるファイルに対して、リンターまたは型チェッカーを再実行します
- コードを修正した場合:変更したコードをカバーする既存のテストを実行します
ローカルでの検証に失敗した場合は、先に修正してください。既知の不具合があるコードをプッシュしないでください。
git add <files>
git commit -m "fix: <descriptive message>"
git push
7. CI を監視してフィードバックに対応
処理をブロックするのではなく、ループで CI のステータスとレビューのフィードバックを確認します。
uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_checks.pyを実行して、現在の CI ステータスを取得します- すべてのチェックが成功した場合 → 終了条件に進みます
- チェックが失敗したものがある場合(保留中のものはない) → 手順 5 に戻ります
- チェックがまだ保留中の場合:
a.
uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.pyを実行して、新しいレビューのフィードバックを取得します b. 新しいhigh/mediumのフィードバックがあれば、直ちに対応します(手順 3 と同様) c. 変更が必要だった場合は、コミットしてプッシュします(これにより CI が再開します)。その後、ポーリングを続けます d. 30 秒待機してから、サブステップ 1 から繰り返します - すべてのチェックが成功した後、最後にフィードバックを確認します。
sleep 10を実行してから、uv run ${CLAUDE_SKILL_ROOT}/scripts/fetch_pr_feedback.pyを実行します。新しいhigh/mediumのフィードバックがあれば対応します。変更が必要な場合は、手順 6 に戻ります。
8. 繰り返し
手順 7 でコードの変更が必要になった場合(CI 成功後に新しいフィードバックがあった場合)は、手順 2 に戻って新しいサイクルを開始します。監視中の CI 失敗には、手順 7 のポーリングループ内ですでに対応しています。
終了条件
成功: すべてのチェックが成功し、CI 後のフィードバック再確認で未対応の新しい high/medium のフィードバック(レビューボットの指摘を含む)がなく、優先度の低い項目についてユーザーが判断しています。
助けを求める: 同じ失敗が 2 回続いた場合、フィードバックに確認が必要な場合、またはインフラストラクチャに問題がある場合。
停止: PR が存在しない場合、ブランチのリベースが必要な場合。
フォールバック
スクリプトが失敗した場合は、gh CLI を直接使用します。
gh pr checks name,state,bucket,linkgh run view <run-id> --log-failedgh api repos/{owner}/{repo}/pulls/{number}/comments
使用するタイミング
上記で説明されている主な分野や機能に関連するタスクに取り組む際に、このスキルを使用してください。
制限事項
- タスクが上記の範囲に明確に該当する場合にのみ、このスキルを使用してください。
- 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、作業を中断して確認を求めてください。