Menü
GitHub PR URLを受け取り、レビュアー向けに日本語でサマリーを生成する。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | pr-summary |
| description | GitHub PR URLを受け取り、レビュアー向けに日本語でサマリーを生成する。 |
| license | MIT |
| argument-hint | [PR URL] [--dry-run] |
| context | fork |
| disable-model-invocation | true |
| model | sonnet |
予備知識のないレビュアーがPRの目的・変更内容・注意点をすぐに把握できるサマリーを生成する。
--dry-run フラグを確認する
--dry-run が含まれる場合 → ドライランモード（サマリーをチャット画面に出力するのみ。PR本文は更新しない）mcp__github__update_pull_request でPR本文を書き換える。add_issue_comment でコメントを追加するのではない）GitHub MCPでPR情報を並列取得する
mcp__github__pull_request_read の get メソッドでPRのメタ情報（タイトル・本文・統計）を取得mcp__github__pull_request_read の get_diff メソッドでdiffを取得mcp__github__list_commits（owner・repo・pullNumber を渡す）でコミットメッセージを取得get_diff）である（詳細は「変更内容」セクション）。get でPR本文（body）が空または取得できなかった場合も、diffとコミットメッセージから背景・意図を構成できるサマリーを構成する
以下の3セクションで構成する。各セクションは必要な情報量に応じて伸縮させてよい。情報が少なければ箇条書き1〜2行でも構わないし、複雑なPRなら詳しく書く。
なぜこのPRが必要か。どんな問題を解決するか。コードを読まなくても背景が伝わるように書く。技術的な前提知識が必要な場合は簡単に補足する。背景・意図はdiffには現れにくいため、コミットメッセージ（本文含む）とPR本文を主な根拠にして書く。
取り上げる対象は base↔head の最終diff（get_diff の結果）に現れる変更に限る。 PR内で一度加えて後続コミットで作者自身が取り消した／作り直した変更（同一PR内で自己解決した中間的な変更）は、最終diffに残らないため「変更内容」には含めない。コミットメッセージは Why（なぜ変えたか）の根拠として参照するが、What（何を取り上げるか）の対象範囲を決めるのは最終diffである。コミットメッセージに痕跡があっても最終diffに現れない変更は書かない。
人間のレビュアーが知っておくべき変更にフォーカスする。すべての変更を網羅する必要はなく、ファイルや差分を一つずつ羅列しない。以下のような変更を優先的に取り上げる：
逆に、自明なリネーム・フォーマット修正・タイポ修正・機械的な追従変更などは、まとめて1行触れるか省略する。「何のために何を変えたか」が伝わる粒度で書く。
加えて、何を変えたか（What）だけでなく、**なぜその方法を選んだか（作者の設計判断・トレードオフ）**を言語化する。複数の選択肢がありえた箇所では「Aではなく B を選んだ」という判断が伝わるように書く。判断の意図が出力に現れることで、レビュアーはその判断の妥当性を評価できる。
判断の根拠は、まずコミットメッセージの本文に書かれていないか確認する（作者が意図を残す主要な場所）。コミットメッセージにもdiffにも根拠が見当たらない場合は、推測で断定せず、その旨を残してレビュアーが確認できるようにする。
人間のレビュアーにしか判断できない観点に絞る。AIレビューやCI（Lint・型チェック・テスト・静的解析・脆弱性スキャンなど）で検出可能な内容は書かない。以下のような、人の判断や文脈理解が必要な観点を優先する：
「Null チェックが漏れているかも」「テストが足りないかも」のような自動検出可能な指摘は書かない。判断の目安：ツールが機械的に判定できるもの（構文エラー・未使用変数・型の不整合・テストカバレッジ不足など）は除外し、仕様の妥当性・ビジネスルールへの適合・ステークホルダーへの影響など人の文脈理解が不可欠なものだけを書く。該当する観点がなければセクションごと省略してよい。
手順3でサマリーを書き上げたら、出力・PR本文更新の前に、レビュアー（読み手）の視点でサマリー全体を一度読み返し、シニアエンジニアならわざわざ言及しない些細な記述を削ぎ落とす。手順3の各セクション基準が「書く最中の粒度指針」であるのに対し、このステップは「書き上がったサマリー全体を俯瞰して、読み手の負荷になる些末な記述を取り除く」最終工程である。
判定の原則：
推敲後のサマリーを、後続の出力（ドライラン）／PR本文更新の入力とする。
ドライランでない通常モードの場合、サマリー生成後に以下を実行する。基本方針は 既存本文を全置換 し、別の自動化ツールが埋め込んだブロックのみを保持することである。
更新後のPR本文を組み立てる
まず既存本文（get で取得済み）から、別ツールが埋め込んだコメント囲みブロックを検出し、開始・終了のコメントマーカーを含めたブロック全体を、内容を一切変更せず原文のまま退避する。
<!-- start xxx --> 〜 <!-- end xxx -->（xxx は任意のツール名）。<!-- begin/end --> 等の別記法）も自動化ブロックとみなして保持対象にする。<!-- start xxx --> / <!-- end xxx --> などの開始・終了マーカー）を含めてブロック全体を丸ごと保持する。マーカーを除去したり中身だけを取り出したりしてはならない。別ツールはこの囲みコメントを目印に自分のブロックを再検出・更新するため、マーカーが落ちるとそのツールが動作しなくなる。<!-- pr-summary-start/end -->）は自動化ブロックとして扱わない。その上で、現在のPR本文に基づいて以下の3パターンで処理する：
パターンA: 既存本文に <!-- pr-summary-start --> と <!-- pr-summary-end --> の両マーカーが存在する場合
→ マーカー間の内容だけを新しいサマリーで置き換える（マーカー自体は維持する）。マーカー外の既存本文・自動化ブロックはそのまま温存する（このパターンでは全置換しない）。
パターンB: pr-summaryマーカーが無く、自動化ブロックが1つ以上検出された場合 → 既存本文は破棄して全置換する。サマリーブロックを本文の先頭に配置し、改行2つを挟んで、退避した自動化ブロックを本文の末尾に集約する（複数あれば元の出現順を保ち、各ブロック間は改行2つで区切る）。退避したブロックは囲みコメント込みで原文のまま再配置し、マーカーや中身を改変しない。
パターンC: pr-summaryマーカーも自動化ブロックも無い場合 → 既存本文を全置換し、サマリーブロックのみを本文にする。
サマリーブロックの形式：
<!-- pr-summary-start -->
（サマリー本文）
<!-- pr-summary-end -->
ユーザーに確認を求める
更新前に更新後のPR本文全体をチャットに出力し、ユーザーの確認を求める。パターンB・Cでは既存本文を全置換するため、差分ではなく全体を見せて意図しない情報の喪失がないことを確認することが特に重要。パターンB・Cで既存本文に人間が手書きしたコンテンツ（自動化ブロック以外の部分）が含まれる場合は、確認画面でその旨を明示し「この内容は削除されます」と伝えること。
mcp__github__update_pull_request を実行するPR本文を更新する
mcp__github__update_pull_request（owner・repo・pullNumber・body を渡す）で更新し、成功後「PR本文を更新しました: （PR URL）」と報告する。
##（H2）を使うGitHub PRのレビューコメントのうち、Hide・解決済みでないものだけを抽出して対応する。
Commit, push, and create or update a PR
GitHub Actions の CI 失敗を、失敗ジョブの特定 → ログからの原因抽出 → 原因分類 → ローカル再現 → 修正 → 検証まで体系的に進めるスキル。特に、失敗ログのノイズに埋もれて原因が見えないとき、環境依存でフレーキーに落ちているときに役立つ。修正に人の判断が必要な場合は、対話モードでは確認して中断し、--non-interactive 指定時はPRにコメントを投稿して中断する。
`bundle exec erblint app` の既存違反をファイル単位で無効化する todo ファイル群 （`.erb_lint_todo.yml` / `.erb-lint-rubocop-todo.yml`）を生成・初期化する手順。手動起動専用 （`/erblint-todo-init`）。todo を作り直したいときなど、一回性のセットアップ作業でのみ使う。 rubocop 単体・haml-lint・herb-lint の運用には使わない。
プランモードで作成したプランファイル（Markdown）の内容に沿って実装を行う。実装フェーズを軽量なsonnetモデルで実行し、コスト・速度を最適化する。引数でプランファイルのパスを指定できる。省略時は直近のセッションログから対象プランを自動特定してユーザーに確認する。コミット・push・PR作成は、プランに明記されている場合のみ実施する。
APM パッケージ由来ルール（.claude/rules/*.md）と重複するプロジェクト固有ローカルルール （.apm/instructions/*.local.instructions.md）を検出し、ローカル側を削除・縮小する。未管理ルールの 新規移行は行わない（それは migrate-rules-to-apm の役割）。手動実行専用（自動トリガーしない）。