headless-commit

name	headless-commit
description	ステージ済みの変更からコミットメッセージを自動生成し、コミットする (ヘッドレスモード)。
disable-model-invocation	true
model	haiku
allowed-tools	["Glob","Grep","Read","Bash(git commit *)","Bash(${CLAUDE_PLUGIN_ROOT}/scripts/git-claude-attribution)"]

Committing Staged Changes

ステージ済みの変更のみをコミットします。確認を挟まず、メッセージを決めたら直ちに Bash ツールで git commit を実行してください。

このスキルはヘッドレスモード (claude --print) で起動されます。確認プロンプトを出しても応答する人間はおらず、呼び出し元シェルスクリプトがハング/誤動作します。「このメッセージで大丈夫ですか？」のような問いかけは禁止です。

また、出力テキスト中に git commit ... をコードブロックや擬似コマンドとして書いても 実行にはなりません。ヘッドレス起動には、それを見て手動で実行してくれる人間はいません。git commit は必ず Bash ツール (Bash(git commit *) が許可済み) を呼び出して実行してください。テキストとしての提示で完了報告に進むと、HEAD は動いていないのに「コミット完了」と嘘の報告を出すことになります。

スコープと禁止事項

このスキルでエージェントが実行してよい操作は git commit のみです。それ以外の CLI コマンド (例: git add, git reset, sed, perl, ファイル整形ツール) や、Write / Edit ツールによるファイルの作成・更新は 一切行ってはいけません。

git commit がフックによって拒否された場合、フックの種類で挙動を分けます:

• pre-commit フックによる拒否: エージェントは 修正を試みず作業を中止 し、フックの出力を「コミット失敗」として報告します。フックが指摘した問題を取り除くためのファイル編集 (例: 行末スペースの除去、設定の書き換え) や追加コマンドの実行 (git add の追加、ステージから外す git reset) は禁止です。pre-commit はワークツリー/インデックスの問題を指摘するフックであり、これを直すのはこのスキルの責務範囲外です。
• commit-msg フックによる拒否: コミットメッセージそのものへの指摘なので、拒否事由を読み解いてメッセージを修正し、git commit を 再実行 してよい (リトライは最大 3 回まで。初回失敗後のリトライを 3 回まで、合計で最大 4 回試行)。3 回リトライしても通らなかった場合は中止し、最後の拒否事由を「コミット失敗」として報告します。

なお、フックの種類を問わず、preprocessing が期待通り動かなかった場合 (展開結果が空、エラー出力等) も、独自にコマンドを補って情報を取りに行ってはいけません。

理由: このスキルはヘッドレス起動 (claude --print) で人間の確認なしに動くため、エージェントがスコープ外の副作用 (ファイル編集、ワークツリーやインデックスの状態変更) を独断で起こすと、呼び出し元から制御不能な変更が混入します。スキルの責務は「与えられたステージ済み差分をコミットするか、できなければ報告するか」の二択に限定されています。

手順

注意:

• CWD がリポジトリルートであることを前提とします。

1. ステージ済みの変更を確認

git status --short 実行結果: !git status --short

git diff --cached --stat 実行結果: !git diff --cached --stat

git diff --cached 実行結果: !git diff --cached

2. コミットメッセージ規約の把握

直近のコミット履歴からプロジェクトの規約を把握する。

git log --oneline -10 実行結果: !git log --oneline -10

CLAUDE.md にコミットメッセージ規約があれば、既にコンテキストに含まれているのでそれに従う。

!${CLAUDE_PLUGIN_ROOT}/scripts/git-claude-attribution

3. コミットメッセージの生成

会話の文脈がないため (ヘッドレス起動)、コミットメッセージは差分の内容、コミット履歴から読み取れる規約、そしてユーザーが渡した経緯メモ ($ARGUMENTS) のみを統合して生成します。

ルール:

• コミットメッセージは${user_config.COMMIT_MESSAGE_LANGUAGE}で生成する
• subject は変更内容を簡潔に表す
• ユーザーが渡した経緯メモ ($ARGUMENTS) の扱い:
  • 経緯メモは git diff には現れない情報 (なぜその変更を行ったか、どういう経緯か) を表すユーザー本人の言葉です。git diff から読み取れる「何を変えたか」とは独立した、捨てると失われてしまう情報なので、必ずコミットメッセージに反映してください。
  • 短くて subject の動機部分として収まるなら subject に組み込む。
    • 例: 経緯メモ unused だから消した → refactor(foo): unused な bar を削除
  • subject に収めると不自然になる、もしくは複数の文・複数の理由がある場合は body に書く。規約に沿う形に整えてよいが、ユーザーの意図は失わない。
    • 例: 経緯メモ 前任者が試験的に入れたが結局使われなかったので整理する → subject に変更内容、body に経緯
• 経緯メモが空のときは body 原則不要 (subject だけで意図が伝わるケースが多いため)。subject だけでは意図が伝わらない大きな変更に限り body を付ける。
• $ARGUMENTS が空でも、経緯メモの不足についてユーザーに確認しない。空は「経緯メモなし」を意味するものとして扱い、そのままコミットする。

ユーザーが渡した経緯メモ: $ARGUMENTS

4. コミットの実行

確認を挟まずに Bash ツールで git commit を実行する (ヘッドレスモードのため確認は届かない)。出力テキストに git commit ... を書くのは実行ではない (冒頭の注意を参照)。

git commit がフックで拒否された場合、出力からどのフックで失敗したかを読み取り、フック種別で挙動を分ける (「スコープと禁止事項」を参照):

• pre-commit フックで失敗: 直ちにステップ 5 の失敗フォーマットで報告して終了する。ファイル編集や追加コマンドによる修正試行は禁止。
• commit-msg フックで失敗: 拒否事由を反映してコミットメッセージを修正し、git commit を再実行する。リトライは最大 3 回まで (初回失敗後のリトライを 3 回まで、合計で最大 4 回試行)。3 回リトライしても通らなかった場合は最後の出力を持ってステップ 5 の失敗フォーマットで報告する。

5. 完了報告

成功時は次のフォーマット:

コミットが完了しました
~~~
<タイトル・本文・フッターを含む完全なコミットメッセージ>
~~~

失敗時 (フック拒否を含む) は次のフォーマット:

コミット失敗 (<フック拒否 / その他の理由>)
~~~
<git commit の終了コード、stderr、フック出力など、原因特定に必要な情報>
~~~