Code Review

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

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参照):

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

• 詳細なレビュー基準
• レビュー実例

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