# 作成した成果物に対して厳格なセルフレビューを実施します

作成したばかりの成果物を見直して、良い点と問題点を洗い出してください。

**重要**: 「この程度なら良いだろう」という甘えは一切許しません。厳格に自己反省を繰り返しながらセルフレビューを実施してください。

$ARGUMENTS

## 実施手順

### 1. レビュー対象の特定

**AskUserQuestionツール**でレビューモードを質問：
- question: 「どのモードでレビューしますか？」
- header: 「レビューモード」
- デフォルト: 変更差分モード

選択肢：
- 「変更差分モード（デフォルト）」: `git diff`と`git diff --staged`で変更されたファイルを対象
- 「ファイル指定モード」: 引数で指定されたファイルパスを対象

**変更差分モードの場合**:
1. `git diff --name-only`と`git diff --staged --name-only`で変更ファイルを取得
2. 変更されたファイルをすべて対象とする

**ファイル指定モードの場合**:
1. 引数で指定されたファイルパスを対象とする
2. 引数がない場合は、**AskUserQuestionツール**でファイルを選択させる（最大4つ）

### 2. レビューの実施

#### 良い点の洗い出し
客観的に優れている点を具体的に列挙：
- 設計・アーキテクチャ（単一責任、適切な抽象化、既存パターンとの整合性）
- 実装品質（可読性、命名、関数型スタイル、エラーハンドリング）
- 型安全性（`any`型の不使用、適切な型定義）
- テスト（主要ケースのカバー）
- ドキュメント（必要なコメント）

#### 問題点の洗い出し（厳格に）
些細な問題も見逃さず指摘：

**重大な問題（即座に修正が必要）**:
- `any`型の使用（絶対禁止）
- 場当たり的な対応（「一時的」「とりあえず」「一旦」「ひとまず」「可能性」という表現）
- 過剰な抽象化（不要なインターフェースや抽象クラス）
- 循環依存、密結合な設計

**改善が望ましい点**:
- 重複コード（既存実装の未確認）
- 既存ライブラリの未活用
- 命令型の配列操作（`array.push()`など、map/filterで書けないか）
- 不必要な`interface`の使用（基本的に`type`を使用）
- barrel import/export
- マジックナンバー/文字列

**軽微な改善点**:
- 命名規約、コメント、パフォーマンス、セキュリティなど

**問題の優先度判断基準**:
- **重大**: システムの安定性・保守性に直接影響、技術的負債となる（any型、場当たり的対応、設計上の欠陥）
- **改善**: コード品質に影響、将来的に問題となる可能性（重複、未活用、非効率な実装）
- **軽微**: 一貫性・可読性に影響、すぐに問題とはならない（命名、コメント）

### 3. レビュー結果の報告

```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 セルフレビュー結果
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

対象: {ファイルパス}
総合評価: {✅ 高品質 / ⚠️ 改善の余地あり / ❌ 重大な問題あり}

## 良い点 ✅
- {具体的な良い点}

## 問題点 ⚠️❌

### 重大（{件数}件）
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）

### 改善（{件数}件）
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）

### 軽微（{件数}件）
1. **{カテゴリ}**: {説明}（場所: {パス}:{行}）

## 自己反省 🔥
{場当たり的な対応があれば50文字以上で反省}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

### 4. 各問題について個別のAskUserQuestionを作成してまとめて質問

見つかった問題について、**各問題ごとに個別のAskUserQuestion**を用意し、**1つのメッセージでまとめて質問**してください。

**AskUserQuestionツールの制約**: 1回のツール呼び出しで最大4問まで

**手順**:
1. 見つかった全問題（重大 → 改善 → 軽微の順）をリストアップ
2. 各問題について、具体的な修正方法の対応方針案を考える
3. 問題を最大4問ずつのグループに分割
4. 各グループについて、1つのメッセージでAskUserQuestionツールを実行

**各質問の形式**:
- question: 「{問題の説明}（場所: {パス}:{行}）この問題にどう対応しますか？」
- header: 「{問題カテゴリ}」（例: "any型使用", "重複コード"）
- multiSelect: false

**選択肢の作り方**:
各選択肢の`label`に具体的な対応方針案を書く。必ず「対応しない」選択肢も含める。

例（any型使用の問題の場合）:
- label: "型推論を使用して置き換える"
  description: "any型を削除し、TypeScriptの型推論に任せる"
- label: "明示的な型定義を追加する"
  description: "適切な型を定義してany型を置き換える"
- label: "unknown型に置き換えて型ガードを追加"
  description: "any型をunknown型に変更し、型ガードで安全性を確保"
- label: "対応しない"
  description: "この問題は許容範囲として対応しない"

例（重複コードの問題の場合）:
- label: "共通関数として抽出する"
  description: "重複部分をユーティリティ関数として抽出"
- label: "高階関数でパターンを抽象化する"
  description: "共通パターンを高階関数として実装"
- label: "対応しない"
  description: "この程度の重複は許容範囲として対応しない"

**重要**:
- labelは必ず具体的な修正方法にすること
- 複数の対応方針案を提示し、ユーザーに選ばせる

### 5. Todoタスクの作成

ユーザーが対応方針を選択したら、**TodoWriteツール**で修正タスクを作成：
- content: 「{選択された対応方針}」（例: 「型推論を使用してany型を置き換える」）
- activeForm: 「{選択された対応方針}中」（例: 「型推論を使用してany型を置き換え中」）
- status: "pending"
- 優先度順（重大 → 改善 → 軽微）に並べる

## 重要な注意事項

- **絶対に甘えを許さない**: 「この程度なら良いだろう」は禁止
- **場当たり的な対応の検出**: 「一時的」「とりあえず」「一旦」「ひとまず」「可能性」が見つかったら50文字以上の自己反省文を記述