oto1720/code-review

Code Review Skill

指定されたコードを多角的にレビューし、指摘事項レポートをMarkdown形式で出力する。

入力

$ARGUMENTS にファイルパス、ディレクトリ、または機能名を受け取る。 未指定の場合は git diff または直近の変更ファイルを対象にする。

実行フロー

Step 1: レビュー対象の特定

# 引数がある場合
find $ARGUMENTS -type f \( -name "*.dart" -o -name "*.go" -o -name "*.ts" -o -name "*.tsx" -o -name "*.py" \) 2>/dev/null

# 引数がない場合: 直近のgit変更を取得
git diff --name-only HEAD 2>/dev/null || git diff --cached --name-only 2>/dev/null

# ステージング済みの変更
git diff --staged --name-only 2>/dev/null

Step 2: コンテキスト収集

レビュー前にプロジェクトの規約・スタイルを把握する:

# コーディング規約・リントルールの確認
cat analysis_options.yaml 2>/dev/null    # Dart
cat .eslintrc* 2>/dev/null               # JS/TS
cat pyproject.toml 2>/dev/null           # Python
cat .golangci.yml 2>/dev/null            # Go

# 既存のテストコード確認
find . -name "*_test.dart" -o -name "*.test.ts" -o -name "*_test.go" | head -20

Step 3: 多角的レビューの実施

以下の7つの観点で各ファイルを分析する:

🔴 Critical（必ず修正）

• バグ・ロジックエラー: 条件分岐の誤り、off-by-one、null安全性の欠落
• セキュリティ問題: SQLインジェクション、XSS、認証バイパス、シークレットのハードコード
• データ損失リスク: 例外未処理による書き込み失敗、トランザクション漏れ

🟠 Major（早めに修正）

• パフォーマンス問題: N+1クエリ、不要なリビルド、メモリリーク
• 設計の問題: 責任の分離違反、プロジェクトのアーキテクチャ規約違反
• 重複コード: DRY原則の違反、共通化できるロジック

🟡 Minor（改善推奨）

• 命名: 意図が伝わらない変数名・関数名
• 可読性: 複雑すぎる条件式、深すぎるネスト
• コメント: 古いコメント、必要なのにないコメント

🟢 Good（良い点・褒める）

• うまく実装されている箇所も必ず記載する

🔵 Suggestion（提案）

• リファクタリングの機会
• より良いパターンの提案（コード例付き）

📝 Testing

• テストが不足している箇所
• テストケースの提案

📚 Documentation

• JSDoc / DartDoc / GoDoc が必要な箇所

Step 4: レビューレポートの生成

docs/reviews/review_{YYYYMMDD_HHMMSS}.md に出力:

# コードレビューレポート

**レビュー日時**: {date}  
**対象**: {対象ファイル一覧}  
**レビュアー**: Claude Code (code-review skill)

---

## 📊 サマリー

| 重要度 | 件数 |
|--------|------|
| 🔴 Critical | N |
| 🟠 Major    | N |
| 🟡 Minor    | N |
| 🟢 Good     | N |
| 🔵 Suggestion | N |

**総合評価**: [Excellent / Good / Needs Work / Major Issues]

---

## 🔴 Critical Issues

### [C-1] {問題のタイトル}

**ファイル**: `path/to/file.dart:42`  
**問題**: {何が問題か}

```dart
// ❌ 現在のコード
{実際のコードを引用}

// ✅ 修正案
{修正後のコード}

理由: {なぜ問題なのか、リスクは何か}

---

🟠 Major Issues

[同様のフォーマット]

---

🟡 Minor Issues

[同様のフォーマット]

---

🟢 Good Points

[G-1] {良い点のタイトル}

ファイル: path/to/file.dart:15
{なぜ良いか、どう参考になるか}

---

🔵 Suggestions

[S-1] {提案のタイトル}

ファイル: path/to/file.dart:78

// 💡 こういう書き方もできる
{提案コード}

---

📝 Test Coverage

テスト不足の箇所:

• {ファイル}: {テストすべきケース}

追加を推奨するテストケース:

// テストコード例

---

アクションアイテム

• [ ] [C-1] {Critical問題} — 必須・今すぐ
• [ ] [M-1] {Major問題} — 必須・今週中
• [ ] [S-1] {Suggestion} — 任意

---

Generated by Claude Code / code-review skill

### Step 5: インラインコメントファイルの生成（オプション）

`docs/reviews/inline_{YYYYMMDD}.md` に行番号付きのコメントも出力:

```markdown
## インラインコメント一覧

| ファイル | 行 | 重要度 | コメント |
|---------|-----|--------|---------|
| auth_service.dart | 42 | 🔴 | nullチェックが不足 |
| home_page.dart | 88 | 🟡 | 変数名をより明確に |

品質基準

• 必ず実際のコードを引用する（架空のコードを書かない）
• 修正案を必ずコードで示す（「修正してください」だけでは不十分）
• 良い点も最低3つ挙げる（建設的なレビューのため）
• ファイル名と行番号を必ず記載
• プロジェクトのアーキテクチャ規約に照らして評価する

出力完了メッセージ

✅ コードレビュー完了

📄 レポート: docs/reviews/review_{timestamp}.md

🔴 Critical: N件  🟠 Major: N件  🟡 Minor: N件
🟢 Good: N件  🔵 Suggestion: N件

総合評価: [評価]