SKILL.md
PR Respond
概要
GitHub Pull Requestのレビューコメントに対して、適切な判断と返信を行い、スレッドをresolveするまでの一連のワークフローをサポートするスキル。
重要: GitHub API直接呼び出しの禁止
以下のコマンドは絶対に使用しないこと:
# 禁止: gh api を直接使用
gh api /repos/{owner}/{repo}/pulls/{pr_number}/comments
gh api graphql -f query="..."
gh api /repos/{owner}/{repo}/pulls/comments/{comment_id}/replies -X POST
# 代わりに: 必ず ./scripts/ 配下のスクリプトを使用する
./scripts/get-review-comments.sh owner repo 123
./scripts/reply-to-comment.sh owner repo 123 comment_id "返信内容"
理由:
- スクリプトはエラーハンドリング、入力検証、出力整形を含む
- API仕様の変更時にスクリプトのみ修正すれば対応可能
- 一貫した出力形式でワークフローの自動化が容易
利用可能なスクリプト
このスキルでは、./scripts/ 配下の以下のスクリプトを使用する:
| スクリプト | 役割 |
|---|---|
parse-pr-url.sh |
PR URLからowner/repo/pr_numberを抽出 |
get-review-comments.sh |
レビューコメント一覧を取得 |
reply-to-comment.sh |
コメントに返信を投稿 |
get-review-threads.sh |
レビュースレッドID・状態を取得(GraphQL) |
resolve-threads.sh |
スレッドを一括resolve(GraphQL) |
ワークフロー
Step 1: PR情報の取得
PR URLからリポジトリ情報を抽出する。
# PR URLをパース
./scripts/parse-pr-url.sh "https://github.com/owner/repo/pull/123"
# Output: {"owner": "owner", "repo": "repo", "pr_number": 123}
Step 2: レビューコメントの取得と確認
PRのレビューコメントを取得し、内容を確認する。
# 詳細なJSON形式で取得
./scripts/get-review-comments.sh owner repo 123
# 簡潔なサマリー形式で取得
./scripts/get-review-comments.sh owner repo 123 --format=summary
各コメントについて以下を確認:
- コメントID
- 対象ファイルと行番号
- 指摘内容
Step 3: 対応判断
各レビューコメントについて、対応するかどうかを判断する。
対応すべきコメント
- 明確なバグや問題点の指摘 → 修正してコミット
- セキュリティ上の懸念 → 必ず対応
- 具体的な改善提案(suggestion付き) → 基本的に採用
対応を検討すべきコメント
以下の基準で判断:
テストカバレッジの指摘
- 内部関数でAPIモックが必要 → 費用対効果が低い、対応しない
- 既存のロジックが十分テストされている → 対応不要の可能性
- プロジェクト規模が小さい → 過剰品質になる可能性
エラーハンドリングの指摘
- 関数内部と呼び出し側の両方で指摘 → 重複を避け、呼び出し側のみ対応
- すでに別の箇所で対応済み → 対応済みであることを説明
判断の原則
- 重複を避ける: 同じエラーハンドリングを複数箇所に追加しない
- 費用対効果: テストの実装コストと効果を天秤にかける
- 実用性優先: 理想論より実用上の問題解決を優先
Step 4: 必要に応じてコードを修正
対応が必要なコメントについて、コードを修正してコミットする。
# 修正をコミット
git add <modified_files>
git commit -m "fix: <コミットメッセージ>
<修正内容の説明>
Co-Authored-By: Claude Sonnet 4.5 <[email protected]>"
# リモートにpush
git push origin <branch_name>
Step 5: 各コメントに返信
すべてのレビューコメントに対して、返信を作成する。すべてのコメントに返信することが重要。
返信パターン
対応済みの場合:
修正しました (<commit_hash>)
<具体的な修正内容の説明>
対応しない場合:
この件は対応しません
**理由:**
- <理由1>
- <理由2>
<補足説明>
間接的に対応済みの場合:
対応済み (<commit_hash>)
コメント#X の修正で、<具体的な対応内容>。これにより<問題が解決した理由>。
返信の実行
# コメントに返信(コメントIDを使用)
./scripts/reply-to-comment.sh owner repo 123 <comment_id> "返信内容"
Step 6: レビュースレッドをresolve
すべてのコメントに返信したら、レビュースレッドをresolve状態にする。
# スレッド情報を取得
./scripts/get-review-threads.sh owner repo 123
# 未解決のスレッドのみ取得
./scripts/get-review-threads.sh owner repo 123 --unresolved-only
# スレッドをresolve(単一)
./scripts/resolve-threads.sh "PRRT_kwDOQ8GWfs5p4t_j"
# スレッドを一括resolve(複数)
./scripts/resolve-threads.sh "PRRT_kwDOQ8GWfs5p4t_e" "PRRT_kwDOQ8GWfs5p4t_h" "PRRT_kwDOQ8GWfs5p4t_j"
ベストプラクティス
返信の品質
- 具体的に: 何を修正したか、なぜ対応しないかを明確に
- コミットハッシュを含める: 修正内容を追跡可能にする
- 敬意を持って: 対応しない場合も丁寧に理由を説明
効率的な対応
- 一度に全コメントを確認: 重複や関連性を把握
- 関連コメントをまとめて対応: 同じ修正で複数の指摘に対応できる場合
- 返信とresolveを同時に: 返信後すぐにresolveすることで漏れを防ぐ
判断の透明性
- 対応しない理由は具体的に説明
- プロジェクトの規模や状況を考慮
- 実用上の問題がないことを明確に
参考資料
詳細なスクリプト使用例は [references/github-api-examples.md](references/github-api-examples.md) を参照してください。