コミット前にコードの品質をレビューしてください。

手順

Step 1: 差分の取得

•git diff と git diff --cached で未コミットの変更を確認
•変更がない場合はその旨を伝えて終了
•差分が大きい場合（10ファイル以上）はファイル単位で確認する

Step 2: アーキテクチャ・責務の分離

CLAUDE.md のアーキテクチャルールに基づき、以下を検査する：

•依存関係ルール違反: domain/ や usecase/ から adapters/ や transport/ をインポートしていないか
•レイヤー責務の混在: ビジネスロジックが handler に書かれていないか、HTTP固有の処理が usecase に入っていないか
•リポジトリインターフェースの配置: インターフェースが usecase 層で定義されているか（domain/repository/ に配置していないか）
•DTO とエンティティの混同: transport 層の DTO を usecase やドメイン層で使っていないか

Step 3: 命名規則

Go の命名慣例とプロジェクト固有のルールを検査する：

•パッケージ名: 小文字、短く、単数形（例: handler, entity, usecase）
•エクスポート名: MixedCaps（例: GetCandles, CandleRepository）
•非エクスポート名: mixedCaps（例: findBySymbol, cacheTTL）
•インターフェース名: -er 接尾辞の慣例（例: Reader, Writer）。ただしリポジトリは XxxRepository で可
•レシーバ名: 1-2文字の短い名前（例: c, cr）、self や this は不可
•定数: 意味のある名前（マジックナンバーの回避）
•ファイル名: snake_case（例: candle_repository.go, candle_handler_test.go）
•テストヘルパー名: setup, newTestXxx 等のプロジェクト慣例に従っているか

Step 4: コード品質

以下の観点で品質を検査する：

•エラーハンドリング: エラーを無視（_ に代入）していないか、適切にラップしているか
•不要な公開: エクスポートする必要のない関数や型が公開されていないか
•コードの重複: 同じ処理が複数箇所に書かれていないか
•関数の長さ: 1つの関数が長すぎないか（目安: 50行以上は要検討）
•引数の数: 引数が多すぎないか（目安: 5個以上は構造体の導入を検討）
•nil チェック: ポインタやスライスの nil チェックが適切か
•コンテキスト伝播: context.Context が適切に渡されているか

Step 5: テスト品質（テストファイルが含まれる場合）

•テーブル駆動テスト: 複数ケースがある場合、テーブル駆動テストを使っているか
•テストケースの網羅性: 正常系・異常系・境界値がカバーされているか
•モックの適切さ: インターフェースに対するモックが適切に使われているか
•テスト名: 日本語または TestXxx_MethodName_Scenario 形式で意図が明確か

Step 6: レビュー結果の出力

以下のフォーマットで結果を出力する。問題がない場合もその旨を明記する：

text

## レビュー結果

対象: <N>ファイル (+<追加行数>, -<削除行数>)

### 問題点（要修正）
問題がある場合、ファイル名と行番号を添えて具体的に指摘する。

### 改善提案（任意）
必須ではないが、コード品質向上のための提案があれば記載する。

### 良い点
良いコードがあれば積極的に言及する。

注意事項

•レビューは日本語で行う
•指摘には必ずファイル名と該当箇所を含める
•修正案がある場合は具体的なコード例を示す
•過度に細かい指摘（スタイルの好みレベル）は避け、実質的な品質改善に焦点を当てる
•このスキルはコードの変更は行わない（レビューのみ）