git-commit-push-pr

Git Commit、Push、PR

作業中の変更を、オープンなプルリクエストにするか、既存の PR の説明を書き換えます。

ユーザーへの確認： このスキルで「ユーザーに確認する」とある場合は、プラットフォームのブロッキング質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）を使用してください。利用できない場合は、質問を提示して返信を待ってください。

モードの判定

ユーザーが既存の PR 説明の更新、リフレッシュ、書き換えを求めていて、コミットやプッシュに触れていない場合は、説明のみの更新です。ユーザーが焦点を指定する場合もあります（例：「PR の説明を更新して、ベンチマーク結果を追加してください」）。DU-3 でその焦点を考慮してください。

説明のみの更新の場合は、以下の「説明の更新ワークフロー」に従ってください。それ以外の場合は、全体のワークフローに従ってください。

コンテキスト

Claude Code 以外の場合は、「コンテキストのフォールバック」セクションに進み、そこでコマンドを実行してコンテキストを収集してください。

Claude Code の場合は、以下の 6 つのラベル付きセクションにデータがあらかじめ用意されています。そのまま使用し、これらのコマンドを再実行しないでください。

Git の状態： !git status

作業ツリーの差分： !git diff HEAD

現在のブランチ： !git branch --show-current

最近のコミット： !git log --oneline -10

リモートのデフォルトブランチ： !git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'

既存 PR の確認： !gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

コンテキストのフォールバック

Claude Code の場合は、このセクションをスキップしてください。上記ですでにデータを利用できます。

すべてのコンテキストを収集するため、次の単一コマンドを実行してください。

printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'; printf '\n=== PR_CHECK ===\n'; gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

---

説明の更新ワークフロー

DU-1：意図を確認する

ユーザーに「このブランチの PR 説明を更新しますか？」と確認してください。断られた場合は終了します。

DU-2：PR を見つける

コンテキストにある現在のブランチと既存 PR の確認結果を使用してください。現在のブランチが空（detached HEAD）の場合は、ブランチがないことを報告して終了します。PR の確認結果が state: OPEN の場合は、コンテキストブロックの PR url を記録してください。これは後続処理に渡す曖昧さのない参照先です。そのうえで DU-3 に進みます。それ以外の場合は、オープンな PR がないことを報告して終了します。

DU-3：更新後の説明を作成して適用する

後で比較・確認できるように、現在の PR 説明を読み取ります。

gh pr view --json body --jq '.body'

更新後のタイトルと本文を生成する — DU-2 の PR URL（例：https://github.com/owner/repo/pull/123）を指定して、ce-pr-description スキルを読み込んでください。URL によってリポジトリと PR が特定されるため、現在のリポジトリが曖昧になるワークツリーやサブディレクトリから呼び出した場合でも識別できます。ユーザーが焦点（例：「ベンチマーク結果を含めてください」）を指定した場合は、URL の後に自由記述の指示として追加してください。このスキルは、適用や確認を行わずに {title, body_file} ブロック（本文は OS の一時ファイル）を返します。

ce-pr-description が {title, body_file} の組み合わせではなく、「未オープン」などの正常終了メッセージを返した場合は、そのメッセージを報告して終了します。

エビデンスの判断： ce-pr-description は、既存の本文にある ## Demo または ## Screenshots ブロックをデフォルトで保持します。ユーザーの焦点がエビデンスの更新または削除を求めている場合は、その意図を指示文として渡してください。スキルはその指示に従います。エビデンスのブロックがなく、追加すれば読者に役立つ場合は、別途 ce-demo-reel を呼び出してキャプチャし、その後、キャプチャしたエビデンスに言及する更新後の指示を付けて ce-pr-description を再度呼び出してください。

比較して確認する — 新しい説明が古い説明と比べてどの点を異なる内容にしているか、簡潔に説明してください。これはユーザーが適用するか判断するのに役立ちます。説明本文自体にこれらの違いを記載する必要はありません。すでにコンテキストにある本文（body_file を書き込んだ bash 呼び出しの結果）をもとに要約してください。本文を再度出力してしまうため、一時ファイルを cat しないでください。

• ユーザーが焦点を指定した場合は、その内容が反映されたことを確認してください。
• 適用する前に、ユーザーに確認してください。

確認されたら、返されたタイトルと本文ファイルを使って適用します。

gh pr edit --title "<returned title>" --body "$(cat "<returned body_file>")"

PR の URL を報告してください。

---

全体のワークフロー

ステップ 1：コンテキストを収集する

上記のコンテキストを使用してください。このステップとステップ 3 に必要なデータはすべてすでに利用可能です。これらのコマンドを再実行しないでください。

リモートのデフォルトブランチの値は、origin/main のように返されます。origin/ のプレフィックスを削除してください。DEFAULT_BRANCH_UNRESOLVED または単独の HEAD が返された場合は、次を試してください。

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

両方とも失敗した場合は、main を使用してください。

現在のブランチが空（detached HEAD）の場合は、ブランチが必要であることを説明してください。今すぐフィーチャーブランチを作成するかどうかを尋ねてください。

• はいの場合は、変更内容からブランチ名を導き出し、git checkout -b <branch-name> で作成して、以降のワークフローで使用します。
• いいえの場合は、停止します。

ワーキングツリーがクリーン（ステージ済み、変更済み、未追跡のファイルがない）の場合は、次のアクションを判断します。

1. git rev-parse --abbrev-ref --symbolic-full-name @{u} を実行して、アップストリームを確認します。
2. アップストリームが存在する場合は、未プッシュのコミットを確認するために git log <upstream>..HEAD --oneline を実行します。

判断フロー：

• デフォルトブランチ上で、未プッシュのコミットがある、またはアップストリームがない -- フィーチャーブランチを作成するかどうかを尋ねます（デフォルトブランチへの直接プッシュはサポートされていません）。はいの場合は、作成してステップ 5 から続行します。いいえの場合は、停止します。
• デフォルトブランチ上で、すべてプッシュ済み、オープン PR なし -- フィーチャーブランチでの作業はないことを報告します。停止します。
• フィーチャーブランチで、アップストリームなし -- ステップ 4 をスキップし、ステップ 5 から続行します。
• フィーチャーブランチで、未プッシュのコミットがある -- ステップ 4 をスキップし、ステップ 5 から続行します。
• フィーチャーブランチで、すべてプッシュ済み、オープン PR なし -- ステップ 4～5 をスキップし、ステップ 6 から続行します。
• フィーチャーブランチで、すべてプッシュ済み、オープン PR あり -- 最新の状態であることを報告します。停止します。

ステップ 2：規約を確認する

コミットメッセージと PR タイトルでは、次の優先順位に従います。

1. コンテキスト内のリポジトリ規約 -- プロジェクトの指示に規約が指定されている場合は、それに従います。セッション開始時に読み込まれているため、再読み込みしないでください。
2. 最近のコミット履歴 -- 直近 10 件のコミットのパターンに合わせます。
3. デフォルト -- type(scope): description（Conventional Commits）。

ステップ 3：既存の PR を確認する

現在のブランチと、コンテキスト内にある既存 PR の確認結果を使用します。ブランチが空の場合は、detached HEAD を報告して停止します。

PR の確認結果が state: OPEN の場合は、URL を記録します。これは既存 PR のフローです。ステップ 4 と 5 に進み（保留中の作業をコミットしてプッシュし）、次にステップ 7 に進んで説明を更新するかどうかを尋ねます。ユーザーが更新を確認した場合に限り、新しい説明を生成する ce-pr-description を実行するステップ 6 を実行します。ステップ 7 の既存 PR 用サブフローでは、ステップ 6 で生成された {title, body_file} を使用します。そうでない場合（オープン PR がない場合）は、ステップ 6、7、8 を順番に実行します。

ステップ 4：ブランチを作成し、ステージしてコミットする

1. デフォルトブランチ上にいる場合は、まず git checkout -b <branch-name> でフィーチャーブランチを作成します。
2. 変更されたファイルを確認し、自然に区別できる懸念事項に分けます。ファイルが明確に別個の論理的な変更に分類できる場合は、別々のコミットを作成します（最大 2～3 件）。ファイル単位でグループ化してください（git add -p は使用しないでください）。判断が難しい場合は、1 つのコミットで問題ありません。
3. 各グループを 1 回の呼び出しでステージしてコミットします。git add -A や git add . は避けてください。ステップ 2 の規約に従います。

   git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
   commit message here
   EOF
   )"
   

ステップ 5：プッシュする

git push -u origin HEAD

ステップ 6：PR のタイトルと本文を生成する

ステップ 1 のワーキングツリーの差分に表示されるのは、実行時に未コミットだった変更のみです。PR の説明では、PR 内のすべてのコミットを網羅する必要があります。

ベースブランチとリモートを特定します。 ベースブランチとリモートの両方を解決します（フォークを使った PR では、origin 以外のリモートが使われることがあります）。最初に成功したものを採用して停止します。

1. PR メタデータ（ステップ 3 で既存 PR が見つかった場合）：

   gh pr view --json baseRefName,url
   

   baseRefName を抽出します。PR URL の owner/repo を git remote -v のフェッチ URL と照合して、ベースリモートを特定します。見つからない場合は origin を使用します。
2. コンテキスト内のリモートのデフォルトブランチ -- 解決できた場合は、origin/ のプレフィックスを削除します。origin を使用します。
3. GitHub メタデータ：

   gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
   

   origin を使用します。
4. 一般的な名前 -- main、master、develop、trunk の順に確認します。

   git rev-parse --verify origin/<candidate>
   

   origin を使用します。

どれも解決できない場合は、対象ブランチを指定するようユーザーに尋ねます。 エビデンスの要否を判断する前に、ブランチの差分全体を取得します。 Step 1 のワーキングツリーの差分に反映されるのは、実行時点の未コミットの変更のみです。よくある「フィーチャーブランチの変更をすべてプッシュ済みで、PRを開いている」ケースでは、Step 1 でコミットとプッシュの手順が省略され、ワーキングツリーの差分は空になります。エビデンスの要否を判断するには、動作が確認可能かどうかを判定するため、上記で解決したベースとの実際のブランチ差分が必要です。そのため、明示的に算出してください。取得が必要なのは、ローカルに参照先がない場合のみです。<base-remote>/<base-branch> がすでにローカルで解決できる場合は、オフライン環境、ネットワーク制限のある環境、認証の有効期限が切れた環境でも失敗しないよう、ローカルの状態を使って差分を実行してください。

git rev-parse --verify <base-remote>/<base-branch> >/dev/null 2>&1 \
  || git fetch --no-tags <base-remote> <base-branch>
git diff <base-remote>/<base-branch>...HEAD

エビデンスの要否を判断するときは、ワーキングツリーの差分ではなく、このブランチ差分を使ってください。ブランチ差分が空の場合（例：HEAD がすでにベースにマージ済み、またはブランチに固有のコミットがない場合）は、エビデンスについて尋ねず、委任に進んでください。

委任の前にエビデンスの要否を判断します。 ブランチ差分に、確認可能な動作（UI、CLI の出力、実行可能なコードを伴う API の動作、生成されたアーティファクト、ワークフローの出力）の変更が含まれ、エビデンスの取得を妨げる事情（利用できない認証情報、有料サービス、デプロイ専用のインフラ、ハードウェア）がない場合は、次のように尋ねてください。「このPRには確認可能な動作があります。PR の説明にエビデンスを記録しますか？」

• 今すぐ記録する — ブランチ差分から説明内容を推測して、ce-demo-reel スキルを読み込みます。ce-demo-reel は Tier、Description、URL を返します。記録したエビデンスは、自由記述の指示として ce-pr-description に渡せるようにしておくか（例：「記録したデモを ## Demo セクションとして含める：」）、返された本文に適用する前に挿入してください。記録結果が Tier: skipped または URL: "none" の場合は、エビデンスなしで進めてください。
• 既存のエビデンスを使う — URL または Markdown の埋め込みを尋ねてから、自由記述の指示として ce-pr-description に渡すか、適用前に挿入してください。
• スキップする — エビデンスのセクションを含めずに進めてください。

エビデンスを取得できない場合（ドキュメントのみ、Markdown のみ、変更履歴のみ、リリースメタデータ、CI／設定のみ、テストのみ、または内部リファクタリングのみ）は、尋ねずにスキップしてください。

タイトルと本文の作成を ce-pr-description に委任します。 ce-pr-description スキルを読み込みます。

• 新しいPRの場合（Step 3 で既存のPRが見つからなかった場合）：このステップの前半で解決済みのベースを使い、base:<base-remote>/<base-branch> を指定して呼び出してください。これにより、ブランチの対象がデフォルト以外のベース（例：develop、release/*）である場合も、ce-pr-description は正しいコミット範囲を説明できます。記録したエビデンスの情報やユーザーの注目点を、自由記述の指示として追加してください（例：「記録したデモを ## Demo セクションとして含める：」）。
• 既存のPRの場合（Step 3 で見つかった場合）：Step 3 のコンテキストにあるPRの完全なURLを指定して呼び出してください（例：https://github.com/owner/repo/pull/123）。このURLは、ワークツリーまたはサブディレクトリから呼び出す場合もリポジトリとPRの識別情報を保持します。スキルはPR自体の baseRefName を読み取るため、base: の上書きは不要です。URLの後に、注目点に関する指示を自由記述で追加してください。

ce-pr-description は {title, body_file} ブロックを返します（本文はOSの一時ファイルに保存されます）。価値を先に伝える文章の原則、コミットの分類、規模、ストーリー構成、文体、視覚的な伝達、番号付けの規則、Compound Engineering バッジのフッターは、内部で適用されます。Step 7 では返された値をそのまま使用し、必要な場合を除いて手動で編集しないでください（例：このステップで記録したエビデンスのセクションを、指示として渡していないため挿入する場合。その場合は、適用前に本文ファイルを直接編集してください）。

ce-pr-description が {title, body_file} の代わりに正常終了メッセージを返した場合（例：PRがクローズ済み、説明するコミットがない、ベース参照先を解決できない場合）は、そのメッセージを報告して停止してください。PRを作成または編集してはいけません。

Step 7: PR を作成または更新する

新規 PR（ステップ 3 で既存の PR が見つからなかった場合）

ce-pr-description が返した {title, body_file} を使用します。

gh pr create --title "<returned title>" --body "$(cat "<returned body_file>")"

タイトルは 72 文字未満にしてください。ce-pr-description は、すでにその範囲内の Conventional Commit 形式のタイトルを出力します。

既存の PR（ステップ 3 で見つかった場合）

新しいコミットは、ステップ 5 で PR にすでに追加されています。PR の URL を報告してから、説明文を書き換えるかどうかを尋ねます。

• はいの場合、ステップ 6 を実行して ce-pr-description で {title, body_file} を生成します（pr: に既存の PR の URL を渡します）。次に、返されたタイトルと本文ファイルを適用します。

  gh pr edit --title "<returned title>" --body "$(cat "<returned body_file>")"
  

• いいえの場合は、ステップ 6 を完全にスキップして終了します。ユーザーが書き換えを断った場合、委任やエビデンスの取得は実行しないでください。

ステップ 8：報告

PR の URL を出力します。