commit

Claude コマンド：Commit

あなたの役割は、Conventional Commits 形式のメッセージと絵文字を使って、適切に整形されたコミットを作成することです。

手順

重要：以下の手順を記載どおりに正確に実行してください。

1. ブランチの確認：現在のブランチが master または main かどうかを確認します。その場合は、コミットする前に別のブランチを作成するかユーザーに尋ねます。ユーザーが新しいブランチの作成を承認した場合は、<type>/<username>/<description> の形式で作成します（例：feature/leovs09/add-new-command）
2. --no-verify が指定されていない限り、プロジェクトの言語に応じて pnpm lint などのコミット前チェックを自動的に実行します。
3. git status でステージされているファイルを確認します。
4. ステージされているファイルが 0 件の場合、変更されたファイルと新規ファイルをすべて git add で自動的に追加します。
5. git diff を実行して、コミットする変更内容を把握します。
6. 差分を分析し、異なる論理的変更が複数含まれているかどうかを判断します。
7. 異なる変更が複数検出された場合は、コミットを複数の小さなコミットに分割することを提案します。
8. 各コミット（分割しない場合は単一のコミット）について、絵文字を使った Conventional Commits 形式でコミットメッセージを作成します。

コミットのベストプラクティス

• コミット前に確認する：コードのリントが実行され、正しくビルドでき、ドキュメントが更新されていることを確認します
• アトミックなコミット：各コミットには、単一の目的に沿った関連する変更を含めます
• 大きな変更は分割する：変更が複数の関心事にまたがる場合は、別々のコミットに分割します
• Conventional Commits 形式：<type>: <description> の形式を使用します。type は次のいずれかです：
  • feat：新機能
  • fix：バグ修正
  • docs：ドキュメントの変更
  • style：コードスタイルの変更（フォーマットなど）
  • refactor：バグ修正や機能追加を伴わないコードの変更
  • perf：パフォーマンスの改善
  • test：テストの追加または修正
  • chore：ビルドプロセスやツールなどの変更
• 現在形、命令形を使う：コミットメッセージはコマンドとして記述します（例：「added feature」ではなく「add feature」）
• 1 行目は簡潔にする：1 行目は 72 文字未満にします
• 絵文字：各コミットタイプには、適切な絵文字が対応しています：
  • ✨ feat：新機能
  • 🐛 fix：バグ修正
  • 📝 docs：ドキュメント
  • 💄 style：フォーマット／スタイル
  • ♻️ refactor：コードのリファクタリング
  • ⚡️ perf：パフォーマンスの改善
  • ✅ test：テスト
  • 🔧 chore：ツール、設定
  • 🚀 ci：CI/CD の改善
  • 🗑️ revert：変更の取り消し
  • 🧪 test：失敗するテストを追加
  • 🚨 fix：コンパイラー／リンターの警告を修正
  • 🔒️ fix：セキュリティ上の問題を修正
  • 👥 chore：コントリビューターを追加または更新
  • 🚚 refactor：リソースを移動または名前変更
  • 🏗️ refactor：アーキテクチャ上の変更を実施
  • 🔀 chore：ブランチをマージ
  • 📦️ chore：コンパイル済みファイルまたはパッケージを追加または更新
  • ➕ chore：依存関係を追加
  • ➖ chore：依存関係を削除
  • 🌱 chore：シードファイルを追加または更新
  • 🧑‍💻 chore：開発者エクスペリエンスを改善
  • 🧵 feat：マルチスレッドまたは並行処理に関するコードを追加または更新
  • 🔍️ feat：SEO を改善
  • 🏷️ feat：型を追加または更新
  • 💬 feat：テキストやリテラルを追加または更新
  • 🌐 feat：国際化とローカライズ
  • 👔 feat：ビジネスロジックを追加または更新
  • 📱 feat：レスポンシブデザインに取り組む
  • 🚸 feat：ユーザーエクスペリエンス／ユーザビリティを改善
  • 🩹 fix：重大ではない問題を簡単に修正
  • 🥅 fix：エラーを捕捉
  • 👽️ fix：外部 API の変更に合わせてコードを更新
  • 🔥 fix：コードまたはファイルを削除
  • 🎨 style：コードの構造／形式を改善
  • 🚑️ fix：重大なホットフィックス
  • 🎉 chore：プロジェクトを開始
  • 🔖 chore：リリース／バージョンタグ
  • 🚧 wip：作業中
  • 💚 fix：CI のビルドを修正
  • 📌 chore：依存関係を特定のバージョンに固定
  • 👷 ci：CI ビルドシステムを追加または更新
  • 📈 feat：分析またはトラッキングコードを追加または更新
  • ✏️ fix：誤字を修正
  • ⏪️ revert：変更を取り消す
  • 📄 chore：ライセンスを追加または更新
  • 💥 feat：破壊的変更を導入
  • 🍱 assets：アセットを追加または更新
  • ♿️ feat：アクセシビリティを改善
  • 💡 docs：ソースコード内のコメントを追加または更新
  • 🗃️ db：データベース関連の変更を実施
  • 🔊 feat：ログを追加または更新
  • 🔇 fix：ログを削除
  • 🤡 test：モックを作成
  • 🥚 feat：イースターエッグを追加または更新
  • 🙈 chore：.gitignore ファイルを追加または更新
  • 📸 test：スナップショットを追加または更新
  • ⚗️ experiment：実験を実施
  • 🚩 feat：機能フラグを追加、更新、または削除
  • 💫 ui：アニメーションとトランジションを追加または更新
  • ⚰️ refactor：不要なコードを削除
  • 🦺 feat：検証に関するコードを追加または更新
  • ✈️ feat：オフライン対応を改善

コミットを分割する際のガイドライン

差分を分析する際は、次の基準に基づいてコミットの分割を検討してください。

1. 関心事の違い：コードベースの無関係な部分に対する変更
2. 変更の種類の違い：機能追加、修正、リファクタリングなどの混在
3. ファイルのパターン：異なる種類のファイルに対する変更（例：ソースコードとドキュメント）
4. 論理的なグループ分け：個別に確認またはレビューしやすくなる変更
5. 規模：分割すると内容がより明確になる大規模な変更

例

良いコミットメッセージ：

• ✨ feat: ユーザー認証システムを追加
• 🐛 fix: レンダリングプロセスのメモリーリークを修正
• 📝 docs: 新しいエンドポイントを含む API ドキュメントを更新
• ♻️ refactor: パーサーのエラー処理ロジックを簡素化
• 🚨 fix: コンポーネントファイルのリンター警告を解消
• 🧑‍💻 chore: 開発者ツールのセットアッププロセスを改善
• 👔 feat: トランザクション検証のビジネスロジックを実装
• 🩹 fix: ヘッダーの軽微なスタイルの不整合を修正
• 🚑️ fix: 認証フローの重大なセキュリティ脆弱性にパッチを適用
• 🎨 style: 可読性を高めるためにコンポーネント構造を再編成
• 🔥 fix: 非推奨のレガシーコードを削除
• 🦺 feat: ユーザー登録フォームに入力検証を追加
• 💚 fix: 失敗している CI パイプラインテストを修正
• 📈 feat: ユーザーエンゲージメントの分析トラッキングを実装
• 🔒️ fix: 認証パスワードの要件を強化
• ♿️ feat: スクリーンリーダー向けにフォームのアクセシビリティを改善

コミットを分割する例：

• 1 つ目のコミット：✨ feat: 新しい solc バージョンの型定義を追加
• 2 つ目のコミット：📝 docs: 新しい solc バージョンのドキュメントを更新
• 3 つ目のコミット：🔧 chore: package.json の依存関係を更新
• 4 つ目のコミット：🏷️ feat: 新しい API エンドポイントの型定義を追加
• 5 つ目のコミット：🧵 feat: ワーカースレッドの並行処理を改善
• 6 つ目のコミット：🚨 fix: 新しいコードのリンティング問題を修正
• 7 つ目のコミット：✅ test: 新しい solc バージョン機能のユニットテストを追加
• 8 つ目のコミット：🔒️ fix: セキュリティ脆弱性のある依存関係を更新

コマンドオプション

• --no-verify：コミット前チェック（lint、build、generate:docs）をスキップします

ブランチ命名規則

master または main でコミットする際、コマンドは新しいブランチを作成するかどうかを尋ねます。作成する場合は、次のパターンに従ってブランチを作成します。

<type>/<git-username>/<description>

構成要素：

• <type>：コミットの種類（feature、fix、docs、refactor、perf、test、chore など）
• <git-username>：Git ユーザー名（git config user.name またはシステムのユーザー名から取得）
• <description>：変更内容を表す kebab-case の説明（例：add-user-auth、fix-login-bug）

例：

• feature/leovs09/add-new-command
• fix/johndoe/resolve-memory-leak
• docs/alice/update-api-docs
• refactor/bob/simplify-error-handling
• chore/charlie/update-dependencies

ワークフロー：

1. コマンドが現在 master または main にいることを検出します
2. 次のように尋ねます：「メインブランチにいます。別のブランチを作成しますか？」
3. 「いいえ」の場合：現在のブランチでコミットを続行します
4. 「はい」の場合：変更を分析して種類を判断し、簡単な説明を尋ねてからブランチを作成し、コミットを続行します

重要な注意事項

• デフォルトでは、コード品質を確保するためにコミット前チェック（pnpm lint、pnpm build、pnpm generate:docs）が実行されます
• これらのチェックに失敗した場合は、そのままコミットするか、先に問題を修正するかを尋ねられます
• 特定のファイルがすでにステージングされている場合、コマンドはそのファイルのみをコミットします
• ファイルがステージングされていない場合、変更されたファイルと新規ファイルがすべて自動的にステージングされます
• 検出された変更に基づいてコミットメッセージが作成されます
• コミット前に、複数のコミットに分けるのが適切かどうかを判断するため、差分がレビューされます
• 複数のコミットが提案された場合、変更を分けてステージングし、コミットする作業を支援します
• コミットメッセージが変更内容に合っていることを確認するため、コミット差分が必ずレビューされます