`git commit` / `git commit --amend` を実行する前、または「commit」「amend」「コミット」「コミットして」の一語・短文だけを渡された時点で必ず発火する git コミット実施ルール。理由や差分の説明が一切無くても、ファイル全文を読んでメッセージを組み立てる前に先に参照する。
主目的は論理的に独立した修正を都度・適切な粒度でコミットすること。メッセージは Conventional Commits 形式、素材は同梱の決定論スクリプト commit-context.sh が出す staged diff のみ。
「コミット分けて」と依頼される、独立した複数修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase / squash / cherry-pick 後のメッセージを整える、`gh pr create` の PR タイトルをコミット流儀へ揃える場面でも参照する。
plan モードでのコミット計画の立案は commit-plan スキルの領分。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
優先度順:
scripts/commit-context.sh が出す staged diff のみ（§4）メッセージ書式より粒度と都度コミットが本質。plan モードでのコミット計画の立案は commit-plan スキルの責務（本スキルはその計画を実施する側）。
plan のコミット計画（commit-plan スキルで立案）に従い、各単位で 編集 → テスト → git commit を 1 サイクルとして繰り返す。次の作業に進む前に必ず前のコミットを確定させ、一括編集→git stash/部分 add での後分割はしない。
plan にコミット計画が無くても、論理的に独立した複数の修正（複数レビューコメント対応・複数の独立バグ修正など）は原則として個別コミット。例外はユーザーから「一括でやって」「後でまとめて」と明示指示された場合のみ。
分割する: 別の関心事／片方だけ revert したくなる可能性／別 discussion・別 issue の対応。 統合する: 同じ論理変更を機械的に行数で割っただけ／片方だけ戻すと壊れる／同じ discussion 内の一連の修正。
「コミット数が増えるから 1 つにまとめる」は採用しない。同じ基準を計画段階で適用するのは commit-plan スキル。
Merge branch ...）は Git 自動生成のため対象外git revert 自動生成）は接頭辞 revert: のまま使えるgit commit / git commit --amend のメッセージを書く前に、素材収集を同梱スクリプトに任せる。git status / git diff / git log を手で並べ直さない（staged / unstaged の取り違え・見落としの元）。
bash <skill-dir>/scripts/commit-context.sh [max-diff-lines]
=== SECTION === 区切りの出力を読み、以下を厳守する:
STAGED DIFF セクションのみ。ファイル全文の Read・過去の記憶・会話に残る別リポジトリの文脈を根拠にしない。+ 行だけが「追加した」、- 行だけが「削除した」。無印のコンテキスト行は今回の変更ではないので、メッセージに書かない（既存行を「追加した」と書く事故の直接対策）。STAGED FILES が「(なし)」なら素材が無い。UNSTAGED / UNTRACKED から何をステージするかを決め（ユーザーの明示指示があればそれに従い、無ければ候補を提示して確認）、ステージ後にスクリプトを再実行してから書く。RECENT COMMITS と SCOPE CANDIDATES で type / scope をリポジトリ慣習に揃える。type は種別（feat / fix …）、scope は括弧内の対象領域 — 混同しない。IN-PROGRESS OPERATION に WARNING（merge / rebase 等の進行中）が出たら、通常コミットせず状況をユーザーに報告する。STAGED DIFF が行数上限で省略されたときだけ、git diff --cached -- <path> で範囲を絞って直接補完してよい。Conventional Commits 1.0.0 に従う。形式:
<type>(<scope>): <description>
主要 type: feat / fix / refactor / test / docs / chore / build / ci / perf / style / revert
詳細（type 一覧の解説、body／footer、破壊的変更の書き方、例、アンチパターン）は references/conventional-commits.md を参照。type 選択に迷う・破壊的変更を含む・PR タイトル整形時など、書式判断が必要な場面で読み込む。
Claude Code の既定動作はコミットメッセージ末尾に Claude-Session: <URL> のようなセッションへのリンク行を付与するが、このリポジトリでは付与しない。ローカル CLI・remote-control のどちらのセッションでも、コミットメッセージは本文（type/scope/description・必要な body・footer）のみで完結させ、セッションURLの行は書かない。
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Claude Code の並列エージェント(agent teams・teammate)の後始末と無応答時の打ち切りルール。`name` を付けて Agent を起動するとき、TeamCreate でチームを組むとき、teammate から `idle_notification` が届いたとき、評価ループ等で次のイテレーションのエージェントを起動する前、エージェントの返信が届かないときに参照する。`name` を付けない通常のサブエージェント起動だけなら対象外。
spec.md の REQ-# を入力に、機能一覧・モジュール構成・インターフェース・データフローを持つ docs/dev/<対象>/basic-design.md を作成・改訂するスキル。/basic-design <対象名> で明示的に呼び出されたときのみ使用する。
技術的な内容を、技術用語を排したビジネス職向けの平易な説明文に翻訳する。`/biz-translate` と明示的に呼ばれたときのみ実行する。
実装計画・リファクタリング計画・レビュー対応計画・並列作業のタスク分解など、計画を成果物として書き出すときに必ず参照するコミット計画ルール。plan モードでは ExitPlanMode で plan を提示する前に必須、計画ドキュメントや job-graph のタスク分解・エージェントへの指示文でも同様に適用する。計画成果物にコミット計画セクション（論理的に独立した修正単位での分割と Conventional Commits 形式のメッセージ）が無ければ実装に入らない。「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画を立てて」「コミット計画を立てて」「タスクを分解して」と依頼される、複数の独立した修正をまとめるか分けるか計画段階で判断する等の場面では、ユーザーが「コミット」に一切言及していなくても必ず発火する。コミットの実施（素材収集・メッセージ確定・git commit 実行）は commit-flow スキルが担う。
プロジェクトに 1 つの「完成の定義」docs/dev/definition-of-done.md を対話で構築・改訂し、機械判定節と人判定節の二部構成で書き出すスキル。/def-done で明示的に呼び出されたときのみ使用する。
「レビューして」「diff をレビュー」「〇〇観点で見て」「PR に出す前にセルフレビュー」などユーザーがコードレビューを依頼したら、観点・レンズ名を挙げていなくても必ず使用する。作業ブランチの diff を複数観点(design / test / yagni、条件付きで spec 等)で並列レビューし統合報告するオーケストレーションスキル。既定は diff 内で完結する fix 指摘のみで、既存コードへの改善提案(リファクタ候補の洗い出し)は起動引数 --improvement の明示時のみ報告する。コードの修正は行わない。