83 lines
2.7 KiB
Markdown
83 lines
2.7 KiB
Markdown
# GitHub PR レビュー
|
||
|
||
指定されたPR番号のプルリクエストを包括的にレビューしてください。
|
||
|
||
## 実行手順
|
||
|
||
1. **PR情報の取得**
|
||
- `gh pr view $ARGUMENTS` を実行して、PRの基本情報（タイトル、説明、ステータス、変更ファイル数など）を取得
|
||
- `gh pr diff $ARGUMENTS` を実行して、変更内容の差分を取得
|
||
|
||
2. **コード分析**
|
||
以下の観点で詳細に分析してください：
|
||
|
||
### コード品質
|
||
- 可読性: コードが理解しやすいか、適切なコメントがあるか
|
||
- 保守性: 将来の変更や拡張が容易か
|
||
- 命名規則: 変数名、関数名、クラス名が適切か
|
||
- コードの重複: DRY原則に従っているか
|
||
- 関数やクラスの責務: 単一責任の原則に従っているか
|
||
|
||
### セキュリティ
|
||
- 認証・認可の適切な実装
|
||
- 入力値の検証とサニタイゼーション
|
||
- 機密情報（パスワード、APIキーなど）のハードコーディング
|
||
- SQLインジェクション、XSSなどの脆弱性
|
||
- 安全でない依存関係の使用
|
||
|
||
### バグの可能性
|
||
- 論理エラーや条件分岐の問題
|
||
- エッジケースの処理
|
||
- null/undefined参照の可能性
|
||
- エラーハンドリングの適切さ
|
||
- 非同期処理の正しい扱い
|
||
- リソースリーク（メモリ、ファイルハンドルなど）
|
||
|
||
### テストカバレッジ
|
||
- テストコードの有無
|
||
- テストケースの網羅性
|
||
- 重要な機能に対するテストの存在
|
||
- エッジケースのテストカバレッジ
|
||
|
||
3. **レビュー結果の出力**
|
||
以下の形式で結果を出力してください：
|
||
|
||
```markdown
|
||
# PR #{PR番号} レビュー結果
|
||
|
||
## 📊 概要
|
||
- タイトル: [PR title]
|
||
- 変更ファイル数: [数]
|
||
- 追加行数: [数]
|
||
- 削除行数: [数]
|
||
|
||
## ✅ 良い点
|
||
- [具体的な良い点を列挙]
|
||
|
||
## ⚠️ 改善提案
|
||
|
||
### 🔴 重要度: 高
|
||
- [重大な問題や必須の修正事項]
|
||
|
||
### 🟡 重要度: 中
|
||
- [改善が望ましい項目]
|
||
|
||
### 🟢 重要度: 低
|
||
- [マイナーな提案や最適化]
|
||
|
||
## 🔒 セキュリティチェック
|
||
- [セキュリティに関する指摘]
|
||
|
||
## 🧪 テストに関する所見
|
||
- [テストカバレッジや品質についての指摘]
|
||
|
||
## 📝 総評
|
||
[総合的な評価とマージ可否についての判断]
|
||
```
|
||
|
||
## 注意事項
|
||
- レビューは建設的かつ具体的に行うこと
|
||
- 問題を指摘する際は、改善案も提示すること
|
||
- ファイルパスと行番号を明記すること（例: `src/main.js:42`）
|
||
- 重要度に応じて優先順位をつけること
|