mcpField
P
pr-finish

pr-finish

github.com/gjkim42開発01.1k 回インストール7 週間前に更新
リポジトリ

pr-finish について

レビュー、修正、検証、CI のサイクルを制限して PR を完了するためのスキルです。指摘の分類と修正の一括適用、プッシュ、定めた範囲での確認手順を案内します。

主な機能

  1. 01PR のレビューとチェック状態を取得
  2. 02編集前に指摘を分類
  3. 03有効な P0～P2 修正を一括適用
  4. 04対象を絞った検証と最終確認
  5. 05レビューと CI の再確認回数を制限

活用シーン

  1. 01PR のレビューコメントを分類
  2. 02複数の指摘をまとめて修正
  3. 03修正内容を検証してプッシュ
  4. 04長時間の CI が上限を超えたら待機を終了

インストール

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

$npx skills add https://github.com/gjkim42/kanon-repo --skill pr-finish

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

詳細

PR の仕上げ

レビューと CI が際限のないループにならないように、PR を仕上げる際にこのスキルを使用します。review-all はレビューのみに限定し、トリアージ、修正、検証、プッシュ、範囲を限定した CI ワークフローはこのスキルで行います。

ルール

  • レビューコメントを一つずつ修正しないでください。
  • 編集前に、現在のレビュー状態をすべて取得してください。PR のレビュー本文、インラインレビューコメント、イシューコメント、現在のヘッド SHA、チェックの状態が対象です。
  • すべての指摘を valid、already fixed、obsolete、not actionable のいずれかに分類してください。
  • 有効な P0〜P2 の修正をすべてまとめて適用してください。
  • P3 は、明示されたリポジトリの規約に違反する場合、わずかな手間で明らかに有用な場合、またはユーザーが些細な指摘もすべて修正するよう求めた場合を除き、任意とします。
  • まず変更したコードを対象にしたテストを実行し、その後、プッシュ前にリポジトリ全体の最終検証を一度実行してください。
  • 1 回の修正バッチにつき、プッシュは 1 回にしてください。
  • バッチ適用後に review-all を 1 回実行してください。有効な P0〜P2 の指摘が残っている場合は、ユーザーから明示的に続行を求められない限り、追加の修正バッチは最大 1 回までとします。
  • 個々の修正のたびに review-all を再実行しないでください。
  • 10 分経過後も長時間実行の e2e ジョブのみが保留中の場合は、ユーザーから明示的に待機を求められていない限り、状況を報告して終了してください。

手順

1. PR のコンテキストを特定する

現在のブランチに対応する PR を探します。

gh pr view --json number,url,title,headRefOid,reviewDecision,statusCheckRollup

ブランチに PR がない場合は、PR 番号を尋ねてください。

2. レビュー状態を取得する

レビューの概要、イシューコメント、チェックを取得します。

gh pr view <pr> --json url,title,headRefOid,reviewDecision,latestReviews,reviews,comments,statusCheckRollup

インラインレビューコメントを取得します。

gh api repos/<owner>/<repo>/pulls/<pr>/comments --paginate

GitHub の操作には gh を使用してください。サンドボックスのネットワークアクセスが原因で API 呼び出しに失敗した場合は、必要な承認を得て同じコマンドを再実行してください。

3. 編集前にトリアージする

変更を加える前に、簡潔なトリアージ表を作成してください。

ソースファイル:行優先度指摘状態対応

分類：

  • valid：現在の HEAD にも当てはまり、修正すべきものです。
  • already fixed：コード、ドキュメント、テストですでに対応済みのものです。
  • obsolete：古いコミットや移動済みのコードに対するコメントで、現在は当てはまらないものです。
  • not actionable：誤り、推測に基づくもの、または依頼された範囲外の動作を求めるものです。

表を完成させてから編集してください。

4. まとめて修正する

有効な P0〜P2 の修正をすべてまとめて適用してください。変更範囲を絞り、リポジトリの規約に沿ってください。P3 は、規約に基づく場合、またはわずかな手間で明らかに価値がある場合にのみ修正してください。

5. 検証する

まず、変更したコードを対象としたチェックを実行してください。例：

go test ./internal/cli
go test ./internal/controller

次に、リポジトリの標準的な検証ターゲットを実行してください。

make test
make verify

make test-integration などのより広範なターゲットは、変更したコードまたはレビューの指摘から必要と判断される場合にのみ実行してください。

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

差分と状態を確認してください。

git status --short
git diff --stat
git diff --check

対象範囲を明示したメッセージでコミットし、そのバッチで 1 回プッシュしてください。

7. Review-All を 1 回実行する

プッシュ後、コミット済みブランチの差分に対して review-all を 1 回実行してください。

review-all で有効な P0〜P2 の指摘があった場合は、修正サイクルをもう 1 回だけまとめて実施してください。すべての指摘をトリアージし、まとめて修正し、検証、コミット、プッシュを行います。ユーザーから明示的な確認を得ない限り、2 回目のサイクルを超えて続行しないでください。

P3 の指摘のみが残る場合は、明示されたリポジトリの規則に違反するものを除き、任意項目として報告してください。

8. 範囲を決めて CI を監視する

状態を確認してください。

gh pr checks <pr>

チェックに失敗した場合は、そのジョブを調査して失敗を修正してください。チェックが成功している場合、または長時間実行の e2e ジョブのみが保留中の場合は、次の方針に従ってください。

  • 保留中の長時間ジョブは、合計で最大 10 分待機します。
  • 10 分経過後も実行中の場合は、保留中のジョブを報告して終了します。
  • ユーザーがすべてのチェックの完了を明示的に求めた場合にのみ、待機を続けてください。

最終報告

最終回答は簡潔にまとめます。

  • 修正またはトリアージしたレビュー指摘
  • プッシュしたコミット
  • 実行したローカルチェック
  • PR のチェック状態
  • 保留中の長時間ジョブ、または任意の P3 項目

コメント

Markdown 対応