git-commits

Git コミット

これは厳格なガイドラインです。 これらのルールに正確に従ってください。

開発者を支援する際に、Git のコミット、ブランチ、PR を作成し、書式を整える方法です。

---

🚨 コミット前のゲート

コミットメッセージを作成する前に、ステージ済みのすべてのファイルに対して pre-commit-check スキルを実行してください。以下の項目を確認します。

1. セキュリティ — 認証情報、シークレット、.env ファイル（security-checklist に委任）
2. コード品質 — DRY、命名、エラー処理、デッドコード（core-principles を参照）
3. 破損リスク — ビルド、テスト、Lambda の呼び出し、環境変数の不足

3 つのゲートすべてに合格するまで、コミットのグループ分けに進まないでください。

ゲートの実行後、結果と使用した方法を簡潔に確認してください。

• 「コミット前チェックに合格しました（pre-commit-check スキルを使用）— セキュリティ上の問題はなく、コード品質に問題はなく、ビルドを検証済みです。」
• 「コミット前チェックに合格しました（インラインの代替手段を使用 — pre-commit-check スキルが見つかりませんでした）— ステージ済みファイルにシークレットはありません。」

セキュリティの代替手段

pre-commit-check または security-checklist を利用できない場合は、これらのルールを直接適用してください。セキュリティチェックを省略してはいけません。

ステージ済みファイルをスキャンし、以下を確認してください。

• 実際の値を含む .env ファイル（.env、.env.local、.env.prod、.env.* など、すべての種類）
• コード内にハードコードされたシークレット、API キー、トークン、パスワード
• AWS 認証情報、秘密鍵（*.pem、*.key）、接続文字列
• .git-credentials、.netrc、認証情報の JSON ファイル

見つかった場合は、直ちに作業を停止し、開発者に警告して、解決されるまで先に進まないでください。

---

コミットメッセージの形式

構成：

<type>: <description>

ルール：

• 1 つのコミットにつき、論理的な変更は 1 つ
• 1 行のみ（複数行のコミットは禁止）
• 命令形：「Add」「Create」「Fix」「Update」（「Added」「Adding」ではない）
• 具体的かつ簡潔にする

種類：

• feat - 新機能
• fix - バグ修正
• refactor - コードの再構成（動作の変更なし）
• docs - ドキュメントのみ
• style - 書式、空白
• test - テストの追加・更新
• chore - ビルド、設定、依存関係

例：

feat: Add user authentication flow
fix: Resolve database connection timeout
docs: Update API endpoint documentation
refactor: Extract validation logic to separate function

---

コミットのグループ分け戦略

分析基準

次の場合は、ファイルを同じグループにまとめます。

• 同じ機能を実装している
• 同じバグを修正している
• 同じリファクタリングの一部である
• 強い依存関係がある（片方がもう片方を必要とする）

次の場合は、ファイルを分けます。

• 目的が異なる（機能、リファクタリング、ドキュメント）
• 異なる機能やコンポーネントを変更している
• 独立して動作できる
• 異なる論理的な変更を表している

目的別のグループ分け

次の観点から変更を分析します。

• 目的：どのような問題を解決するか？
• 範囲：コードベースのどの領域か？
• 独立性：単独で成立するか？
• 依存関係：ほかの変更に依存しているか？

一般的なパターン：

• 新機能 = コンポーネント + 型 + ユーティリティ + ドキュメント
• リファクタリング = 機能とは分けたコード品質の改善
• バグ修正 = 問題に絞った最小限のファイル
• 設定 = package.json、環境、ビルドファイル

---

プロセス

開発者からコミットの支援を求められた場合：

1. 🚨 コミット前のゲート - ステージ済みファイルに対して pre-commit-check スキルを実行（セキュリティ、品質、破損リスク）
2. 変更を分析 - 実際の変更を確認するために Git コマンドを実行する（推測しない）
3. 論理的にグループ化 - ファイルの種類ではなく、目的に基づいて整理する
4. メッセージを作成 - 選択した形式（シンプルまたは Conventional Commits）に従う
5. 承認を求めて提示 - コミットグループと、影響を受けるファイルを表示する
6. 承認を待つ - 開発者が使用中のツールでステージングとコミットを行う

---

出力例

シンプルな形式

Commit 1: Add user authentication logic
Files:
- auth.ts (authentication functions)
- types.ts (auth types)

Commit 2: Update database schema
Files:
- schema.ts (user table changes)

Conventional Commits

📦 Commit 1: feat: Add user authentication flow
Files:
- frontend/contexts/auth-context.tsx (auth state management)
- frontend/hooks/use-auth.ts (auth hook)
- frontend/types/auth.ts (type definitions)
Group: Authentication feature - all related

📦 Commit 2: refactor: Extract API client utils
Files:
- frontend/lib/api-client.ts (extracted from inline code)
- frontend/utils/fetch-helper.ts (helper functions)
Group: Code quality - independent refactoring

📦 Commit 3: docs: Update authentication setup guide
Files:
- docs/guides/authentication.md (auth flow documentation)
Group: Documentation - separate from code

---

ブランチと PR

ブランチを作成するタイミング：

dev に直接コミットします：

• プロジェクトのセットアップ、ひな形の作成
• Docker／devcontainer の設定
• リント、フォーマットの設定
• 小規模なバグ修正（数行程度）
• 依存関係の更新
• 軽微な設定の調整

dev からフィーチャーブランチを作成します：

• 機能全体（新しい機能）
• 大規模なバグ修正（複数のファイル、複雑なロジック）
• 大規模なリファクタリング
• 複数の論理的なコミットや作業セッションにまたがるもの

目安：変更が数行のコードで完結するなら、dev にコミットします。レビュー時の背景説明を添えた独自の PR が必要なら、ブランチを作成します。判断に迷う場合は、確認してください。

ブランチの命名：

• 種別の接頭辞を付けた、内容が分かりやすいケバブケースの名前を使用します：feat/user-profile、fix/auth-timeout
• 計画フェーズへの言及は絶対に避けてください：phase-1、step-2-3 などは使用しません。
• 計画ドキュメントは追跡対象ではないため、Git の履歴で言及しても意味がありません。

PR タイトル — 平易で説明的なもの（Conventional Commits 形式ではありません）：

• PR の内容を平易な英語で説明します。
• feat:、fix:、chore: の接頭辞は付けません。種別はブランチ名とラベルで示します。
• 命令形にし、先頭を大文字にします。

# ✅ Good PR titles
Add scales browser UI
Fix test runner in CI
Migrate devcontainer to ai-standards

# ❌ Bad PR titles (don't use conventional commit format)
feat: Add scales browser UI
chore: Migrate devcontainer to ai-standards

# ❌ Bad PR titles (auto-generated GitHub defaults)
Dev
Fix/auth timeout on mobile

PR で Conventional Commits を使わない理由： バージョン管理はラベルに基づいています（main への PR に付ける major／minor／patch ラベル）。PR タイトルは人が読むためのものなので、簡潔にしてください。

例：

# ✅ Good branch names
git checkout -b feat/user-profile
git checkout -b fix/auth-timeout
git checkout -b update-api-endpoints

# ❌ Bad branch names (no planning references)
git checkout -b phase-1-setup
git checkout -b step-2-3-implement-auth
git checkout -b task-1-2-database

バージョン管理：

• main へのマージ時に GitHub Action が自動で処理します。
• PR ラベル（major、minor、patch）によってバージョンの更新幅が決まります。
• コミットや PR タイトルにバージョン番号を手動で記載しないでください。

---

ガイドライン

• まずコミット前チェックを実施：作業を進める前に、必ず pre-commit-check を実行します。
• まず変更を分析：実際の変更内容を確認するため、必ず git status と git diff を実行します。
• 論理的にまとめる：ファイルの種類ではなく、機能や修正ごとにまとめます。
• 行範囲は記載しない：具体的な行番号ではなく、ファイルだけを列挙します。
• 承認を待つ：明示的な承認なしにコミットを実行しないでください。
• 計画への言及を避ける：コミット、ブランチ、PR で「Step 1.2」や「Phase 3」などに決して言及しないでください。
• 問題がないか確認：.env ファイル、本番環境の console.log、改行の欠落がないかを指摘します。

---

やってはいけないこと

❌ コミット前チェックを実行せずにコミットすることは絶対に禁止です — 作業を止めて、まず pre-commit-check を実行してください。 ❌ 開発者から実行を明示的に依頼されない限り、ステージング、コミット、プッシュを行わないでください。デフォルトでは計画を提示し、承認を待ちます。 ❌ 依頼されていないファイルを変更しないでください。 ❌ 変更内容を推測しないでください。必ず実際の差分を分析してください。

---

継続的な改善

このスキルで防止できたはずの動作について開発者から指摘を受けた場合、今後同じ指摘が繰り返されないよう、このスキルに加える具体的な修正を提案してください。