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