commit-push

このスキルが起動した時点で、ユーザーが「コミットとプッシュをしてよい」と明示的に承認した状態とみなす（ /commit-push を打つ行為自体が decide_or_ask.md の言う「一意に読める指示」に該当する）。確認質問は挟まず、即実行する。

進め方

1. 状態把握 (並列実行)

   • git status で未追跡 / 変更ファイルの一覧
   • git diff と git diff --staged で差分内容
   • git log --oneline -5 で直近のコミットメッセージスタイル参照

2. 早期離脱判定

   • 変更が無ければ「変更なし」とだけ報告して終了。空コミットは作らない
   • .env / credentials / 秘密鍵らしきファイルが含まれていたら警告して停止し、ユーザー判断を仰ぐ

3. コミットメッセージのドラフト (~/.claude/rules/karma_commit_style.md に従う)

   • 1行目は <type>(<scope>): <subject> の形。type(scope): は英小文字、subject は 日本語の体言止め（「〜の追加」「〜の修正」「〜の分離」など）
   • subject 末尾にピリオド・句点なし。50文字目安
   • 本文が必要なら1行空けて「なぜ・何を」を書く。コミットに至った経緯ではなく 差分の意図 を書く
   • 末尾に生成者のトレーラーを置く。文言はルール側が持つ（ karma_commit_style.md の「生成者のトレーラー」）

4. ステージング & コミット

   • 既にステージ済みのものがあればそれを尊重しつつ、未ステージの変更は 対象ファイルを名指しで git add <path>... する（ git add -A / git add . は使わない）
   • コミットメッセージは HEREDOC で渡す。

     git commit -m "$(cat <<'EOF'
     <type>(<scope>): <subject>
     
     <body if any>
     
     Co-Authored-By: Claude Code <noreply@anthropic.com>
     EOF
     )"
     

   • --no-verify / --no-gpg-sign などのフック回避フラグは使わない。例外は下記の「フックが重い場合」だけ
   • --amend は使わない（必ず新規コミット）

5. pre-commit hook 失敗時の挙動

   • フックで止まったならコミットは作成されていない。原因を読み取り、修正し、再ステージし、新規コミットを作る（amend しない）
   • 再試行しても解消しないならエラー内容を要約してユーザーに報告し停止

6. フックが重い場合（全テストを同期実行する等でコミットが数分ブロックする）

   • 飛ばす前に、そのフックが何を見ているか読む。 --no-verify は1つのフラグで全部のフックを飛ばすので、避けたい重い検査だけでなく、テスト以外を見るもの（固有名の走査・秘匿値の検出）まで一緒に消える
     • 読む対象は設定ではなく中身。 入口はリポジトリごとに違い（ core.hooksPath を指すもの、lefthook が .git/hooks へ書くもの）、設定を見ただけでは「フックが無い」と誤読する
     • ステージした範囲で検査対象が変わるものがある（公開側のファイルだけを走査する等）。フックの名前からは分からない
   • 同じ検証を自分で先に済ませてからフックを飛ばす。土台は background_heavy_work.md
   • 順序は「フックの中身を読む → 見ているものを自分で流す → 通ったことを確認する → --no-verify でコミット」。流す対象は読んだ結果で決まるので、テストと lint に固定しない
   • 検証せずに飛ばさない。 それは手抜きであって時間短縮ではない
   • 飛ばしたことと、代わりに何を通したかを報告に必ず書く

7. プッシュ

   • 現在のブランチを追跡先リモートへ git push する
   • --force / --force-with-lease は使わない。push が拒否されたら原因（リモート先行など）を報告してユーザー判断を仰ぐ
   • 上流未設定なら git push -u origin <branch> で初回プッシュ

8. 完了報告

   • 変更ファイル数 / 増減行数を1行で報告
   • push したコミットを1行ずつ列挙する: <短縮ハッシュ> <subject> を全件並べる（ git log --oneline <oldsha>..<newsha> の出力をそのまま貼る形。報告にレンジ表記は使わない（ report_formatting.md ））
   • コミット後に変更が残っていない（ working tree clean ）ことを確認

9. PR の鮮度を確認（PR がある場合のみ）

   • push で差分が動いたので、本文と補足コメントが実態と食い違っていないかを見る（ keep_records_current.md ）
   • ズレていれば /update-pr-description を案内する。このスキルでは直さない
   • AI レビューを回すかはユーザーに尋ねる。1周ごとに課金されるので自動で回さない

出力の目安

• 通常時: 変更ファイル数と増減行数を1行 + push したコミットを1行ずつ列挙（レンジ表記は使わない）
• 変更なし: 「変更なし」の1行で終わる
• フックで止まった / push が拒否された: 原因と、ユーザーに求める判断を簡潔に

やってはいけないこと

• 確認質問を挟むこと（このスキルが呼ばれた時点で承認済み）
• git add -A / git add . での一括ステージ
• git commit --amend での既存コミット書き換え
• 検証せずに --no-verify 等でフックを回避すること（同じ検証を自分で済ませた場合のみ可。手順6）
• フックの中身を読まずに --no-verify を打つこと。1つのフラグで全部飛ぶので、避けたい検査とは別のもの（固有名の走査・秘匿値の検出）まで消える。「テストは通した」は代替になっていない
• git push --force / --force-with-lease
• 主ブランチ (main / master) への直接 push
• メッセージを動詞終止形（「〜した」「〜する」）や命令形にすること（体言止めで統一）
• subject に「PR レビュー対応」「指摘修正」のような meta 情報を入れること（差分の意図そのものを書く）