Code Review 35

---
name: code-review
description: |
  コードレビューを実施する際に使用。プルリクエストのレビュー、コード品質チェック、
  セキュリティ検査、パフォーマンス分析を行う。「レビューして」「コードをチェック」
  「品質を確認」などの指示で起動。
---

# Code Review Skill

## Purpose

このスキルは、以下のガイドライン(`~/.claude/CLAUDE.md`)に基づいた体系的なコードレビューを提供します:

- コード品質の向上
- セキュリティ脆弱性の検出
- パフォーマンス問題の特定
- 保守性の評価
- ベストプラクティスの適用

## When to Use

以下の場合にこのスキルを使用:

- プルリクエストのレビュー依頼時
- 「コードをレビューして」という明示的な指示
- コード品質チェックの要求
- セキュリティレビューの必要時
- リファクタリング前の評価

## Instructions

### 1. Check CI/CD Status

**プルリクエストの場合、最初にCI/CDステータスをチェックする:**

```bash
# GitHubのPR番号が明示されている場合
gh pr view <PR番号> --json statusCheckRollup

# または、現在のブランチのPRを確認
gh pr status
gh pr checks
```

**CI/CDチェックの結果に応じた対応:**

- ✅ **すべてパス**: 通常のコードレビューに進む
- ❌ **失敗あり**:
  - **自分が作成したPR**: 失敗原因を分析し、修正を実施
  - **他人のPRレビュー**: 失敗内容を確認し、レビューコメントに含める

**CI失敗時の詳細確認:**

```bash
# 失敗したチェックの詳細を確認
gh pr checks <PR番号>

# ログの取得（GitHub Actionsの場合）
gh run view <run-id> --log-failed
```

### 2. Confirm Review Scope

レビュー対象を明確にする:

```bash
# 変更ファイルの確認
git status
git diff --name-only

# PRの場合は差分を確認
gh pr diff <PR番号>

# または特定のファイルが指定されている場合はそれを対象とする
```

### 3. Understand Context

レビュー前に以下を確認:

- プロジェクトの種類(プロトタイプ/MVP/本番)
- 関連する既存コード
- テストの存在
- ドキュメント

### 4. Handle CI Failures

**自分のPRでCI失敗の場合:**

1. **失敗の原因を特定**:
   - テスト失敗: どのテストがなぜ失敗したか
   - ビルドエラー: コンパイルエラー、型エラー等
   - Linter/Formatter: コーディングスタイル違反
   - セキュリティスキャン: 脆弱性検出

2. **修正を実施**:
   - エラーログを読み、根本原因を修正
   - 関連するテストケースも更新
   - ローカルで同じチェックを実行して検証

3. **再プッシュ**:
   ```bash
   git add .
   git commit -m "fix: resolve CI failures"
   git push
   ```

**他人のPRレビューでCI失敗の場合:**

レビューコメントの冒頭に以下を追加:

```markdown
## ⚠️ CI/CD Status

### 失敗しているチェック
- [チェック名1]: [失敗理由の要約]
- [チェック名2]: [失敗理由の要約]

### 修正が必要なアクション
1. [具体的な修正内容]
2. [具体的な修正内容]

詳細は以下のコードレビューを参照してください。

---
```

### 5. Conduct Systematic Review

以下の観点でコードを評価(詳細は[reference.md](reference.md)参照):

#### A. コード品質
- 可読性(変数名、関数名の適切性)
- DRY原則の遵守
- 適切な抽象化レベル
- コメントの質(「なぜ」を説明)

#### B. エラーハンドリング
- エラーケースの適切な処理
- エラーの抑制ではなく根本原因の解決
- 明確なエラーメッセージ
- 外部API呼び出しの失敗処理

#### C. セキュリティ
- 認証情報のハードコード確認
- 入力検証の実装
- OWASP Top 10の脆弱性チェック
- 最小権限の原則

#### D. テスト
- テストカバレッジ
- エッジケースのテスト
- テストの独立性
- テストの可読性

#### E. パフォーマンス
- N+1問題
- 不要なループや計算
- キャッシング戦略
- リソースリーク

#### F. 保守性
- 適切なモジュール分割
- 依存関係の明確性
- 技術的負債の記録
- 一貫したコーディングスタイル

### 6. Provide Feedback

レビュー結果を以下の形式で提供:

```markdown
## コードレビュー結果

### ⚠️ CI/CD Status (該当する場合)
[CI失敗情報をここに記載]

### 🔴 Critical Issues (即座に修正が必要)
- [具体的な問題と場所]
- [修正案]

### 🟡 Warnings (修正を推奨)
- [改善提案]
- [理由]

### 🟢 Good Practices (良い点)
- [評価できる実装]

### 💡 Suggestions (任意の改善案)
- [より良い実装の提案]

### 📝 Notes
- [その他の気づき]
```

### 7. Constructive Communication

- 個人ではなくコードに焦点を当てる
- 問題だけでなく、良い点も指摘
- 具体的な改善案を提示
- 「なぜ」その変更が必要かを説明

## Key Principles

1. **プロジェクトコンテキストを考慮**: プロトタイプと本番環境では異なる基準を適用
2. **優先順位付け**: Critical > Warning > Suggestion の順で重要度を明示
3. **実用性**: 完璧を求めすぎず、適切なバランスを取る
4. **学習機会**: レビューを教育の機会として活用

## Reference Documents

- [詳細なレビュー基準](reference.md)
- [レビュー実例](examples.md)

## Dependencies

- Git (変更差分の確認用)
- GitHub CLI (`gh`) - PR情報とCI/CDステータスの取得用
- プロジェクト固有のlinter/formatter(存在する場合)

## CI/CD Integration

このスキルは以下のCI/CDシステムに対応:
- GitHub Actions
- CircleCI (GitHub統合経由)
- その他GitHub Checksに統合されているCI/CD

**注意**: PRのCI/CDステータス確認には`gh`コマンドが必要です。インストール方法:
```bash
# macOS
brew install gh

# 認証
gh auth login
```