smithery.ai

pr-respond

PRにレビューコメントが付いたら呼び出す。レビュー対応、返信作成、スレッドresolveまで一貫してサポート。「レビュー対応して」「PRレビューに返信」で起動。

First seen Mar 27, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Skill metadata

Parsed from SKILL.md frontmatter.

Allowed toolsBash(./scripts/*:*), Bash(gh pr view:*), Bash(git:*), Read, Edit, Glob, Grep

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,440 B
  • docs SUMMARY.md 236 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

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モックが必要 → 費用対効果が低い、対応しない
  • 既存のロジックが十分テストされている → 対応不要の可能性
  • プロジェクト規模が小さい → 過剰品質になる可能性

エラーハンドリングの指摘

  • 関数内部と呼び出し側の両方で指摘 → 重複を避け、呼び出し側のみ対応
  • すでに別の箇所で対応済み → 対応済みであることを説明

判断の原則

  1. 重複を避ける: 同じエラーハンドリングを複数箇所に追加しない
  2. 費用対効果: テストの実装コストと効果を天秤にかける
  3. 実用性優先: 理想論より実用上の問題解決を優先

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"

ベストプラクティス

返信の品質

  • 具体的に: 何を修正したか、なぜ対応しないかを明確に
  • コミットハッシュを含める: 修正内容を追跡可能にする
  • 敬意を持って: 対応しない場合も丁寧に理由を説明

効率的な対応

  1. 一度に全コメントを確認: 重複や関連性を把握
  2. 関連コメントをまとめて対応: 同じ修正で複数の指摘に対応できる場合
  3. 返信とresolveを同時に: 返信後すぐにresolveすることで漏れを防ぐ

判断の透明性

  • 対応しない理由は具体的に説明
  • プロジェクトの規模や状況を考慮
  • 実用上の問題がないことを明確に

参考資料

詳細なスクリプト使用例は [references/github-api-examples.md](references/github-api-examples.md) を参照してください。