mcpField
P
piv-review-pr

piv-review-pr

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

piv-review-pr について

piv-review-prは、GitHubのプルリクエストを審査するエージェントスキルです。人間の判断前に独立したレビューと検証を行いたいチーム向けで、変更を別のコンテキストで確認し、重大度別の結果をPRに投稿します。最終判断は人間が行います。

主な機能

  1. 01番号、URL、ブランチからPRを特定
  2. 02プロジェクト規約と実装背景を読み込み
  3. 03テスト、型チェック、Lint、ビルドを実行
  4. 04重大度別に変更をレビュー
  5. 05レポートを保存してPRに投稿

活用シーン

  1. 01マージ前に正確性とセキュリティを確認
  2. 02PRがプロジェクト規約に沿うか検証
  3. 03人間のレビュー向けに問題と検証結果を整理

インストール

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

$npx skills add https://github.com/coleam00/skills --skill piv-review-pr

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

詳細

PR をレビューする：人間の前に立つエージェント型ゲート

入力：$ARGUMENTS

このスキルの目的は、新鮮な視点です。コードを書いたコンテキストとは異なるクリーンなコンテキストで PR をレビューし、詳細な分析を code-reviewer エージェントに委ねることができます。これこそが、作者自身のコンテキストでは正当化されて見過ごされる問題をレビューで検出できる理由です。PR に判定を投稿し、最後は人間が判断します。

フェーズ 1 — PR を取得する

入力を PR 番号（番号、URL、または gh pr list --head <branch> --json number -q '.[0].number' によるブランチ）に解決します。その後：

gh pr view {N} --json number,title,body,author,headRefName,baseRefName,state,additions,deletions,changedFiles,files
gh pr diff {N}
gh pr checkout {N}

状態の確認：MERGED／CLOSED → 停止（「レビュー対象はありません」）；DRAFT → 方向性をレビューし、承認もブロックもしません。

フェーズ 2 — コンテキストを読み込む（適切な基準でレビューするため）

  • CLAUDE.md と .claude/references/ 内のファイル — プロジェクトの標準をレビュー基準とします。
  • 実装レポート（piv-implement が作成している場合は .claude/reports/*{branch}*）とその計画：文書化された逸脱を確認します。文書化された逸脱は意図的な判断であり、問題ではありません。指摘するのは文書化されていない相違点だけです。（レポートがない場合は通常どおりレビューし、レポートがないことを記載します。）
  • PR 自体の意図（タイトル／本文）：どのような問題を解決すると説明しているか。

フェーズ 3 — 検証を実行する

プロジェクトで実際に使われているテスト一式（piv-validate スキル、または計画に記載された検証コマンド）を実行します。テスト、型チェック、リンター、ビルドを含めます。成功／失敗と件数を記録します。テスト一式の失敗自体が指摘事項です。

フェーズ 4 — 差分をレビューする（code-reviewer エージェントに依頼）

プロジェクトに code-reviewer サブエージェントがある場合（.claude/agents/code-reviewer.md）、詳細なレビューを依頼します。ない場合は、このセッションのクリーンなコンテキストでレビューします。プロジェクトの標準に照らしてレビューし、確度の高い問題のみを報告します。コンテキストを把握するため、変更されたファイルはすべて差分だけでなく全体を読みます。正確性 · 型安全性 · パターン／標準への準拠 · セキュリティ · パフォーマンス · テストの有無 · 保守性を確認します。

すべての問題を重要度別に分類します：

重要度意味
Criticalマージを阻む問題 — セキュリティ、データ損失、クラッシュ
Highマージ前に修正すべき問題 — 型安全性の欠如、エラーハンドリング不足、ロジックエラー
Mediumパターンの不統一、エッジケースの見落とし、文書化されていない逸脱
Low提案、軽微な仕上げ

適切にできている点も取り上げます。レビューは建設的なものであり、欠陥の羅列ではありません。

フェーズ 5 — 判断する

  • 承認 — Critical／High の問題がなく、検証に合格し、意図に合致している場合。
  • 変更を要求 — High の問題、修正可能な検証失敗、または文書化されていないパターン違反がある場合。
  • ブロック（強い変更要求） — 重大なセキュリティ／データの問題、または根本的に誤ったアプローチがある場合。
  • 明示的な --approve／--request-changes フラグがあれば従います。ただし、未解決の Critical な問題がある場合は承認しません。

フェーズ 6 — GitHub に投稿してレポートを保存する

レポートを .claude/code-reviews/pr-{N}-review.md に書き込みます（概要 · 重要度別の問題と file:line および修正案 · 検証テーブル · 良かった点 · 推奨事項）。その後、投稿します：

# approve
gh pr review {N} --approve --body-file .claude/code-reviews/pr-{N}-review.md
# request changes
gh pr review {N} --request-changes --body-file .claude/code-reviews/pr-{N}-review.md
# or just comment (draft PRs / advisory)
gh pr comment {N} --body-file .claude/code-reviews/pr-{N}-review.md

出力と引き継ぎ

次を出力します：PR 番号／URL · 重要度別の問題件数 · 検証結果 · 推奨事項。その後、次のように引き継ぎます： 「PR に投稿しました。これから人間がコードとこのレビューを確認し、マージします。」 問題がある場合は、レポートを使って piv-fix-review-findings を実行し、その後に検証を再実行するのが自然な次のステップです。

注記

  • 新鮮な視点こそが目的です。クリーンなコンテキストで実行するか、code-reviewer エージェントをクリーンなコンテキストとして使います。コードを書いたセッションでレビューしないでください。精査する代わりに、問題を正当化してしまいます。
  • これはエージェント型のゲートであり、人間の役割に代わるものではありません。人間が承認できるよう、検証済みで優先順位を付けた PR を提示します。さらに掘り下げるには、複数のレビューエージェントを使い、利用する技術スタックに合わせてレビュアーを調整し、その背後に検証ピラミッドを構築します。

コメント

Markdown 対応