human-commit

Human Commit

Git の変更を読み取り、実際の開発者が書いたようなコミットメッセージを生成します。

ワークフロー

ステップ 1 — 差分を読む

git diff --cached 2>/dev/null

出力が空（ステージされた変更がない）の場合は、次のコマンドに切り替えます。

git diff HEAD 2>/dev/null

関連するファイルも確認します。

git status --short 2>/dev/null

差分が約 500 行を超える場合は、そのまま分析しようとしないでください。まず、変更量の多いファイルを特定します。

git diff --cached --stat 2>/dev/null || git diff HEAD --stat 2>/dev/null

次に、すべての行ではなく、変更量の多いファイルと全体的なテーマに焦点を当てて分析します。

ステップ 1b — リポジトリのコミットスタイルを検出する

git log --oneline -5 2>/dev/null

直近 5 件のコミットを確認します。大半が Conventional Commits 形式（type(scope): subject または type: subject）に従っている場合、リポジトリでは CC を使用しています。小文字の平文の文が使われている場合は、平文スタイルに合わせます。既存のスタイルに合わせ、新しいスタイルを持ち込まないでください。

ステップ 2 — 変更を分析する

次の項目を特定します。

• 変更されたファイルとその領域（認証、UI、依存関係、設定、テストなど）
• 変更の内容（修正、追加、削除、移動、更新、リファクタリング）
• 明確な「理由」があるか（バグ、整理、新機能、メンテナンス）
• スコープ（モノレポの場合）：変更されたファイルが packages/、apps/、または名前付きワークスペース配下にある場合は、ディレクトリ名からスコープを推測します（例：packages/auth/ → スコープ auth）
• 破壊的変更：エクスポートされた関数の削除、公開インターフェースの名前変更、関数シグネチャの変更、メジャーバージョンの更新がある場合は、それを示してください。メッセージに BREAKING CHANGE フッターが必要になる場合があります。

ステップ 3 — 3 つの候補を生成する

コミットメッセージの候補をちょうど 3 つ出力します。それぞれをコードブロック内の別々の行に記載します。

スタイルのルール（ステップ 1b で検出したリポジトリのスタイルに合わせます）：

リポジトリが Conventional Commits を使用している場合（ステップ 1b で検出）：

• type(scope): subject 形式を使用します。fix、feat、refactor、chore、docs、test、build
• スコープは省略可能です。変更されたファイルから明確なスコープが推測できる場合は含めます。
• サブジェクトは小文字、命令形で、72 文字以内にします。
• 破壊的変更が検出された場合は、空行に続けて BREAKING CHANGE: <変更内容> を追加します。

リポジトリが 平文スタイル を使用している場合（または明確なパターンがない場合）：

• サブジェクト行は 小文字 にします。
• サブジェクトは約 50 文字 にします（72 文字までは問題ありません）。
• Conventional Commits の接頭辞は使いません。fix: resolve token expiry ではなく fix tokens not expiring とします。
• 命令形にします。fixed X や fixes X ではなく fix X とします。

どちらのスタイルでも：

• 明らかな冗長表現は避けます。update code to fix the issue with the login のようにはしません。
• 本文は任意です。変更の説明が本当に必要な場合に限り、空行に続けて 1～2 行を追加します（各行 72 文字以内）。

避けるべきアンチパターン：

• ❌ implement JWT token validation middleware with expiry checking
• ❌ refactor: extract authentication logic into separate service module
• ❌ fix: resolve issue with user authentication token expiration handling
• ✅ fix tokens not expiring
• ✅ move auth to its own file
• ✅ bump deps
• ✅ add dark mode toggle
• ✅ fix login redirect on mobile

出力形式

平文スタイル：

Option 1: fix tokens not expiring
Option 2: auth middleware wasn't checking expiry
Option 3: fix expired jwt tokens still passing through

Conventional Commits スタイル：

Option 1: fix(auth): tokens not expiring on check
Option 2: fix(auth): jwt expiry not validated
Option 3: fix: expired tokens still passing auth middleware

本文を含む場合（必要に応じて）：

Option 2: reorganize auth module

pulled jwt logic out, the file was getting too long

破壊的変更のフッターを含む場合：

Option 1: refactor(api): rename user endpoints

BREAKING CHANGE: /users/:id renamed to /users/:userId

最適な候補をオプション 1 に選びます。