Commit
コミットは、一年後に誰かがインシデント対応でプレッシャーの中読む最小の履歴単位です。その読み手のために最適化しましょう。
ワークフロー
- コミット前に確認：
git status、git diff --staged、git diff。決して盲目的にコミットしないでください。 - 絶対に含めてはいけないものを確認：認証情報、
.envファイル、秘密鍵、大きなバイナリ、デバッグ用プリント、コメントアウトされたコード。見つかったら停止し、ユーザーに伝えてください。secrets-hygieneスキルを参照してください。 - 意図的にステージングする。
git add -Aよりもgit add <paths>を推奨します。1コミットにつき1論理変更；diffにリファクタリングと機能追加が混在している場合は分割してください。 - 以下の形式でメッセージを書きます。
- ヒアドキュメントを使ってコミットすると、複数行の本文がシェルでそのまま維持されます：
git commit -m "$(cat <<'MSG'
feat(auth): add OIDC login for the admin console
Replaces the shared basic-auth password with Cognito-backed OIDC so
access can be revoked per user. Sessions expire after 8h.
Refs: PLAT-412
MSG
)"
git log -1 --statで確認します。ユーザーが明示的に依頼しない限り、修正（amend）や強制プッシュ（force-push）はしないでください。
メッセージの形式
<type>(<scope>): <命令形のサマリ, 72文字以下, 末尾にピリオドなし>
<なぜこの変更が必要か — diffはすでに何が変わったかを示しているので、それではなく理由を書く>
<フッター: Refs/Closes チケット, BREAKING CHANGE: ..., Co-Authored-By>
タイプ：feat、fix、refactor、perf、test、docs、build、ci、chore、revert。
スコープは対象のモジュール、サービス、スタック（api、terraform/vpc、ci）。変更が全体的な場合は省略します。
本文はサマリよりも重要です。「なぜ今なのか？」「何を検討したのか？」を2〜4文で答えてください。些細な変更であれば1行コミットでも構いません。
例
入力: S3バケットにタグがない場合のヌルポインタを修正した
出力: fix(s3-inventory): handle buckets with no tag set
入力: terraformのawsプロバイダを5.40から5.60にバンプした。新しいlambdaランタイム属性に必要 出力:
build(terraform): bump aws provider to 5.60
Required for `aws_lambda_function.runtime = "python3.13"`. No resource
diffs on `terraform plan` across all stacks.
$ARGUMENTS が与えられた場合
ユーザーからのスコープまたはサマリのヒントとして扱いますが、それでもdiffを確認し、実際の変更と一致しない場合は修正してください。