pre-commit-check

コミット前チェック

これは厳格なガイドラインです。 次のルールを厳守してください。

コミットする前に、ステージされたファイルのみを対象に、3つのゲートで確認します。すべてのゲートに合格する必要があります。

---

ゲート 1：セキュリティ

security-checklist スキルに委任します。ステージされたファイルをスキャンして、以下がないか確認してください。

• ハードコードされたシークレット、API キー、トークン、パスワード
• 実際の値が含まれる .env ファイル
• 認証情報、秘密鍵、接続文字列

見つかった場合：停止してください。ゲート 2 に進んではいけません。

---

ゲート 2：コード品質

ステージされたファイルを core-principles および標準的なベストプラクティスに照らして確認します。

• DRY — この変更は、既存のロジックをほかの場所で重複させていませんか？コピー＆ペーストされたコードや、抽出すべき繰り返しパターンがないか確認してください。
• 純粋関数 — ヘルパー関数は純粋で、テスト可能ですか？副作用は分離されていますか？
• 迅速な失敗 — 暗黙のデフォルト値がありませんか？設定やデータが不足している場合は、フォールバックせずに例外をスローする必要があります。
• 命名 — 変数、関数、ファイルには分かりやすい名前が付いていますか？
• 関心の分離 — ビジネスロジックに I/O やプレゼンテーションの処理が混在していませんか？
• エラー処理 — エラーは適切なレベルで、対処に役立つ情報とともに処理されていますか？
• 不要なコード — 残された console.log、コメントアウトされたブロック、未使用のインポートはありませんか？

問題を報告してください。軽微なスタイル上の指摘は記載してもかまいませんが、コミットを妨げるべきではありません。

---

ゲート 3：問題が起きないか

コミット前に、**プッシュ後に何が壊れる可能性があり、ユニットテストでは検出できないか？**と確認してください。

ユニットテストは自動的に実行されます。このゲートでは、テストで見逃される問題、つまり実行環境の問題、権限不足、インフラの設定ミス、デプロイの失敗を確認します。

必ず確認してください：

• コードはビルドできますか？ビルドを実行してください。
• 既存のテストは成功しますか？テストを実行してください。
• リンターエラーはありませんか？リンターを実行してください。

インフラコード（Lambdas、CDK、SST）— プッシュ後の障害の多くはここで発生します：

• dev にデプロイして、Lambda を直接呼び出してください。
• CloudWatch を確認して、環境変数の不足、権限エラー、インポートの失敗がないか調べてください。
• 新しい SSM パラメーターやシークレットが、対象環境に実際に存在することを確認してください。
• Lambda はすべてのユニットテストに合格しても、呼び出し時に失敗する可能性があります。必ず呼び出してください。

フロントエンド：

• コンソールエラーなしでレンダリングされますか？
• ブラウザーでページを読み込めますか？

CI に依存する変更（ワークフロー、ビルド設定）：

• 可能であれば、関連するステップをローカルで実行してください（ビルドコマンド、テストスイート、リンター）。

ルール： 検証にかかる時間が 2 分未満なら、今すぐ実施してください。プッシュして、CI が検出してくれることを期待してはいけません。

---

出力

検出事項を報告する際は、次の形式を使用してください。

🔴 Blocked — [reason, e.g. "hardcoded API key in config.ts"]
🟡 Fix before commit — [code quality issue with file reference]
✅ Verified — [what was tested, e.g. "build passes, Lambda invoked successfully"]

---

継続的な改善

開発者がこのスキルで防ぐべきだった動作を修正した場合、今後同じ修正が必要にならないよう、このスキルへの具体的な追記を提案してください。