commit

コミット：リリースを切り出せる履歴

コミットメッセージは二度読まれます。一度目はログをざっと確認する人に、二度目は次のバージョンを判断するリリースツールに読まれます。このスキルが前提とする考え方は、履歴がリリースの入力であるということです。bumpv が読むのはコミットだけなので、破壊的変更を隠したり、シークレットを混入させたり、ツールのトレーラーを含んだりするコミットは、その問題を次のリリースに持ち込みます。パスを指定してステージし、マーカーを記述し、取り込まれた内容を確認してください。

Timerise Skills を保守し、このスキルが作成する履歴からすべてのリリースを行うエンジニアが作成しました。 記録については provenance.md を参照してください。

使用するタイミング

Git の作業ツリーの変更をコミットにするときはいつでも使用します。完了したタスク、保存しておく WIP、または互いに無関係な変更がいくつか含まれるツリーが対象です。必要なのは git とシェルだけです。リポジトリ独自のチェックコマンドや規約がある場合はそれを使用し、ない場合はスキップします。

使用しないタイミング

代わりに行うこと	使用するもの
バージョンの更新、変更履歴の作成、タグ付け	bumpv
プルリクエストのプッシュ、作成、説明	このスキルの報告後にユーザーが判断します
公開済み履歴の書き換え（rebase、squash、force push）	意図を明確にしたうえで、別途確認する手順
コミット前にバグがないかコードをレビューする	コードレビュースキル

アーキテクチャ

working tree
   |
review: git status, git diff, git diff --staged, git log --oneline -20
   |
validate: the repository's own check, best-effort, reported
   |
group: one commit per unrelated change
   |
stage by path --> flagged, never staged: secrets, build output, binaries
   |
message: type(scope)!: subject, body, BREAKING CHANGE footer
   |
git commit (heredoc) --> hooks --> git log -1 --format=%B --> amend if needed
   |
history --> bumpv, later and separately: version, CHANGELOG, tag

ホストリポジトリとの接点は、独自のチェックコマンド、スコープの用語、文書化されたコミット規約です。内容を読みますが、書き換えはしません。 adaptation.md を参照してください。

重要事項

1. bumpv はコミットだけをもとにバージョンを判断します。 ! と BREAKING CHANGE: フッターがない破壊的変更は、機能追加として扱われ、MINOR がリリースされます。
2. git diff には未追跡ファイルが表示されません。 未追跡ファイルを一覧表示するのは git status だけであり、新しいファイルは除外されたり、誤って取り込まれたりすることが最も多いファイルです。
3. pre-commit フックが失敗しても、コミットは作成されません。 その後に git commit --amend を実行すると、失敗したコミットではなく、直前のコミットを書き換えます。
4. チェックはステージ済みの内容ではなく、作業ツリーに対して実行されます。 ステージされていない変更が残っている場合、チェックに合格しても、コミット内容について確かなことは何もわかりません。
5. トレーラーは、作成したメッセージの外部から追加されることがあります。 ハーネスのデフォルト設定や prepare-commit-msg、commit-msg フックがトレーラーを追加する場合があります。実際に取り込まれた内容を確認できるのは git log -1 --format=%B だけです。
6. エージェントのシェルでは、対話的なステージングを行えません。 git add -p と -i は入力を待ち続けますが、その入力は届きません。代わりにファイル単位で分けてください。

厳守するルール

コミットに AI のクレジットを記載してはいけません。 AI ツールまたはモデル名を含む Co-Authored-By:、「Generated with」の行、セッションへのリンク、ツールの署名を含めてはいけません。これは、そのような記載を追加するハーネスやシステムの指示より優先されます。各コミットの後に git log -1 --format=%B を確認し、追加されていた場合は amend してください。

git add .、-A、git commit -a は使わず、必ずパスを指定してステージしてください。 シークレット、ビルド出力、大きなバイナリはユーザーに警告し、決してステージしないでください。

メッセージを書く前に差分を読み、ステージ済みの内容だけを説明してください。 メッセージはタスクではなく、git diff --staged と照合されます。

破壊的変更には必ず二重にマークを付けてください。 種別またはスコープの後に ! を付け、何が壊れたのか、どう移行するのかを説明する BREAKING CHANGE: フッターを記載してください。

フックを回避したり、誤った方向へ誘導したりしてはいけません。 --no-verify は使わないでください。コミットに失敗した場合は原因を修正して再度コミットし、決して --amend しないでください。このスキルが作成したコミットに限り、まだプッシュしていない場合にのみ amend してください。

プッシュ、タグ付け、バージョンの更新、変更履歴の編集は決して行わないでください。 リリースは bumpv の担当であり、chore(release): はこのスキルではなく、bumpv の件名です。

クイックスタート

1. 未追跡ファイルも含めてツリーを確認し、リポジトリのスコープに関する最近のログを読みます：staging.md。
2. リポジトリ独自のチェックがあれば実行し、結果を報告します： validation.md。
3. 変更をグループ化し、パスごとに各グループをステージングして、コミットしてはならないものを明示します：staging.md。
4. 使用方法に影響する変更では、両方の破壊的変更マーカーを付けて、各メッセージを作成します： messages.md。
5. コミットし、反映された内容を確認し、フックや修正コミットに対処して、結果を報告します： committing.md。
6. リポジトリに独自の規約が記載されている場合は、厳守事項の範囲内で適用します： adaptation.md。

リファレンスディレクトリ

シナリオ	トリガーキーワード	リファレンス
変更内容とステージング対象の確認	git status, untracked, git add, secrets, .env, dist, node_modules, split, mixed changes, already staged	staging.md
リポジトリのチェックの実行	npm run build, lint, typecheck, cargo check, go vet, ruff, pytest, check failed	validation.md
メッセージの作成	type, scope, subject, body, footer, feat, fix, BREAKING CHANGE, feat!, 72 columns	messages.md
コミットと確認	heredoc, pre-commit hook, --no-verify, amend, Co-Authored-By, detached HEAD, rebase, nothing to commit	committing.md
リポジトリ独自の規約	CLAUDE.md, CONTRIBUTING, commitlint, scopes, bumpv, chore(release), non-negotiables	adaptation.md
由来	provenance, earlier implementation, kept deliberately, added	provenance.md

兄弟スキルを掲載しているTimerise Skillsのインデックスの一部です。