| name | update-pr-description |
| description | 既存PRのdescriptionをコードの現状に合わせて更新する。 「PR説明文を更新」「descriptionを更新」「update-pr-description」「PR本文を直して」 「PRの説明文がコードと合ってない」「descriptionを最新にして」「PRのdescription更新して」 「PRの内容を最新にして」などのリクエストで使用。 PRのURLや番号が提示された場合にも、description更新の文脈であればこのスキルを使うこと。 |
PR Description 更新
既存PRのdescriptionを、コードの実際の変更内容と比較し、不整合を検出して更新する。
PR番号またはURLを引数で受け取る。省略時はAskUserQuestionで確認。
処理フロー
1. PR情報の取得
URLまたはPR番号からowner/repo/numberを抽出する。カレントディレクトリがgitリポジトリ内の場合は --repo を省略可。
並列実行:
gh pr view <number> [--repo <owner>/<repo>] --json title,body,headRefName,baseRefName,commits,files,additions,deletions,changedFiles
gh pr diff <number> [--repo <owner>/<repo>]
2. PRテンプレートの検出
プロジェクト固有のPRテンプレートを動的に検出し、descriptionの期待される構造を把握する。
検出順序（最初に見つかったものを使用）:
| 優先度 | パス |
|---|
| 1 | .github/PULL_REQUEST_TEMPLATE.md |
| 2 | .github/pull_request_template.md |
| 3 | docs/pull_request_template.md |
テンプレートが見つからない場合は、descriptionの見出し構造（## ...）からセクションを推定する。
PR作成ワークフローの検出（任意）:
見つかった場合は、各セクションの書き方の指針として参照する。
| パス |
|---|
.ai/workflows/create-pr-description.md |
.cursor/commands/create-pr-description.md |
3. セクション分解
既存のdescriptionを、テンプレート構造に基づいてセクション単位に分解する。テンプレートの ## 見出しを区切りとして使用する。
4. 差分分析
PR diffと変更ファイル情報を分析し、以下を把握する:
| 分析観点 | 具体的に見ること |
|---|
| 変更ファイル | 追加・変更・削除されたファイルの一覧 |
| 変更の種類 | 新規追加、修正、リファクタ、テスト追加、設定変更 |
| 主要な変更内容 | クラス・メソッド・APIの追加/変更/削除 |
| テスト | テストファイルの変更内容 |
| DB変更 | マイグレーションファイルの有無と内容 |
5. セクションごとの整合性チェック
各セクションについて、実際のコード変更との整合性を判定する。
| セクション例 | チェック観点 |
|---|
| やったこと / Changes | diffに含まれる変更がすべて記載されているか。記載はあるが実際にはない変更はないか |
| やらなかったこと / Out of scope | 明らかにスコープ外にした事項の記載漏れはないか |
| 確認方法 / How to verify | 実装した機能に対応する確認手順が書かれているか |
| QA観点 / Testing scope | 影響範囲が実際の変更と一致しているか |
| 関連リンク / Links | 既存記載の維持（変更しない） |
| キャプチャ / Screenshots | 既存記載の維持（変更しない） |
判定結果の分類:
| 判定 | 意味 | 対応 |
|---|
| 整合 | 記載内容がコード変更と一致 | 変更なし |
| 不足 | コード変更に対応する記載が不足 | 追記を提案 |
| 不正確 | 記載内容がコード変更と矛盾 | 修正を提案 |
| 過剰 | コードに存在しない変更が記載されている | 削除を提案 |
| 未確認 | コードから判断困難（関連リンク、キャプチャ等） | スキップ |
6. 更新案の提示
変更がない場合: 「descriptionは現在のコード変更と整合しています。更新は不要です。」と報告して終了。
変更がある場合: 以下の形式で変更提案を表示する。
## PR Description 更新提案
**PR**: #<number> <title>
**ブランチ**: <head> → <base>
### 変更サマリー
| セクション | 判定 | 変更内容 |
|-----------|------|---------|
| やったこと | 不足 | 〜の記載を追加 |
| 確認方法 | 不正確 | 手順を実装に合わせて修正 |
| やらなかったこと | 整合 | 変更なし |
### 各セクションの変更詳細
#### 「やったこと」セクション（不足）
**理由**: diffに〜の変更が含まれるが、descriptionに記載がない
**現在の記載**:
> {現在のセクション内容}
**提案する記載**:
> {更新後のセクション内容}
出力ルール:
| ルール | 詳細 |
|---|
| 変更なしセクション | サマリー表に「整合 / 変更なし」として表示するが、詳細は省略 |
| 変更理由 | 各セクションの変更に必ず「理由」を明記する。ユーザーが「なぜ不整合と判断したか」を理解できるようにするため |
| 既存記載の尊重 | 正確な記載はそのまま残す。文体・トーンを維持する |
| テンプレート構造の維持 | セクションの追加・削除・順序変更はしない |
| HTMLコメント | テンプレートのHTMLコメント（<!-- ... -->）は元の状態を維持 |
| チェックボックス | QA result OKラベル等のチェック状態は変更しない |
| 確認方法の推測 | コード変更から手動確認手順を推測する。API変更ならエンドポイントのテスト手順、UI変更なら操作手順、内部リファクタなら既存機能の動作確認手順 |
7. ユーザー確認
提案した変更内容についてユーザーの確認を取る。
| ユーザーの応答 | 対応 |
|---|
| 承認（y, OK, いいよ 等） | Step 8へ進む |
| 修正依頼 | 指摘箇所を修正して再提示 |
| 一部採用 | 指定されたセクションのみ反映 |
| 却下 | 「更新をキャンセルしました」と報告して終了 |
ユーザーの明示的な承認なしに gh pr edit を実行しない。PRのdescription更新はチームメンバーに影響する変更であり、慎重に行う必要がある。
8. PR descriptionの更新
承認された更新内容を反映する。
gh pr edit <number> [--repo <owner>/<repo>] --body "$(cat <<'EOF'
{更新後のdescription全文}
EOF
)"
更新後、PRのURLとともに変更したセクションのサマリーを報告する。
エラー処理
| エラーパターン | 対処 |
|---|
| PR番号・URLが不正 | URLの形式を確認し、ユーザーに再入力を依頼 |
| アクセス権なし（HTTP 404） | gh auth statusで認証確認を案内 |
| diffが取得できない | gh apiでファイル単位のdiffを取得 |
| descriptionが空 | PRテンプレートをベースに新規作成を提案。ただしこのスキルの主目的は「更新」であり、初回作成はPR作成ワークフローの使用を案内 |
| テンプレートがない | description内の ## 見出しからセクションを推定して処理を続行 |
gh pr edit 失敗 | エラー内容を報告。権限問題の場合は手動更新を案内 |
他スキルとの使い分け
| 操作 | 使用先 |
|---|
| 既存PR descriptionの更新 | このスキル |
| PR descriptionの新規作成 | PR作成ワークフロー（プロジェクト固有） |
| PRの全体レビュー | /reviewing-pr |
| PRレビューコメントへの対応 | /review-pr-comments |
| PR/Issue情報取得・作成 | /github |
| commit + push | /push |
