Initial commit

commands/self-review.md

@@ -0,0 +1,147 @@
+# 作成した成果物に対して厳格なセルフレビューを実施します
+
+作成したばかりの成果物を見直して、良い点と問題点を洗い出してください。
+
+**重要**: 「この程度なら良いだろう」という甘えは一切許しません。厳格に自己反省を繰り返しながらセルフレビューを実施してください。
+
+$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文字以上の自己反省文を記述