git-commit

エージェントに、メッセージを書くところからコミットの実行まで任せたいときに使います。説明文によると、コミットしたいとき、変更を複数のコミットに分けたいとき、/commit と打たれたとき、Conventional Commits の形を求められたときに呼ばれます。

GitHub の awesome-copilot に収録されたスキルで、差分を調べ、関係するファイルをステージし、メッセージを書き、git commit を流すところまでが範囲です。

手順

6 段

種別（type）の表

11 種

1 行目の上限

72 文字

同梱ファイル（2026-10-23 時点）

0 件

6 段の手順

1. リポジトリの決まりを読むcommitlint の設定、CONTRIBUTING.md、git log --oneline -10
2. 変更を調べるgit status --porcelain、git diff --staged、git diff
3. ファイルをステージする1 つのコミットに 1 つの論理的な変更
4. メッセージを書く種別・範囲・要約を差分から決める
5. コミットする段落ごとに -m を分ける
6. 結果を確かめるgit log -1 --stat と git status --porcelain

最初の段で見つけたリポジトリの決まりが、このスキルの規則と違うときは、リポジトリの決まりに従います。変更が何も無いときは、そう伝えて空のコミットを作りません。

メッセージの形

形は <type>(<scope>): <summary> の 1 行に、任意の本文と末尾（footer）が続きます。範囲を省くなら <type>: <summary> です。

• 要約は命令形で書く。「add」であって「added」や「adds」ではない
• 1 行目は 72 文字以内で、末尾に句点を付けない
• 本文には、何を変えたかと、なぜ変えたかを書く
• 末尾は Refs: #456 や Closes #123 の形。Git が trailer として読むのは Token: value の形だけ

種別の表は feat・fix・docs・style・refactor・perf・test・build・ci・chore・revert の 11 行です。本文は、Conventional Commits の仕様が決めているのは feat と fix だけで、ほかは Angular の流儀（@commitlint/config-conventional）から来ている、と正確に書き分けています。リポジトリに独自の一覧があればそちらを使います。

互換性を壊す変更は、コロンの前に ! を置くか、BREAKING CHANGE: の末尾を付けます。大文字で書き、BREAKING-CHANGE: も正しいとしています。

混ざった変更を分ける

ステージ済みのファイルに別の変更が混ざっていれば、先に git reset -q -- でその分を外し、このコミットの分だけを git add -- で載せ直します。ステージの段には、エージェントが詰まりやすい点が具体的に書かれています。

• glob は引用符で囲む囲まないとシェルが展開し、下の階層のファイルが拾われない
• git add -p と -i を使わない人の入力を待って止まる
• 衝突を解いたら git add --resolved解いたファイルだけを載せる。衝突の印が残っていれば止まる
• 載せた一覧を確かめるgit diff --staged --name-only。.env・credentials.json・秘密鍵を入れない

シェルを選ばない書き方

コミットは、段落ごとに -m を分けて渡します。Git が段落の間に空行を入れるので、改行を含む文字列を組む必要がありません。本文は、この形なら Bash でも PowerShell でも動くとしています。長いメッセージは一時ファイルに書いて git commit -F で渡します。

• メッセージだけが欲しい説明文が名指しで除外している。書くだけなら caveman-commit
• push や PR を作りたい説明文が範囲外としている
• rebase や履歴の整理説明文が範囲外としている。安全の決まりでも禁じている
• コミットの前の検査を入れたいフックの設定は setup-pre-commit の担当

メッセージを書かせるだけで、コミットは自分でしたいなら caveman-commit が合います。こちらは git commit を実行せず、ステージもしません。

同じ awesome-copilot には、メッセージだけを書く commit-message-storyteller もあります。その説明文は、ステージとコミットはこの git-commit に任せるよう書いています。

コミットは実行される

frontmatter の allowed-tools は shell(git:*) です。allowed-tools は道具を絞る設定ではなく、呼ばれた回に確認なしで使ってよい道具を前もって宣言するものです。ほかの道具も使えますし、git の命令は確認なしで走り得ます。

安全の決まり

本文の末尾に、してはいけないことがまとめてあります。

• Git の設定を変えない
• 言われない限り --no-verify を使わない。フックは .git/hooks にも Git の設定にもあり得る
• フックで失敗したら、直してステージし直し、同じ git commit をもう一度流す。直前のコミットを変える --amend は使わない
• 言われない限り履歴を変えない。git reset --hard、git rebase、試験的な git history を使わない
• 言われない限り push しない。既定のブランチに force push しない

フックの失敗を --amend で繕わない、という決まりは実務的です。失敗したコミットは作られていないので、--amend は 1 つ前の無関係なコミットを書き換えてしまいます。

秘密のファイルを入れない決まりは、目で確かめる手順に頼っている

.env や秘密鍵を入れないための仕組みは、ステージした一覧を確かめる手順だけです。.gitignore の設定や検出の道具は使いません。リポジトリの側でも .gitignore を整えておくのが安全です。

git add --resolved は新しい Git が要る

本文の compatibility 欄は、git add --resolved には Git 2.56 以降が要る、と書いています。古い Git では、衝突を解いたあとのこの手順が失敗します。

対応エージェントの明記が無い

awesome-copilot の README が案内するのは、GitHub Copilot の CLI と VS Code での入れ方です。Claude Code や Codex の名前は出てきません。本文は Copilot に固有の書き方を使っていないので、ほかのエージェントでも読める内容です。ライセンスは MIT です。

変更が大きいとき、自動で分けてくれますか

1 つのコミットに 1 つの論理的な変更を載せるよう、本文が決めています。ステージ済みのものに別の変更が混ざっていれば外してから、このコミットの分だけを載せます。分け方はエージェントの判断なので、分けた案を先に見せてもらうと確実です。

リポジトリ独自のコミットの規約がある場合は

最初の段で commitlint の設定、CONTRIBUTING.md、直近 10 件のコミットを読み、このスキルの規則と違えばリポジトリの決まりを使う、と本文にあります。種別の一覧も、リポジトリに独自のものがあればそちらが優先です。

フックで失敗したらどうなりますか

Git はコミットを作らないので、問題を直し、ファイルをステージし直して、同じ git commit をもう一度流します。--no-verify で飛ばすのは、利用者に言われたときだけです。--amend は前のコミットを変えるので使わない、と本文は書いています。

Windows の PowerShell でも動きますか

本文は、段落ごとに -m を分ける書き方が Bash でも PowerShell でも動くとしています。改行を含む文字列を組まないので、シェルごとの引用符の違いで崩れにくい形です。長いメッセージは一時ファイルに書いて -F で渡します。