shepherd について
shepherdは、プルリクエストをマージ可能な状態まで整えるワークフロースキルですが、自らマージはしません。自動レビューを待って該当する指摘に対応し、レビューとCIを再確認してから人に判断を引き継ぎます。
主な機能
- 01レビューのフィードバックとPRチェックをポーリング
- 02該当するレビュー指摘への対応
- 03修正をコミット・プッシュして再レビュー
- 04引き継ぎ前に最新レビューとCIを確認
- 05マージには人の明示的な承認を要求
活用シーン
- 01新規作成したPRをレビュー可能な状態に整える
- 02自動レビューの指摘に繰り返し対応
- 03最新の変更がレビューとCIを通過したか確認
- 04マージせずに準備完了のPRを人へ引き継ぐ
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/shepherdを入力して読み込まれたか確認します。
詳細
PR のシェパード
あなたの仕事は、この PR をマージ可能な状態にするまで導くことです。レビューを受け、指摘に対応し、検証を済ませ、CI をすべて成功させます。**マージはしません。**マージするかどうかは人間が判断します。
PR を作成する（または、作成されたばかりの PR を引き継ぐ）か、まだであればレビュー可能な状態にしてから、そのステータスをループで粘り強く確認します。すべての自動レビュアー（Bugbot、Cubic など）がレビューを完全に終えるまで、確認を止めないでください。
-
レビュアーを待つ： すべてのレビュアーが完了するまで、
gh pr view/gh pr checks/ レビューコメントを継続して確認します。フィードバックが一部しか揃っていない段階では対応しないでください。まだ実行中のレビュアーがいる場合は、待ち続けてください。 -
フィードバックを仕分ける： 両方のレビューが完了したら、必要な変更を実装します。中程度以上の重要度の問題はすべて修正します。重要度の低い問題は、DRY 違反である場合、またはほかに修正すべき問題がすでにある場合に限り修正します。残っているのが提案や重要度の低い問題だけで、それらがごく軽微な指摘（nit）またはまれなエッジケースに該当する場合は、厳密に対応を見送り、理由を説明して、自律的に作業を続けてください。
-
コミットしてプッシュする： 変更を実装したら、コミットしてプッシュします。その後、手順 1 に戻ります。レビュアーは新しいプッシュを自動的に再レビューします。
-
ループする： どちらのレビュアーからも対応すべき重要な指摘がなくなるまで、クリーンなレビューサイクルが完了するよう繰り返します。
-
マージ可能な状態を二重に確認する： PR をマージ可能な状態と宣言する前に、（a）すべてのレビュアーが最新のコミットを再レビューしたこと、（b）未対応の必須変更がないこと、（c）CI が成功し、PR がマージ可能であることを 2 回確認します。
-
停止して、人間に引き継ぐ： PR がマージ可能な状態であることを報告して待機します。マージしないでください。
絶対ルール：明示的な承認なしにマージしない
gh pr merge、GitHub のマージ API、またはそれに相当する操作を、決して独断で実行しないでください。- 「すべてのチェックが成功」は、マージの許可ではありません。作業を止めて報告してよいという意味です。
- ユーザーが最初に「この PR をマージして」と言った場合でも、「この PR をマージ可能な状態にして」と解釈し、マージする前に明示的な確認を求めてください。
- マージしてよいのは、マージ可能な状態であることを報告した後、ユーザーが「はい、マージして」「そのままマージして」など、曖昧さのない明示的な YES を返した場合だけです。👍 や「OK」だけでは不十分です。不明確な場合は、もう一度確認してください。
- 迷った場合は、マージしないでください。確認を求めてください。
「修正をプッシュした」だけでは完了ではありません。「すべて成功」も完了ではありません。それは人間に引き継ぐ段階です。
早々に作業を止めないでください。独断でマージしないでください。
完了とは、クリーンなレビューサイクルを終え、二重に確認し、マージ可能な状態であることを報告し、人間から明示的な承認を得ることです。