--- name: commit description: > git commit作業（通常commit・amend・fixup）に着手する直前、 またはコミットメッセージ案（計画ファイル・PR説明など）を書く時点で起動する。 # 編集時の注意点: # コミット境界判断のSSOTは本ファイル「通常commit」節。 # 本文中の判断分岐・規範削除・機能的な規範変更はchoreへ分類しない。 --- # コミット運用とコミットメッセージ 本スキルは、git commitの操作手順とコミットメッセージの記述規約を提供する。 ## 検証 作業が一段落したら、対象に近いformat、lint、testを実行し、警告ゼロを確認してからコミットする。 検証コマンドの出力は切り詰めず、長大な出力は管理対象一時領域へ保存して必要箇所を抽出する。 全コミットの完了後に計画全体を最終検証し、レビューへ進む。 ## 通常commit コミット数はセッションや計画ごとに固定せず、変更目的、依存関係、レビュー、revert時の理解しやすさを 基準に境界を決める。計画の想定commit単位がある場合はその単位を起点とし、各単位で実装、近接検証、 差分確認、commitを反復する。各中間`HEAD`も当該時点の公開契約とテストを満たす状態にする。 コミットはメインが所有する。サブエージェントは明示的に許可された場合、または計画実装の正規手順として 指定された場合だけcommitできる。`git push`は委譲先へ明示された場合を除き呼び出し元が所有する。 別セッションが同一リポジトリへコミットしうる前提で作業する。 編集の直前に対象ファイルを再取得し、コミットの前に基準コミットを再確認する（努力目標）。 自セッションの担当範囲だけをステージし、担当外の変更を混入させない（厳守規定。 他セッションの未完成の変更を巻き込むとコミットが技術的に成立しない）。 1つのセッションで複数のリポジトリを扱う場合、`git`コマンドは`-C <絶対パス>`で対象リポジトリを明示し、 同一のコマンド列へ`cd`と`git`を並置しない（努力目標）。 commit直前に次を実施する。 1. `git status --short`、`git diff --cached`、`git diff`で現在の単位だけがstage済みであることを確認する 2. 計画記載の目的及びファイル群別の変更説明と、実装中に目的への帰属と必要性を確認した追加変更を、差分と特徴的な文字列で照合する 3. format、lint、testの結果と警告ゼロを確認する 4. 競合解決後は`git grep -nE '^(<{7}|={7}|>{7})( |$)' -- .`で競合マーカーが無いことを確認する 5. commit後に`git status --short`と`git show --stat --oneline HEAD`で成果を実測する ユーザーの未コミット変更を混入させない。pre-commitのstashが競合する場合だけ、対象ファイルへ正式な検査を 実行済みであることを条件に`--no-verify`を使用できる。検証省略やhook失敗の回避には使用しない。 ## 条件付き手順 - amend、fixup、autosquashを行う直前に`agent-toolkit/skills/commit/references/history-rewrite.md`を全文読む - 実際にpushする直前に`agent-toolkit/skills/commit/references/push-and-ci.md`を全文読む - CI失敗を扱う直前に`agent-toolkit/skills/bugfix/references/ci-failure-handling.md`を全文読む - 計画実装の履歴契約を扱う時は`agent-toolkit/skills/plan-mode/references/implementation-task.md`を全文読む - push済みcommitのamend、fixup、rebaseは禁止する。push済み判定は `agent-toolkit/skills/commit/references/history-rewrite.md`のremote-tracking ref到達判定を用いる - push後のCI失敗は`agent-toolkit:bugfix`を起動し、同スキルのCI失敗契約で原因を分析する ## 作業用ブランチと退避物の削除 退避・バックアップ・実験などのために作成した一時ブランチ、`git stash`による退避、別パスへの複製は、 当該目的を達した時点で削除する。 委譲先の完了報告が退避識別子または複製パスを開示した場合は、呼び出し元が受領時の検収で本節により処置する。 委譲先へ退避の破棄を禁じる規定は判断主体を呼び出し元へ移す規定であり、移された側の義務を定める本節と対にする。 削除前の照合は退避手段別に行う。 - 一時ブランチ: `git cherry -v <統合先> <対象ブランチ>`と `git diff --diff-filter=A --name-only <統合先>..<対象ブランチ>`を実行し、 統合先に同等の変更があることと、当該ブランチにのみ存在するファイルが無いことを確認する。 cherry-pickと履歴一本化を経た統合先はpatch-idが一致せず`git cherry`が成立しないため、 対象ブランチの変更ファイル集合に対する`git diff <対象ブランチ> <統合先> -- `と、 差分が出たファイルの個別確認へ切り替える - `git stash`: `git stash list`で対象を特定し、`git stash show --include-untracked -p <識別子>`で 追跡分と未追跡分の双方の内容を確認する（未追跡分だけを確認する場合は`--only-untracked`を使う）。 追跡分と未追跡分のそれぞれについて採用差分か破棄差分かの帰属を確定し、 採用差分であれば統合先への反映を確認したうえで`atk worktree-stash drop '<識別子>'`により 固定ロック下のOID再照合と削除を完了する - worktree固有refへ退避した場合は`git stash show --include-untracked -p refs/worktree/<退避ラベル>`で照合し、 `atk worktree-stash drop refs/worktree/<退避ラベル>`で同じ削除経路を使う - 別パスへの複製: `diff`で複製元と複製先の内容を照合する いずれかの帰属または反映状況が未確定である間は削除しない。 保持する場合は保持理由と削除条件を記録し、理由を記録しないまま残さない。 ## コミットメッセージとリリース コミットメッセージ第1行は「件名」と呼び、コミット文脈の記述で本表記に統一する。 コミットメッセージはConventional Commits形式で書く（プロジェクト方針が無い場合）。 プロジェクト方針で固定文言体系（カテゴリ名・固定件名等）が指定されている場合はそれに従い、 以下の形式は適用しない。 プロジェクト方針は、当該リポジトリの`CLAUDE.md`・`AGENTS.md`・`.claude/rules/`配下、 コミットテンプレート、lint設定などの明文化された情報から確認する。 明文化された方針が扱わない事項では、同種の複数コミットで一貫して観測され、 明文化された方針と矛盾しない形式だけをプロジェクト内の慣例として優先する。 単発のコミット履歴は慣例の根拠にしない。 方針と履歴が矛盾する場合は`agent-toolkit/rules/01-agent.md`「規範と実態の照合」に従う。 - 形式: `[()]: `。破壊的変更は`!`を付ける - typeは当該リポジトリのエンドユーザー振る舞いへの影響を基準に選ぶ - 「エンドユーザー」はリポジトリの性質で変わる アプリ・サービスではエンドユーザー、開発者向けツール・ライブラリではそれを使う開発者、 配布物（プラグインなど）では配布先でのエンドユーザーやエージェントが該当する - 「当該リポジトリの開発者」と「エンドユーザー」を混同しない 個人の開発設定だけが変わり配布先振る舞いに影響しない変更は内部的な変更に分類する - `feat`/`fix`/`perf`: 機能追加・バグ修正・性能改善 - `chore`/`ci`/`refactor`/`docs`/`test`: エンドユーザー振る舞いに直接影響しない内部的な変更・軽微な修正など - scopeは変更範囲が一意に伝わる短い名詞（モジュール名・ディレクトリ名・機能名など）を任意で付ける 同一モジュール・同一機能で閉じる変更でのみ付与し、複数モジュールに跨る変更や範囲が曖昧な変更では省略する - `!`もエンドユーザー振る舞いへの影響を基準に判断する lint/format設定・CI/ワークフロー手順・依存グループ入れ替えなど開発者向け設定の変更には付けない - 本文中の判断分岐・規範削除・機能的な規範変更は`chore`ではなく`fix`または`refactor`を選ぶ - descriptionは日本語でユーザー向けの表現で変更内容を簡潔に説明する - リリースノートへの転記時にscope部分が省略される場合があるため、 description単独で対象範囲と意図が伝わる粒度で書く（scope情報をdescription側にも自然に含める） - 識別子は読者基準で選ぶ。エンドユーザーが呼び出す・設定する・目にする対象 （ツール名・コマンド名・設定ファイル名・公開機能名など）は原表記で書く - 言い換えはエンドユーザーが知り得ない内部実装の識別子（内部関数名・git configキー名など）に限り、 対象を一意に特定できる語を選ぶ。曖昧な一般名詞への機械的な置換で対象を特定できなくしない - NG例: `ci: 検査ジョブのツール管理器の入れ替えを行う` 開発者向けリポジトリの読者はmiseを直接設定するため、「ツール管理器」への言い換えは対象の特定を妨げる - OK例: `ci: 検査ジョブのmise入れ替えをキャッシュ復元後に行う` - NG例: `chore: setupで.gitmessageをcommit.templateへ登録する` `commit.template`はエンドユーザーが操作しない内部キーのため言い換え対象となる - OK例: `chore: コミットメッセージ雛形の自動登録を追加する` - NG例: `feat(vitest): JSON reporter併用でテスト失敗を構造化する` scope省略時に対象ツール（vitest）が消えて何のテストか分からなくなる - OK例: `feat(vitest): vitestのテスト失敗をJSON reporter併用で構造化する` - 計画ファイルにコミットメッセージ案を書く時点でも上記基準でセルフチェックする - 本文（body）は任意。記載する場合はwhyを大雑把なサマリー粒度で書く - ファイル名や実装詳細レベルの描写は避け、エンドユーザーが理解できる粒度に留める - コミット帰属文字列は、ユーザーの明示指示、明文化されたプロジェクト方針、 実行環境が提示する既定値の順で観測できる最初の定義から決定する。 観測できない場合はモデル名や既定形式を推測して補わず、空文字列の指定は帰属の明示的な無効化として扱う。 帰属情報は最終コミットメッセージへ1回だけ付け、既存の異なるtrailerを保持する フィードバック採用（`atk mq adopt`起因）を反映するコミットは、本文（body）へ 「再発予防: <検討結果を要約した1行>」行を必ず含める（「本文は任意」規定の例外。 採用フィードバックが複数なら複数行でよい）。 要約は計画ファイルの`## 恒久化・リファクタリング内容`にある再発防止の判断と一致させる。 リリース操作に着手する時点で`agent-toolkit/skills/commit/references/push-and-ci.md`を全文読み、同文書のリリース手順を適用する。