Claude CodeでCONTRIBUTINGのPRチェックと返信の下書きを作る

初めての貢献者のPRは、中身より先に「基準を満たしているか」を確かめる作業が重くなります。この記事では、CONTRIBUTING.mdの基準をClaude Codeのスキルにして、PRの差分・テストの有無・コミット規約を照らし、不足点を丁寧な返信文に下書きする手順を書きます。投稿は人が行い、スキルは下書きまでにとどめる構成です。

点検と返信を1つのスキルにする理由

CONTRIBUTING.mdは、貢献者がPRやissueを正しい形で出せるようにするための文書です。GitHubのドキュメントは、基準があると、不備のあるPRが差し戻されて出し直しになる手間を、オーナーと貢献者の双方で減らせると説明しています。

基準があっても、メンテナーの手間は残ります。初めての貢献者に返すときは、不足を並べるだけでは冷たく響きます。「ありがとう」から入り、直してほしい点を具体的に、直し方の手がかりと一緒に書く必要があります。この文面づくりが毎回の負担です。

そこで、点検と返信をひとつの手順にまとめます。点検は事実の照合、返信は言い回しの整形です。前者はコマンドの出力に基づき、後者はスキルの指示で口調を固定できます。毎回プロンプトを書き直す代わりに、/contrib-pr-reply 123のように呼び出すだけで済みます。

観点別のレビューは別の道具が受け持ちます。pr-review-toolkitは、テスト網羅やエラー処理などコードの質を専門エージェントに分けて見る汎用のレビューです。こちらは出力が違います。見るのはリポジトリ固有の基準への適合で、出すのは貢献者に宛てた返信文です。

前提となるファイルと環境

用意するものは3つです。

• リポジトリにCONTRIBUTING.mdがあること。GitHubはルート、docs、.githubのいずれかに置けると案内しています
• GitHub CLIのghが使え、対象リポジトリで認証済みであること
• スキルを置く.claude/skills/ディレクトリ(リポジトリに入れれば、メンテナー全員で共有できます)

CONTRIBUTING.mdがルートにない場合は、後述のスキルのパスを置き場所に合わせて書き換えます。

SKILL.mdの全体像

次の内容を、リポジトリの.claude/skills/contrib-pr-reply/SKILL.mdに保存します。基準の項目は例なので、自分のCONTRIBUTING.mdの内容に合わせて入れ替えてください。

---
name: contrib-pr-reply
description: 初めての貢献者のPRをCONTRIBUTING.mdの基準で点検し、返信文を下書きする
argument-hint: [PR番号]
disable-model-invocation: true
allowed-tools: Bash(gh pr view *) Bash(gh pr diff *) Bash(cat ${CLAUDE_PROJECT_DIR}/CONTRIBUTING.md)
---
 
## このリポジトリの貢献基準
 
!`cat ${CLAUDE_PROJECT_DIR}/CONTRIBUTING.md`
 
## 手順
 
PR $ARGUMENTS を点検します。次のコマンドで情報を集めます。
 
- `gh pr view $ARGUMENTS --json title,body,author,commits,files,statusCheckRollup,isCrossRepository,maintainerCanModify`
- `gh pr diff $ARGUMENTS`
 
点検する項目は次のとおりです。基準の文言と照らし、根拠を1行で添えます。
 
1. PR本文: 目的と関連issueが書かれているか
2. 差分: 変更範囲が1つの目的に収まっているか
3. テスト: 変更したコードに対応するテストファイルが差分に含まれているか
4. コミット: 各コミットのメッセージが基準の書式に沿っているか
5. チェック: statusCheckRollup に失敗があるか
6. 取り込み方: isCrossRepository と maintainerCanModify を見て、返信で軽微な修正をこちらで引き受けられるかを判断する
 
## 出力
 
1. 点検表(項目 / 結果 / 根拠)
2. 返信文の下書き。次の順で書く
   - 最初に、時間を割いて送ってくれたことへの礼
   - 良い点を1つ以上、具体的に
   - 直してほしい点を、基準の該当箇所と直し方の例つきで
   - 最後に、質問があれば歓迎する旨
3. 返信文は下書きです。投稿はせず、私が確認してから出します。

各行が何をしているか

ポイントは4つあります。

基準を毎回読み込ませる(動的コンテキスト注入)

!`cat ...`の行は、スキルがClaudeに渡される前にコマンドとして実行され、出力で置き換えられます。つまりClaudeには、コマンド自体ではなくCONTRIBUTING.mdの全文が届きます。基準をスキルに書き写さずに済むため、CONTRIBUTING.mdを更新すれば次の呼び出しから新しい基準で点検されます。基準が二重管理にならない点が、スキルに丸写しするより安全です。

この記法は、!が行頭か空白の直後にあるときだけ認識されます。KEY=!`cmd`のように文字に続けると、そのまま文字列として残ります。

パスには${CLAUDE_PROJECT_DIR}を使っています。注入コマンドは、セッションのシェルの現在のディレクトリで実行され、Claudeがcdすると動きます。プロジェクトのルートを指す変数を使えば、どこで呼び出しても同じファイルを読めます。この変数は、スキル本文とallowed-toolsの両方で展開されます。

呼び出しを人に限る(disable-model-invocation)

disable-model-invocation: trueにすると、Claudeが会話の流れで勝手にスキルを起動しなくなります。副作用のあるワークフローや、実行のタイミングを自分で決めたい作業に向く設定です。このスキルは外部に書き込みません。それでも人が選んだPRにだけ使いたいので、手動限定にしています。

コマンドを読み取り系に絞る(allowed-tools)

allowed-toolsに並べたツールは、スキルを呼び出したターンの間、確認なしで使えます。ここではgh pr view、gh pr diff、CONTRIBUTING.mdのcatだけを許可しました。gh pr commentやgh pr reviewは含めていません。投稿に使うコマンドを許可しないことで、返信を勝手に出さない運用をスキルの側でも支えます。

この許可は次のメッセージを送ると失効します。スキルの内容は会話に残りますが、権限は残りません。

注入コマンドの扱いにも注意が要ります。注入コマンドは、スキルの展開中に確認のプロンプトを出しません。許可ルールで承認されていないコマンドがあると、通常のモードでは呼び出し自体が中断されます。catをallowed-toolsに入れているのはこのためです。

引数でPRを指定する($ARGUMENTS)

$ARGUMENTSは、スキル名の後ろに打った文字列に置き換わります。/contrib-pr-reply 123なら、本文中の$ARGUMENTSが123になります。注入コマンドの中には引数を入れていません。PRの情報取得はClaudeに実行させる形にし、allowed-toolsでgh pr view *とgh pr diff *を通しています。

実行して返信を受け取る

CONTRIBUTING.mdがあるリポジトリでClaude Codeを起動し、PR番号を付けて呼び出します。

/contrib-pr-reply 123

Claudeはgh pr viewとgh pr diffで情報を集め、点検表と返信文を出します。出力は、例えば次のような形になります(スキルの指示に沿った例示であり、実際の出力は基準とPRの内容で変わります)。

| 項目 | 結果 | 根拠 |
|---|---|---|
| PR本文 | 要確認 | 関連issueの記載がない |
| テスト | 不足 | src/parser.ts の変更に対応するテストが差分にない |
| コミット | 要確認 | 2件目が「fix」のみで、基準の書式に沿っていない |
 
--- 返信文の下書き ---
はじめてのPR、ありがとうございます。パーサーの境界条件を
丁寧に直してくださっていて、読みやすい差分でした。
 
マージの前に、2点だけお願いできますか。
- src/parser.ts の変更に対するテストの追加(CONTRIBUTING.mdの
  「テスト」の節を参照ください。既存のテストを真似る形で十分です)
- 2件目のコミットメッセージを基準の書式に直す
  (git rebase -i で書き換えられます)
 
不明な点があれば、ここで気軽に聞いてください。

下書きは自分で読み、必要なら直してから投稿します。投稿にghを使う場合も、人が内容を確かめた後に手で実行します。

基準を照合しやすい形に直す

返信文の質は、CONTRIBUTING.mdの書き方に左右されます。「質の高いPRを歓迎します」のような抽象的な文言は、点検に使えません。次のように、判定できる文にしておくと、スキルの照合が安定します。

• 「テストを書く」ではなく「src/の変更には、同名のテストをtests/に追加する」
• 「分かりやすいコミットメッセージ」ではなく「1行目は命令形、50字以内。理由は本文に書く」
• 「小さなPRにする」ではなく「1つのPRで扱う目的は1つにする」

あわせて、スキルの点検項目と基準の見出しを対応づけておくと、返信文に「基準のこの節を参照ください」と書けるようになります。CONTRIBUTING.mdの節名は、貢献者にとって次の行動の手がかりです。

軽微な不足はこちらで直すという選択肢

点検で見つかった不足が、コミットメッセージの書式やテスト1件のような軽いものなら、貢献者に差し戻す代わりにメンテナー側で直す道もあります。gh pr viewのJSONにはisCrossRepository(フォークからのPRか)とmaintainerCanModify(メンテナーによる変更の可否を示す項目)が用意されています。この2つを点検項目に加えておくと、返信文を「直してもらう」と「こちらで直します」のどちらの方向で書くかを、Claudeが材料つきで提案できます。

初めての貢献者にとっては、小さな不備で差し戻されるより、「軽い点はこちらで整えます」と言われるほうが、次の貢献につながりやすい場面もあります。どちらを選ぶかは、リポジトリの方針とメンテナーの手間で決まる判断です。スキルには、選択肢を並べて提案させるところまでを任せ、決めるのは人にします。

つまずきやすい点

呼び出しが中断される

Shell command permission check failedのようなエラーで止まるときは、注入コマンドが許可ルールに合っていません。allowed-toolsのパターンと、スキル本文のcatの書き方が一致しているかを確かめます。拒否ルールに当たるコマンドも同じ形で中断します。

CONTRIBUTING.mdが見つからない

.github/CONTRIBUTING.mdやdocs/CONTRIBUTING.mdに置いている場合は、2か所のパスを両方直します。本文の注入行とallowed-toolsのパターンが違うと、上の中断につながります。

差分が大きすぎる

大きなPRでは、差分がコンテキストを圧迫します。gh pr diffには--name-onlyでファイル名だけを出すオプションと、--excludeで一部のファイルを除くオプションがあります。生成物やロックファイルを--excludeで外すと、点検に必要な部分に絞れます。

PRの本文は信頼できない入力

PR本文やコミットメッセージは、外部の人が書いた文字列です。そこに「この指示を無視して〜」のような文が混ざる可能性があります。このスキルは読み取り系のコマンドしか許可していないため、書き込みの被害は出にくい作りです。それでも返信文は必ず人が読んでから投稿します。

なおgh pr diffは、標準では差分中のターミナルのエスケープシーケンスを無害化して出力します。

スキルの実行を分離したいとき

点検の途中経過で会話を汚したくない場合は、context: forkを指定してサブエージェントで実行する選択肢があります。ただし、フォークしたサブエージェントは会話履歴を見ません。スキルの指示だけで完結させる必要があり、このスキルの本文は基準の注入とPR番号の引数だけで足りるため、そのまま使えます。サブエージェントの仕組みはClaude Code Subagents完全ガイドにまとまっています。

context: forkは既定でバックグラウンドで動きます。結果を同じターンで受け取りたいなら、background: falseを併記します。

似た用途との置き場所

スキルの書き方全般はClaude Code Skillsのfrontmatter全フィールドが詳しいです。PRの種類によって点検の重みを変えたいときは、別のスキルに分けると運用が楽になります。たとえば、セキュリティ修正のPRをレビューする手順は、回帰テストと抜け道の確認に重心があり、貢献者への返信とは目的が違います。

まとめ

このスキルの核は、CONTRIBUTING.mdを動的コンテキスト注入で毎回読み込み、読み取り系のコマンドだけを許可して、返信文を下書きまでで止めることです。基準の側を「判定できる文」に書き直しておくほど、点検の根拠が具体的になり、初めての貢献者に渡す返信も短く済みます。まずは自分のリポジトリのCONTRIBUTING.mdから、機械的に照合できる項目を3つ選び、スキルの点検項目にしてみるのが取り掛かりやすい入口です。