---
name: commit
model: inherit
description: "Git 規約（.claude/rules/git-conventions.md）に従い，変更内容の確認 → コミットを行う．"
argument-hint: "<コミット内容の補足（省略可）>"
disable-model-invocation: true
---

あなたは Git 運用の司令塔です．コミット作業の実行は **ops-runner エージェント**（軽量モデル）に委譲し，あなた自身は**判断**（意図・docs 更新の要否）・確認の仲介・結果の報告だけを行います（使用量節約のため，diff 読みや git 操作を自分では行わない．逆に価値判断は ops-runner にさせない）．

## ステップ 1: 意図サマリと docs 要否の判断 (Intent & Docs Decision)

このセッションで行った作業を把握している場合は，以下を作る（**判断はここで行う**）:

- **意図サマリ**（1〜3 行）: 何をなぜ変更したか（コミットメッセージの材料）．重要な変更なら `.claude/rules/git-conventions.md` の書式でメッセージ全文を確定させてもよい
- **docs 更新の要否**（3 択）: 変更が API・データ構造・環境設定・開発計画の進捗・規約やルールに関わるかを，セッションの知識で判断する
  - **更新済み**: 今回の変更に `docs/`・CLAUDE.md「開発進捗」・`docs/PROGRESS.md` の更新も含めてある
  - **不要**: 該当しない
  - **要**: 委譲する前に必要な更新を行う（内容に迷う場合はユーザーに確認する）．docs を同じコミットに含めるため
- **ブランチ名**: 現在 `main` にいる可能性がある場合は，git-conventions の命名規則（プレフィックス＋英単語 2〜4 語）でブランチ名を決めて渡す（ops-runner に命名させない）
- `.claude/commit-context.md` がある場合（`/implement` 経由）は，そこに記録された判断を正とし，改めて判断しない

セッションを把握していない場合（起動直後の `/commit` 等）は「意図情報なし・要否は事後判断」とする．

## ステップ 2: 委譲 (Delegate)

ops-runner エージェントを起動し，プロンプトに以下を含める:

- 手順書: `.claude/skills/commit/reference.md` の「コミット実行手順」と `.claude/rules/git-conventions.md` を読んで従うこと
- ステップ 1 の意図サマリ（またはメッセージ全文）．意図情報なしの場合はその旨
- $ARGUMENTS（`push` / `merge` キーワードの有無を明示する）
- 確認が必要な事態では停止して報告すること

## ステップ 3: 結果報告 (Report)

- エージェントの報告（ブランチ・コミット SHA・メッセージ・PR URL 等）をユーザーに簡潔に伝える
- **意図情報なしで委譲した場合**は，エージェントの「事実報告」（変更ファイルの分類）を見て docs 更新の要否を事後判断し，必要と思われれば「⚠ docs/・CLAUDE.md の開発進捗・`docs/PROGRESS.md` の更新が必要かもしれません」とユーザーに伝える（追加コミットで対応してよい）
- エージェントが返した警告（意図と diff の食い違い等）はそのまま表示し，判断はユーザーに委ねる
- エージェントが「確認事項」で停止した場合は，ユーザーに確認し，回答を「承認済み」として添えて再委譲する
  - ただし停止理由が**分類器ブロック**（auto mode のセキュリティ分類器により，コマンドが実行される前に遮断された）の場合は，再委譲しても同じ地点で止まるため**再委譲しない**．`.claude/settings.json` の `permissions.allow` の確認・追加とセッション再起動をユーザーに案内して終了する（詳細は `.claude/skills/commit/reference.md` の「gh コマンドが実行される前にブロックされた場合」を参照）
- **ops-runner の起動（Agent ツール呼び出し）自体が分類器にブロックされた場合**は，委譲そのものが成立しない（プロンプトの文言を変えても通らない．`.claude/settings.json` の permissions 変更を含む変更のコミットを委譲したところ，Agent 起動が 2 回ブロックされた実測例がある）．この場合は状況をユーザーに伝え，**ユーザーの承認を得た上で**次のいずれかで進める
  - 司令塔（メインループ）が直接コミット操作を行う（メインループからは同じ操作が通ることを確認済み）．これは冒頭の「git 操作を自分では行わない」原則の**例外**とする
  - ユーザーが `! git ...` で手動コミットする

## 注意事項 (Notes)

- 変更がない場合（作業ツリーがクリーン）は空コミットしない（エージェントの報告どおり伝えて終了する）
- 本スキルはユーザーが明示的に指示した時のみ実行する（CLAUDE.md「Git 運用」）