---
name: github-commit-message
description: GitHubのコミットメッセージを生成し、ユーザー承認を経てコミットする。コードの修正・実装が完了した際、またはコミットメッセージの作成・コミット実行を求められた際に起動する。
---

# GitHubコミットメッセージ生成

変更内容を分析し、プロジェクトのフォーマットに従ったコミットメッセージ案を生成する。ユーザーの承認を得てからコミットを実行する。

## 主要な概念

- **コミットメッセージフォーマット**: `[機能名] XXXXXX #{ticket_no}` の形式で、なぜその実装・修正が必要だったかを伝える
- **承認ファースト**: ユーザーの承認なしに `git commit` を実行してはならない
- **チケット番号**: ブランチ名から自動的に抽出する。取得できない場合はユーザーに確認する

## 使用タイミング

以下の場合に起動する:

- コードの修正・実装が完了した直後（「コミットして」「コミットメッセージを作って」など）
- git commit に関する操作を求められた場合
- 変更内容のサマリーとコミットメッセージの提案を求められた場合

## 使い方

### ステップ1: 変更内容の収集

以下のコマンドを並列で実行し、現在の変更状況を把握する:

- `git status` — ステージング状況と未追跡ファイルを確認する
- `git diff` — 未ステージの変更内容を確認する
- `git diff --staged` — ステージ済みの変更内容を確認する
- `git log -5 --oneline` — 直近のコミット履歴とメッセージスタイルを確認する
- `git branch --show-current` — 現在のブランチ名を取得する

### ステップ2: チケット番号の抽出

ブランチ名からチケット番号を抽出する:

- `feature/123-login-improvement` → `#123`
- `bugfix/456-validation-error` → `#456`
- `refactor/789-code-cleanup` → `#789`

ブランチ名にチケット番号が含まれない場合、または抽出できない場合は、ユーザーに確認する。

### ステップ3: コミットメッセージ案の生成

以下のフォーマットでコミットメッセージを生成する:

```
[機能名] XXXXXX #{ticket_no}
```

**`[機能名]`** の記述ルール:
- 変更の分類または画面名を日本語で記述する
- 例: `[認証]`, `[プロジェクト管理]`, `[ダッシュボード]`, `[バグ修正]`, `[リファクタリング]`, `[バックエンド]`, `[テスト]`, `[パフォーマンス]`
- 画面に関する変更の場合は具体的な画面名を使用する（例: `[ログイン画面]`, `[ホーム画面]`）

**`XXXXXX`** の記述ルール:
- 「〜のため〜を実装」の構成で簡潔に記述する（日本語）
- 理由（〜のため）と実装内容（〜を実装/〜を修正）を1行でまとめる
- コードから読み取れない背景・意図をこれまでの会話や仕様から補足する

**コミットメッセージ例:**
- `[認証] ログイン時のセッション管理を強化するためJWT検証ロジックを実装 #123`
- `[バグ修正] 日付バリデーションエラーを解消するため入力チェックロジックを修正 #456`
- `[プロジェクト管理] ダッシュボードの視認性を向上させるためレイアウトを改善 #789`
- `[リファクタリング] コードの保守性を高めるためバリデーションロジックを共通化 #101`

### ステップ4: ユーザーへの提示と承認

以下の3点をセットで提示する:

```
## Summary
- 影響ファイル/機能（変更されたファイルと対象機能）
- 実装理由（なぜこの変更が必要だったか）
- テスト状況（テスト済み・未テストなど）

## Commit Message Proposal
[機能名] XXXXXX #{ticket_no}

## Need Approval
上記のメッセージでコミットしてよいですか？
修正が必要な場合は内容をお知らせください。
```

**承認プロセスのルール:**
- ユーザーの承認が得られるまで `git commit` を実行してはならない
- ユーザーから修正指示があった場合は、指示を反映して再提案し、再度承認を得る
- 承認されたら、提示したメッセージをそのまま使用してコミットを実行する
- コミット実行後であっても、ユーザー指示があるまで `git push` は実行してはならない

### ステップ5: コミットの実行

承認を得たら以下を実行する:

```bash
git add .
git commit -m "$(cat <<'EOF'
[機能名] XXXXXX #{ticket_no}
EOF
)"
```

コミット完了後、結果（コミットハッシュ・メッセージ）をユーザーに報告する。

## エラー対応

| 状況 | 対応 |
|------|------|
| `git commit` が失敗した場合 | エラー内容をユーザーに報告し、対応方法を提案する |
| ステージングされていないファイルがある場合 | ステージング状況を確認・報告し、対象ファイルをユーザーに確認する |
| コンフリクトがある場合 | 問題の詳細と解決方法を提示する |
| pre-commit hookが失敗した場合 | hookのエラー内容を報告し、修正方法を提案する。修正後に新しいコミットを作成する（amendは使用しない） |

## セキュリティチェック

コミット前に以下を確認する:

- [ ] APIキー・パスワード・トークンなどのシークレットがコードに含まれていない
- [ ] `.env` ファイルや認証情報ファイルがステージングされていない
- [ ] 機密情報を含むファイルが誤って追加されていない

シークレットが検出された場合はコミットを中断し、ユーザーに警告する。

## ベストプラクティス

- **背景を補足する**: コードから読み取れない「なぜ」を会話の文脈から推測して記述する
- **1コミット1目的**: 複数の変更がある場合は目的ごとに分割することを提案する
- **日本語で統一**: コミットメッセージは日本語で記述する
- **承認を省略しない**: どんな状況でもユーザー承認なしにコミットを実行しない