Claude Codeのcommit-commandsで、コミットからPR作成まで1コマンドにする
commit-commandsプラグインの3コマンド(commit・commit-push-pr・clean_gone)の入れ方と違い、READMEと実際のコマンド定義の食い違い、使う前の注意点を扱います。
commit-commandsは、コミット・push・プルリクエスト作成を1つのスラッシュコマンドにまとめるClaude Codeの公式プラグインです。Anthropicの公式マーケットプレイスに入っていて、次の1行で入ります。
/plugin install commit-commands@claude-plugins-official入れると3つのコマンドが増えます。コミットだけを作るcommit、コミットからPR作成までを通すcommit-push-pr、リモートで消えたブランチを掃除するclean_goneです。この記事では3つの違いと入れ方に加え、READMEの説明とコマンド定義そのものを突き合わせて見えた差も扱います。
3つのコマンドは何をするのか
最初に役割を並べます。名前の付き方はプラグイン名が前に付く形で、/commit-commands:commitのように呼びます。
| コマンド | やること | 外に出る操作 |
|---|---|---|
commit | やること変更を見て、1つのコミットを作る | 外に出る操作なし(ローカルのみ) |
commit-push-pr | やることmainにいれば新ブランチを作り、コミットしてpushし、PRを開く | 外に出る操作pushとPR作成 |
clean_gone | やることリモートで削除済み([gone])のローカルブランチを消す | 外に出る操作ブランチ削除 |
commitは、git status・git diff HEAD・現在のブランチ・直近10件のコミットログを読み込んだうえで、コミットを1つ作ります。直近のログを見るので、メッセージの書き方はそのリポジトリの流儀に寄ります。
commit-push-prは5つの手順をひと続きで実行します。mainにいるときだけ新しいブランチを作る、1つのコミットにまとめる、originへpushする、gh pr createでPRを作る、の流れです。READMEによると、PR本文には1〜3行の概要とテスト計画のチェックリストが入ります。
clean_goneは、PRをマージしてリモートのブランチを削除したあとに溜まる、ローカルの古いブランチを片付ける用途です。
入れ方と、入ったかどうかの確かめ方
インストール手順は公式ドキュメントがcommit-commandsを例にして書いています。ターミナルでclaudeを起動し、上のコマンドを打つと、その場では入らず、プラグインの詳細画面が開きます。
詳細画面では、追加されるコマンドやフックなどの一覧(Will install)が確認できます。公式マーケットプレイスのプラグインなら、Context costとして2種類のトークン見積もりも出ます。
- Every turn: 毎回のメッセージに上乗せされる量
- When invoked: スキルやエージェントが呼ばれたときに増える量
続いてスコープを選びます。選択肢は3つです。
インストールのスコープ
ユーザー
このマシンのすべてのプロジェクトで使えます。
プロジェクト
そのリポジトリで作業する全員に有効になります。
ローカル
自分だけ、そのリポジトリの中だけで有効です。
インストール後の要約の最後の1文に「Plugin is now active.」とあれば、すぐ使えます。/を入力して/commit-commands:commitが候補に出れば完了です。出ないときは、/pluginのInstalledタブか、シェルのclaude plugin listで入っているかを見ます。
公式マーケットプレイスは、最初の対話セッションの起動時にClaude Code側が追加してくれます。そのためcommit-commandsの例には、マーケットプレイスを追加する手順がありません。他社のマーケットプレイスから入れるときは先に追加が必要です。全体の枠組みはプラグインとマーケットプレイスの解説にあります。
READMEの「Installation」には、このプラグインはClaude Codeに含まれていてコマンドは自動で使えると書かれています。一方、公式ドキュメントの手順は/plugin installを実行する前提です。迷ったら、/の候補に/commit-commands:commitが出るかで判断するのが確実です。
READMEとコマンド定義を突き合わせると
コマンドの実体は、プラグイン内のcommands/にあるMarkdownファイルです。フロントマターのallowed-toolsと、本文の指示だけで動いています。READMEと並べると、次の違いがありました。
READMEの説明と、コマンド定義の中身
READMEの説明
/commitは秘密情報を含むファイル(.envなど)をコミットしないと説明されています。/commit-push-prはブランチ内の全コミットを分析してPR本文を書くと説明されています。
コマンド定義
どちらの指示文にも、秘密情報を避ける指示は書かれていません。commit-push-prが読み込む情報は、git status、git diff HEAD、現在のブランチ名の3つだけで、ブランチ内の過去コミットの履歴は含まれません。
秘密情報の件は、定義にない振る舞いを期待しないほうが安全、ということです。.envのような機密ファイルは、.gitignoreに入れておくのが前提になります。
PR本文の件は影響が出やすい点です。コマンドが見ているのは作業ツリーとHEADの差分です。複数のコミットを重ねたブランチでcommit-push-prを実行すると、すでにコミット済みの内容がPR本文に反映されない可能性があります。READMEの文面どおりの結果を期待する前に、生成されたPR本文を読んでから確定してください。
allowed-toolsが決める「確認なしで動く範囲」
allowed-toolsは、そのコマンドの実行中に確認なしで使えるツールの範囲です。3つの定義は、この点で性格が違います。
| コマンド | allowed-tools |
|---|---|
commit | allowed-toolsgit add・git status・git commit |
commit-push-pr | allowed-toolsgit checkout --branch・git add・git status・git push・git commit・gh pr create |
clean_gone | allowed-tools指定なし |
commitにはgit pushが含まれません。コミットまでで止まるので、「ローカルだけ進めたい」ときの選択肢になります。
commit-push-prの許可パターンは、ブランチ作成がgit checkout --branchという綴りです。短縮形の-bで呼ばれた場合に許可パターンへ一致するかは、定義からは分かりません。確認が出たら、ブランチ作成のコマンドを見てから承認する、という運用で足ります。
clean_goneはallowed-toolsを持ちません。指示文はgit branch -v、git worktree list、それに続く削除のシェルスクリプトを実行する流れで、コマンドごとに承認を求められる場面があります。
commit-push-prの自動許可は、Claude Code側の変更履歴にも出てきます。v2.1.206では、git pushの自動許可先がoriginに加えてremote.pushDefaultなどにも広がりました。詳細はcommit-push-prがpush remoteへのgit pushを自動許可で扱っています。v2.1.229では、--forceや--amend、--no-verifyのような危険なフラグ付きのgit・ghコマンドが、自動承認の対象から外れました。
なお、変更履歴の/commit-push-prと、このプラグインの/commit-commands:commit-push-prが同じ実装なのかは、公式ドキュメントに書かれていません。コマンド一覧のページにも、/commitや/commit-push-prの行はありません。変更履歴の挙動を前提にするなら、自分の環境で動作を見てからにします。
clean_goneを手元で動かしてみた
clean_goneの指示文に書かれたシェルスクリプトを、空のリポジトリで試しました(git 2.50.1)。ローカルのベアリポジトリをリモートに見立て、通常のブランチとworktreeを持つブランチを1つずつ作り、両方のリモートブランチを削除してから実行しています。ネットワークは使っていません。
結果は次のとおりです。
(実行前)
feat-a c6d2f7c [gone] a
+ feat-b 85b8303 [gone] b
* main 7c4b4d1 init
(実行中)
Processing branch: feat-a
Deleting branch: feat-a
Processing branch: feat-b
Removing worktree: wt-b
Deleting branch: feat-b
(実行後)
* main 7c4b4d1 init[gone]が付いた2本が消え、worktreeも先に取り除かれました。ここで押さえておく点が2つあります。
1つ目は、[gone]が表示されるのはアップストリームを設定したブランチに限られることです。同じ手順をgit push -uなしで行うと、リモートブランチを消してもブランチ一覧に[gone]は出ず、clean_goneは何も消しませんでした。PRを作るときはgit push -u origin <ブランチ名>で上流を張っておく運用が前提になります。commit-push-prの定義にはgit pushの引数が書かれておらず、上流が張られるかは定義から分かりません。
2つ目は、削除が強制であることです。スクリプトはgit branch -Dとgit worktree remove --forceを使います。未マージのコミットや、worktree内の未コミットの変更があっても、確認なしに消えます。READMEは「安全に実行できる」と書いていますが、消える対象は「リモートで削除済みのブランチ」に限られるだけで、ローカルにしかない作業まで守る仕組みではありません。実行前にgit branch -vで[gone]の一覧を目で見ておくと安心です。
READMEには、[gone]が見つからないときはgit fetch --pruneでリモートの追跡情報を更新するよう書かれています。
つまずきやすい点
READMEのトラブルシューティングに挙がっている症状は、次の3つです。
commitで空のコミットになる: コミットする変更がありません。git statusで変更の有無を確認しますcommit-push-prでPR作成に失敗する: GitHub CLI(gh)が未インストールか未認証です。gh auth loginで認証します。リポジトリにGitHubのリモートが必要ですclean_goneが何も見つけない: 上で見たとおり、アップストリームの設定とgit fetch --pruneを疑います
commit-push-prが必要とするのは、ghの認証と、originという名前のリモートです。READMEの要件にも、リポジトリにoriginがあることが明記されています。
自分のワークフローにどう組み込むか
READMEの運用例は、3通りです。コミットを重ねる間はcommit、PRにする段階でcommit-push-pr、PRがマージされたあとの掃除にclean_goneを使います。
コミット前に走らせたい検査がある場合は、フックとの併用になります。コミットが検査に落ちた場合の直させ方は、huskyとpre-commitを併用する手順が参考になります。PRリンクの飛び先をgithub.com以外にしたいなら、prUrlTemplate設定が受け持ちます。
プラグインが手に合わなければ、定義が数十行のMarkdownという点が活きます。自分用のコマンドを同じ形で書けば、コミットメッセージの規約や、PR本文のテンプレートを指示に足せます。公式プラグインはそのままの形で使い、足りない部分だけ自作する、という分け方が現実的です。
まとめ
commit-commandsは、コミットを作るcommit、PR作成まで通すcommit-push-pr、[gone]ブランチを消すclean_goneの3つです。入れてしまえば手数は減ります。ただし、READMEが説明する秘密情報の回避とブランチ全体の分析は、指示文には書かれていません。clean_goneは強制削除です。PR本文と削除対象を自分の目で見てから進める使い方なら、時間の節約になります。