コミット(エージェント委譲)

トークンを使う作業(diff を読む・コミットメッセージを起草する・コミットする・不正コミット防止 チェック)は commit-worker エージェント(ワーカー)に委譲する。メインモデルはコミットメッセージを 書かない。 ワーカーが従う手順・チェック・規約は commit-worker エージェント自身の定義(.claude/agents/commit-worker.md)に組み込まれており、 メインモデルは本文を再掲しない(再掲は高コストなメインモデルの出力を毎回浪費するため)。

メインモデルの責務

メインモデルが行うのは、リポジトリ全体の文脈が要る2つの判断だけ。

1. 対象範囲の決定: git status --short で状態を確認し、このコミットに含める個別ファイルを決める。
   • コミット対象の変更が無ければ、その旨を報告して終了する(空コミットはしない)。
   • 指定以外に既にステージ済みの変更があれば、混入を避けるためユーザーに知らせ、含める範囲を 確定してから進める。
2. 起動タイミング(指示ゲート・レビューゲート): 本スキルを起動してよいのは、ユーザーから コミットの明示的な指示があるとき(autonomous-dev のようにユーザーが明示起動したスキルの 手順に含まれる場合を含む)に限る。修正・実装の指示やレビューが収束した事実はコミット指示に ならない——指示が無ければ収束を報告して止まる。そのうえで、対象変更が収束した後だけ。 収束の定義・結末の種類(収束/千日手/要ユーザー判断)は review-loop-judgement の終了条件 が正。 反復レビューが codex-review-loop・fable-review-loop・opus-review-loop のいずれであっても 収束の定義は同一で、受理できる。 千日手・要ユーザー判断・未完了(実行中/stall/タイムアウト/失敗/ハング/判定未取得)では 本スキルを起動しない(ユーザーに諮る / tooling を直して取り直す)。レビューがハング・無出力で 完走しないとき、メインモデルの判断や合理化でコミットへ進むこと(=収束 verdict の代替)は禁止。 語検出による enforcement(不正条件の判定)はワーカーが行うので、メインモデルはここで語検出を 二重に実施しない。

呼び出し元がコミットメッセージ(件名・本文)を持ち込むのは禁止。渡してよいのは一行の意図ヒントだけで、 それを超える文面も、一行でもそのまま件名として通る一文も、ワーカーが不正条件として検出・停止する。

委譲の手順

1. 上記の責務1・2を満たすことを確認する。収束していなければワーカーを起動せず、ユーザーに諮るか tooling を直す。
2. Agentツールを subagent_type: "commit-worker" で起動し、プロンプトに下記「ワーカーへ渡す プロンプトの型」を渡す。commit-worker エージェントは frontmatter でモデルが固定されて いるため、呼び出し側で model パラメータを指定する必要はない(他モデルの指定・ 上書きも行わない)。
3. ワーカーの報告からコミットハッシュ・件名・残りの作業ツリー状態を確認し、ユーザーに報告する。 成功と確認できない報告なら、成功扱いにせずユーザーに知らせる。ワーカーが「不正コミットの疑い」で 停止した場合はコミットせず、その理由をユーザーに報告する。 ガードの deny や失敗を避けるために起草したメッセージを削った、形式を規約から外した (改行をエスケープ表記に置き換えて1行へ詰めた等)、または起草物と別の文面へ差し替えた旨の報告は 失敗として扱い、成功として次へ進めずユーザーに知らせる(この回避はワーカーが禁じられている)。 Co-Authored-By トレーラを省いたコミットも同じく失敗として扱う。 コマンドの形を試す目的のコミット(試行コミット)は、成立した時点で失敗として扱う。 報告された件名が diff の内容を述べていない間に合わせの文面なら、成功扱いにせずユーザーに知らせる。

ワーカーへ渡すプロンプトの型

作業ディレクトリ: <リポジトリルートの絶対パス>

ステージ対象ファイル(これだけを add):
- <file1>
- <file2>

反復レビュー(codex-review-loop・fable-review-loop・opus-review-loop のいずれか)の最終応答テキスト(原文・要約でない):
<<<
<verdict を含む原文をそのまま貼る>
>>>

レビュー済みファイルのリスト:
- <file1>
- <file2>

意図ヒント(原則「なし」): <なし。渡す場合は一行>

• ステージ対象は個別ファイルの明示リストにする(ディレクトリ、git add -A、git add . は渡さない)。
• 意図ヒントは原則「なし」で渡す。 渡してよいのは、コード差分だけでは分からない修正意図が あるときに限る。ヒントは、ワーカーが diff から起草する代わりにそれを写す誘因になる。差分が変更 内容を語っているなら、ヒントは起草を助けずに歪めるだけになる。
• 渡す場合も、作業過程参照(ステップ番号・レビューのラウンド番号・作業時点依存の日付・ 「改修前/改修後/今回」等の相対参照・一時ドキュメントへの参照)を書かない。ヒントの言い回しは 起草に引き継がれるため、メインモデルはヒントを書く時点で混入させない。
• 上記5フィールド以外を追加しない(実行モデル表示名を含む)。

対象外

--amend や rebase など履歴の書き換えを伴う操作はこのスキルの対象外。 メインモデルがユーザーに確認した上で直接行う。