PRアップデーター

既存のプルリクエストにフォローアップ変更をプッシュし、その説明を新しい作業を反映するように更新します。

---

ワークフロー

ステップ1: 事前チェック

1. GitHub CLIの認証を確認する — gh api user --jq '.login' を実行してCLIが認証されていることを確認します。失敗した場合、ユーザーは最初に gh auth login を実行する必要があります。
2. 既存のPRを検索する — gh pr view --json number,title,body,url,baseRefName,state を実行して、現在のブランチのPRを検索します。PRが存在しない場合は中止し、代わりに /create-pr の使用を提案します。state フィールドを確認します。OPEN ではない場合は中止し、PRがすでにマージまたはクローズされていることをユーザーに通知します。
3. Gitの状態が清潔であることを確認する — git status を実行してコミットされていない変更がないことを確認します。コミットされていない変更がある場合は、最初に /commit スキルを実行してそれらをコミットします。
4. サブモジュールを同期する — まず .gitmodules が存在するかどうかを確認します。存在する場合は git submodule update --init --recursive を実行します。存在しない場合はこのステップをスキップします。

ステップ2: ベースブランチとの同期

フィーチャーブランチがベースブランチに最新の状態であることを確認して、マージコンフリクトを回避します:

1. 最新リモートをフェッチする — git fetch origin <base-branch> を実行します(PRメタデータからベースブランチを使用)
2. 分岐を確認する — git log HEAD..origin/<base-branch> --oneline を実行してベースブランチに新しいコミットがあるかどうかを確認します
3. 必要に応じてリベースする — ベースブランチに新しいコミットがある場合: a. git rebase origin/<base-branch> を実行します b. コンフリクトを解決する — リベースがコンフリクトに遭遇した場合:
   • コンフリクトしているファイルを読み、両側を理解します
   • コンフリクトをユーザーに表示します — 両側を表示し、どちらのバージョンを保持するかを尋ねます。コンフリクトを黙って解決しないでください。
   • 解決されたファイルをステージします: git add <file>
   • 継続します: git rebase --continue
   • リベースが完了するまで繰り返します
4. 清潔な状態を確認する — git status を実行して未解決のコンフリクトが残っていないことを確認します
5. ブランチをプッシュする — git push を実行します。リベースが履歴を変更した場合は、代わりに git push --force-with-lease を使用します。--force-with-lease が失敗した場合、他のユーザーがこのブランチにプッシュしています。リモートブランチをフェッチし(git fetch origin <branch>)、分岐を確認し(git log HEAD..origin/<branch> --oneline)、ユーザーに進め方を尋ねます — 他の寄稿者の変更を最初に統合する必要があるかもしれません。

ステップ3: 新しい変更を分析する

現在PRにある変更の全体的な範囲を理解します:

1. git log origin/<base-branch>..HEAD --oneline を実行してこのブランチのすべてのコミットを確認します
2. git diff origin/<base-branch>...HEAD --stat を実行して変更されたファイルの高レベルな概要を取得します
3. git diff origin/<base-branch>...HEAD を実行して完全なdiffを読みます。注: 3ドット(...)構文は意図的です — このブランチがベースから分岐してから導入された変更のみを表示し、このPRの一部ではないベースブランチのコミットは除外します。
4. 変更のタイプを識別します: feat、fix、refactor、docs、chore など。
5. 既存のPRタイトルと本文を確認する — 現在のPRタイトルと本文(ステップ1から)を完全なdiffと比較します。正確に説明されているもの、欠落しているもの、古いもの、または関連がなくなったものを明記します。

重要: 最新のコミットだけでなく、すべてのコミットを確認してください。更新されたPR説明はブランチ全体を反映する必要があり、新しい追加のみではありません。

ステップ4: PR説明を更新する

タイトル

• 70文字以下
• 従来型のプレフィックスを使用: feat:、fix:、refactor:、docs:、chore:
• 既存のPRタイトル(ステップ1から)を確認します。変更の全体的な範囲を正確に反映している場合は、それを保持します。範囲が変わったまたはタイトルが誤解を招く場合は、更新します。

本文

既存のPR本文(ステップ1から)を確認し、ブランチの現在の状態を反映するように更新します。まだ正確なコンテンツ(例: コンテキスト、リンク、決定)は、最初から書き直すのではなく保持します。このテンプレートを使用します — 詳細はPRの複雑さでスケールします:

## Summary
<1〜5個の箇条書き: 何が変わったか、そしてなぜか説明 — ブランチのすべての変更をカバー>

## Changes
<何が変更されたかの分類されたリスト — 領域/関心ごとにグループ化>

## Diagrams
<オプション — ワークフローまたはアーキテクチャの変更を視覚的に明確にするときはMermaid図を含める>

## Test Plan
<変更がどのように検証されたか — 手動テストステップ、実行された自動テスト、curlコマンドなど>

本文のガイドライン:

• 目的を明確に述べてください — 何であるかではなく、なぜであるかを説明してください
• ブランチのすべての変更をカバーします。最新のコミットだけではなく
• 関連する問題/ドキュメントへのリンクを含むコンテキストと背景を提供します
• ワークフローまたはアーキテクチャの説明を簡素化するときはMermaid図を含めます
• PRを単一の関心事に集中させます — PRが大きすぎる場合は分割を提案します
• PR本文を上書きする前に、既存の本文を標準テンプレートセクション(Summary、Changes、Diagrams、Test Plan)と比較します。PR作成後に手動で追加されたセクションまたはコンテンツ(例: レビュアーノート、デプロイメントチェックリスト、リンクされたディスカッション)にフラグを立てて、ユーザーにそれらを保持するかどうかを尋ねます。
• 「Generated with Claude Code」フッターまたはボット属性ラインを含めないでください
• Co-Authored-By ラインを含めないでください

ステップ5: 更新を適用する

本文をテンポラリファイルに書き込み、--body-file を使用してシェル引数の長さ制限を回避します:

cat > /tmp/pr_body.md <<'EOF'
## Summary
...

## Changes
...

## Test Plan
...
EOF
gh pr edit --title "the pr title" --body-file /tmp/pr_body.md

追加しないでください:

• --author フラグ
• Co-Authored-By トレーラー
• 「Generated with Claude Code」フッター

ドラフト/準備完了の処理: ユーザーがドラフトPRをレビュー準備完了としてマークしたい場合は、gh pr ready を実行します。ドラフトに変換したい場合は、gh pr ready --undo を実行します。

ステップ6: レポート

• PR URLを返してユーザーがそれを確認できるようにします
• PR説明で以前と比較して何が変わったかを要約します
• gh pr edit が失敗した場合は、エラーを診断し、修正を提案します

---

エンコードされたベストプラクティス

PRサイズ: PRは小さく、焦点を当てたものに保ちます。diffが非常に大きい場合(>500行変更)は、小さなPRに分割することを提案します。

コミット履歴: コミット履歴が乱雑な場合は、リベースしてクリーンアップすることを提案します。なぜであるかを説明するクリーンなコミットはレビューをはるかに容易にします。

フィードバックリクエスト: ユーザーが特定のフィードバックを希望していることを言及している場合は、本文に「Feedback Requested」セクションを追加します。

スクリーンショット: フロントエンドの変更の場合は、更新後にスクリーンショットまたは記録をPRに追加することをユーザーに思い出させます。