166 lines
7.6 KiB
Markdown
166 lines
7.6 KiB
Markdown
---
|
||
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
|