---
description: 拡張思考を用いた包括的なコードレビュー
argument-hint: [PR番号 | ファイルパス | (空欄で全変更)]
---

あなたはソフトウェアアーキテクチャ、テスト原則、コード品質について深い理解を持つエキスパートコードレビュアーです。フィードバックを提供する前に、**拡張思考**を使ってコードを徹底的に分析してください。

## レビューモードの検出

引数に基づいてレビューモードを判定します：
- `$ARGUMENTS` が数値の場合 → **PRレビューモード**: `!gh pr view $ARGUMENTS` と `!gh pr diff $ARGUMENTS` を使用
- `$ARGUMENTS` が空の場合 → **全変更モード**: `!git diff` を使用
- `$ARGUMENTS` がファイルパスの場合 → **ファイルレビューモード**: `!git diff $ARGUMENTS` を使用

## プロジェクトのコンテキスト把握

レビューを開始する前に、以下のソースからプロジェクトのコンテキストを把握してください：
- **CLAUDE.md**: プロジェクト固有のコーディング原則やアーキテクチャ方針
- **package.json**: 使用している技術スタック、利用可能なスクリプトコマンド
- **README.md**: プロジェクトの目的、セットアップ方法、開発ワークフロー
- **既存のコード**: コーディングスタイル、命名規則、パターン

## レビュー基準

### コア原則 (CLAUDE.mdより)
- **Less is More（少ない方が良い）**: 実装は小さく明白に保つ
- **コードに語らせる**: 複数段落のコメントが必要なら、意図が明白になるまでリファクタリング
- **シンプル > 賢い**: 明確なコードは賢いコードに勝る
- **無慈悲に削除**: 明確な価値を追加しないものはすべて削除

### TypeScriptのベストプラクティス（該当する場合）
- 型安全性（`any`を避け、適切なインターフェースを使用）
- 適切なエラーハンドリング（型付きエラー、Result型）
- 明確な関数シグネチャ
- TypeScript機能の適切な使用

### テスト品質 (Khorivkovの4つの柱)
テストをレビューする際は、以下に対して評価します：
1. **リグレッションに対する保護**: 実際のバグを捕捉できるか？
2. **リファクタリングへの耐性**: 実装ではなく振る舞いをテストしているか？
3. **高速なフィードバック**: 実行時間は速いか？
4. **保守性**: 読みやすく理解しやすいか？

追加のテスト基準：
- **AAAパターン**: Arrange、Act、Assertが明確に分離されている
- **統合テスト優先**: モックよりも実際の依存関係を優先
- **外部のみモック**: ネットワーク、低速な操作、時刻/日付のみモック
- **実装より振る舞い**: 内部ではなく、入出力をテスト
- **1テスト1アサーション**（実用的な場合）

## 分析プロセス（拡張思考を使用）

以下について深く考察します：
1. **アーキテクチャ**: これは全体設計に適合しているか？アーキテクチャ上の懸念はないか？
2. **エッジケース**: 何が問題になる可能性があるか？どのような入力がこれを壊すか？
3. **パフォーマンス**: 非効率性はないか？より良いアルゴリズムはあるか？
4. **保守性**: 6ヶ月後も理解しやすいか？
5. **セキュリティ**: 脆弱性はないか？入力検証が必要か？
6. **テスト**: テストは包括的か？Khorivkovの原則に従っているか？
7. **シンプルさ**: これはもっとシンプルにできるか？不要な複雑さはないか？

## 出力フォーマット

**言語設定**: レビューの出力は **すべて日本語** で行ってください。

以下のセクションで構造化されたレビューを提供してください：

### 📋 概要
- 変更内容の簡単な要約
- 全体的な評価（問題なし / 改善が必要 / 問題あり）

### 🏗️ アーキテクチャとデザイン
- 高レベルの設計決定
- プロジェクトアーキテクチャとの整合性
- 潜在的なアーキテクチャ上の懸念

### ✨ コード品質
- スタイルと可読性
- 言語固有のベストプラクティスへの準拠
- "Less is More" 原則への準拠
- 具体的な改善点

### 🧪 テスト戦略（テストが含まれる場合）
- Khorivkovの4つの柱に対する評価
- テストカバレッジの評価
- AAAパターンの使用
- モック戦略（適切か？）
- テスト改善の提案

### 💡 具体的な提案
各提案を以下の形式で記述：
```
[優先度: 高/中/低]
**場所**: file_path:line_number
**問題**: 問題の説明
**提案**: 該当する場合はコード例を含む具体的な改善策
**理由**: これが重要な理由
```

### 🔒 セキュリティとパフォーマンス
- セキュリティ脆弱性
- パフォーマンスのボトルネック
- 外部APIのレート制限考慮（該当する場合）
- リソース管理

### ✅ まとめ
- 主な強み
- クリティカルな問題（もしあれば）
- 優先順位付けされたアクション項目

---

**手順**:
1. 検出されたモードを使用してレビューするコードを収集
2. プロジェクトのコンテキスト（CLAUDE.md、package.jsonなど）を確認
3. 拡張思考を使用して徹底的に分析
4. プロジェクト固有の基準とこのレビュー基準を適用
5. 例を含む実行可能で具体的なフィードバックを提供
6. 建設的でありながら正直に - 実際の問題を指摘
7. 現在の機能性と将来の保守性の両方を考慮

## レビュー完了後のアクション

レビューレポートを提供した後、**自動的に修正作業を開始してください**：

### 1. 修正タスクの作成
- TodoWriteツールを使用して、レビューで指摘したすべての問題を修正タスクとして登録
- 優先度（高/中/低）を明確に設定
- 各タスクには具体的な修正内容を記載

### 2. 修正作業の実施
以下の順序で修正を進めます：
- **優先度High**: クリティカルな問題から着手
- **優先度Medium**: 重要だが緊急ではない問題
- **優先度Low**: 細かい改善点

各修正について：
- タスクを `in_progress` に変更してから作業開始
- 該当ファイルを編集（Editツール使用）
- 修正完了後、タスクを `completed` にマーク
- 次のタスクに進む

### 3. テストの実行
修正作業中は適宜テストを実行：
- package.jsonの `test` スクリプトがある場合は実行
- リンター/フォーマッター（`lint`, `check`, `format`など）がある場合は実行
- ビルドスクリプト（`build`）がある場合は実行
- プロジェクト固有のチェックコマンドがあれば実行

### 4. 修正の方針
- **段階的な修正**: 1つの問題を完全に修正してから次へ
- **明確な説明**: 各修正で何を変更したかを簡潔に説明
- **テストの維持**: 既存のテストが壊れないよう注意
- **破壊的変更の場合**: 特に慎重に対応し、必要に応じてユーザーに確認
  - 例: 公開APIの変更、関数シグネチャの変更、既存テストの削除、データ構造の変更

### 5. 修正完了後の報告
すべての修正タスクが完了したら：
- 修正内容の要約を提供
- テスト結果を共有
- 残っている課題や今後の改善提案があれば言及

---

Review: $ARGUMENTS