smart-commit

スマートコミット

トリガー

「コミット」「変更を保存」と言ったとき、または変更後にコミットする準備ができたときに使用します。

ワークフロー

1. 現在の状態を確認し、コミットする内容を特定します。
2. 品質チェック（影響を受けるファイルの lint、typecheck、テスト）を実行します。
3. ステージされた変更をスキャンして問題がないか確認します。
4. 差分から Conventional Commits 形式のコミットメッセージを作成します。
5. 特定のファイルをステージし、コミットを作成します。
6. この変更から得られた学びを尋ねます。

コマンド

git status
git diff --stat

npm run lint 2>&1 | tail -5
npm run typecheck 2>&1 | tail -5
npm test -- --changed --passWithNoTests 2>&1 | tail -10

git add <specific files>
git commit -m "<type>(<scope>): <summary>"

コードレビュースキャン

コミットする前に、ステージされた変更のうち本番コード（テストファイルを除く）を確認し、以下をチェックします。

• console.log / debugger ステートメント（テストファイルでは抑制されます。レビュー時の抑制事項を参照）
• チケット参照のない TODO/FIXME/HACK コメント（例：TODO(JIRA-123) は問題ありません）
• ハードコードされたシークレットや API キー
• 残されたテスト専用コード

問題があれば、作業を進める前に報告します。

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

<type>(<scope>): <short summary>

<body - what changed and why>

タイプ： feat、fix、refactor、test、docs、chore、perf、ci、style

ガードレール

• ユーザーから明示的に指示されない限り、品質チェックを省略しません。
• ファイル名を指定してステージします。git add -A や git add . は決して使用しません。
• 要約は72文字未満にします。本文では「何を」ではなく「なぜ」を説明します。
• 汎用的なメッセージ（「バグを修正」「コードを更新」など）は使いません。
• 該当する場合は、課題番号を記載します。

出力

• 品質チェックの結果（合格／不合格）
• ステージされた変更で見つかった問題
• 提案するコミットメッセージ
• コミット後のコミットハッシュ
• 確認：記録しておくべき学びはありますか？

レビュー時の抑制事項

コミット前スキャンでは、以下を報告しないでください。実際のバグを見つけることなくノイズを増やすためです。

• しきい値、設定値、機能フラグの変更（上限、タイムアウト、再試行回数）
• 実行時の動作を変更しないインポート順の変更
• 空白のみ、またはフォーマットのみの変更
• テストファイルでの console.log の追加または削除
• TODO/FIXME コメント（課題管理システムで別途追跡されます）
• 動作を変更しない変数名やパラメーター名の変更