mcpField
B
branch-review-before-pr

branch-review-before-pr

github.com/ulpi-ioテスト・品質5167 回インストール9 週間前に更新
リポジトリ

branch-review-before-pr について

PR 前にブランチとベースの差分を確認するレビュー用スキルです。根拠のある指摘を報告し、修正にはユーザーの明示的な承認を求めます。

主な機能

  1. 01差分全体とチェックリストの確認
  2. 02ブランチ差分にレビュー範囲を限定
  3. 03ブロッカーと非ブロッカーの分類
  4. 04承認がない場合は読み取り専用
  5. 05個別に承認された修正のみ適用

活用シーン

  1. 01PR 作成前のブランチレビュー
  2. 02プロジェクトのチェックリストに沿った変更確認
  3. 03ブロッカーの分類と対応判断

インストール

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

$npx skills add https://github.com/ulpi-io/skills --skill branch-review-before-pr

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

同梱ファイルchecklist.md

詳細

このスキルはレビューを優先し、ユーザーが明示的に承認した場合にのみ変更を行います。

譲れないルール：

  1. 問題を報告する前に、差分全体を読みます。
  2. checklist.md を読み込み、抑制項目を尊重します。
  3. レビュー対象は、レビューのベースとの差分に限定します。
  4. ブロッキングな問題について、ユーザーが明示的に「今すぐ修正」を選ばない限り、読み取り専用を維持します。
  5. 指摘は簡潔で、根拠を示し、具体的にします。

PR 作成前のブランチレビュー

入力

  • $request：任意の注目領域、ブランチのリスクに関するヒント、またはレビュー範囲の明確化

目標

現在のブランチをデフォルトのベースと比較してレビューし、次のことを行います。

  • コンテキストの確認後も残る構造的な欠陥を見つける
  • ブロッキングな問題とブロッキングではない問題を分ける
  • 各ブロッキングな問題への対応方法をユーザーに尋ねる
  • ユーザーが明示的に承認した修正のみを適用する

ステップ 0：レビューのベースを特定する

次を確認します。

  • 現在のブランチ
  • デフォルトのレビュー用ベース（通常は origin/main または origin/master）
  • ユーザーがブランチ全体のレビューを希望しているか、より限定された範囲のレビューを希望しているか

現在のブランチがすでにベースブランチである場合、または差分がない場合は、そこで終了し、その旨を明確に伝えます。

成功基準：差分のベースが明示されており、レビュー対象となる実際のブランチ差分があること。

ステップ 1：チェックリストと差分の範囲を確認する

次を読みます。

  • checklist.md
  • ベースブランチとの差分全体
  • 差分が大きい場合は変更ファイルの一覧

ルール：

  • --stat だけを見てレビューしないでください。
  • 抑制されているチェックリスト項目は報告しないでください。
  • 差分が大きい場合は、主張を確認できるだけの周辺コンテキストを含めて、変更ファイルを個別に読みます。

成功基準：チェックリストを読み込み、重要な変更ファイルをすべて確認していること。

ステップ 2：2 段階でレビューする

第 1 段階では、ブロッキングな問題のみを確認します。

  • クエリとデータの安全性
  • 競合状態と並行処理
  • 認証と信頼境界

第 2 段階では、ブロッキングではない問題を確認します。

  • 残りのすべてのチェックリスト項目

問題の候補ごとに、次を確認します。

  • 実際にレビュー対象の範囲内か
  • 差分内の別の箇所ですでに修正されていないか
  • 周辺のコードですでに対策されていないか

成功基準：重要なチェックリスト項目をすべて評価し、誤検出を除外していること。

ステップ 3：すべての指摘を報告する

常に結果をすべて報告します。

  • まずブロッキングな問題
  • 次にブロッキングではない問題
  • 問題が見つからなかった場合は、明確に問題なしと伝える

次の構成を使用します。

Branch Review: N issues (X critical, Y informational)

CRITICAL (blocking):
- [file:line] Problem description
  Fix: suggested fix

Issues (non-blocking):
- [file:line] Problem description
  Fix: suggested fix

成功基準：ブランチがブロックされているかどうか、その理由がユーザーにすぐわかること。

ステップ 4：ブロッキングな問題を 1 件ずつ処理する

ブロッキングな問題ごとに、次の内容を含む AskUserQuestion を個別に使用します。

  • 問題と発生箇所
  • 推奨する修正
  • 次の選択肢：
    • Fix it now
    • Acknowledge
    • False positive

ユーザーが選択した場合：

  • Fix it now：承認された修正のみを適用します。
  • Acknowledge：コードは変更せず、受け入れたことを記録します。
  • False positive：コードは変更せず、指摘を却下したことを記録します。

複数のブロッキングな問題を 1 つの質問にまとめてはいけません。

成功基準：各ブロッキングな問題について、ユーザーの明示的な判断があること。

ステップ 5：承認された修正のみを適用する

ユーザーが Fix it now を選択した場合：

  • 最小限かつ適切なコード変更を行います。
  • 変更範囲は、承認された問題に限定します。
  • コミット、プッシュ、PR の作成は行いません。
  • 修正を適用した後、変更内容を要約します。

ユーザーが問題を了承するか、却下するだけの場合は、編集を行いません。

成功基準：明示的に承認された修正のみが適用されていること。

参照資料を読み込むタイミング

  • checklist.md 詳細なレビューマトリクス、抑制項目、問題の分類に使用します。

ガードレール

  • disable-model-invocation を追加しないでください。このスキルは PR／リリースのワークフローでも引き続き使用できる必要があります。
  • コンテキストの確認に必要な場合を除き、変更されていないファイルはレビューしないでください。
  • スタイル上の好みを問題として報告しないでください。
  • ユーザーがその問題を明示的に承認しない限り、修正しないでください。
  • このスキルを使ってコミット、プッシュ、PR の作成を行わないでください。

出力仕様

次の内容を報告します。

  1. レビュー対象のベースとブランチの範囲
  2. ブロッキングとなる指摘事項
  3. ブロッキングではない指摘事項
  4. 質問があった場合の、ブロッキングとなる指摘事項ごとのユーザーの決定
  5. 実際に適用した修正

コメント

Markdown 対応