code-reviewer

コードレビュー

プルリクエストやコード変更を分析し、品質、セキュリティ、保守性、ベストプラクティスを確認する包括的なコードレビュースキルです。

このスキルが有効になるとき

このスキルは、次の場合に有効になります。

• コードレビューを依頼したとき
• PR レビューを依頼したとき
• 変更のレビューについて言及したとき
• 「これをレビューして」や「このコードをチェックして」と伝えたとき

レビュープロセス

フェーズ 1：コンテキストの収集

1. 変更されたファイルを取得

   git diff main...HEAD --name-only
   git log main...HEAD --oneline
   

2. 差分を取得

   git diff main...HEAD
   

3. プロジェクトのコンテキストを把握

   • 関連するドキュメントを読む
   • 類似ファイルにおける既存のパターンを確認する
   • プロジェクト固有の規約を特定する

フェーズ 2：分析カテゴリ

1. 正確性

• ロジックに問題がなく、要件に合致している
• エッジケースが処理されている
• エラー処理が適切である
• 明らかなバグや誤字がない

2. セキュリティ

• 秘密情報や認証情報がハードコードされていない
• 入力値の検証とサニタイズが行われている
• SQL インジェクションが防止されている
• XSS が防止されている（フロントエンドの場合）
• 認証／認可のチェックが行われている
• ユーザーデータが安全に扱われている

3. パフォーマンス

• N+1 クエリがない
• キャッシュが適切に使用されている
• アルゴリズムが効率的である
• 不要な計算がない
• メモリ効率がよい

4. コード品質

• DRY 原則に従っている
• KISS 原則に従っている
• 抽象化が適切である
• 命名規則が明確である
• 型が適切に指定されている（TypeScript の場合）
• コメントアウトされたコードがない

5. テスト

• テストで新しい機能がカバーされている
• テストでエッジケースがカバーされている
• テストのアサーションに意味がある
• 壊れやすいテストがない

6. ドキュメント

• 複雑なロジックが説明されている
• 公開 API にドキュメントがある
• 関数に JSDoc/TSDoc がある
• 必要に応じて README が更新されている

7. 保守性

• コードが読みやすい
• スタイルが一貫している
• モジュール化された設計になっている
• 関心事が分離されている

フェーズ 3：出力形式

レビューのフィードバックには、次の構造化された形式を使用します。

# Code Review

## Summary
Brief overview of the changes (2-3 sentences).

## Issues by Severity

### Critical
Must fix before merge.

- [ ] **Issue Title**: Description with file:line reference

### High
Should fix before merge unless there's a good reason.

- [ ] **Issue Title**: Description with file:line reference

### Medium
Consider fixing, can be done in follow-up.

- [ ] **Issue Title**: Description with file:line reference

### Low
Nice to have improvements.

- [ ] **Issue Title**: Description with file:line reference

## Positive Highlights
What was done well in this PR.

## Suggestions
Optional improvements that don't require immediate action.

## Approval Status
- [ ] Approved
- [ ] Approved with suggestions
- [ ] Request changes

よくある問題の確認

セキュリティ上の問題

問題	パターン	推奨事項
秘密情報のハードコード	const API_KEY = "sk-"	環境変数を使用する
SQL インジェクション	\"SELECT * FROM...\" + user_input	パラメーター化クエリを使用する
XSS 脆弱性	innerHTML = user_input	サニタイズするか、textContent を使用する
認証チェックの欠落	@RequireAuth のない新しいエンドポイント	認証ミドルウェアを追加する

パフォーマンス上の問題

問題	パターン	推奨事項
N+1 クエリ	データベース呼び出しを含むループ	イーガーローディングまたはバッチクエリを使用する
不要な再レンダリング	useEffect の依存配列が不足している	依存配列を修正する
メモリリーク	イベントリスナーが削除されていない	useEffect の return でクリーンアップを追加する
非効率なループ	O(n²) のネストされたループ	ハッシュマップまたは別のアルゴリズムを検討する

コード品質の問題

問題	パターン	推奨事項
コードの重複	類似したブロックが繰り返されている	関数に切り出す
マジックナンバー	if (status === 5)	名前付き定数を使用する
長い関数	関数が 50 行を超える	小さな関数に分割する
複雑な条件式	`a && b

テスト上の問題

問題	パターン	推奨事項
テストがない	テストファイルのない新機能	ユニットテストを追加する
エッジケースが未テスト	正常系のみをカバーするテスト	エッジケースのテストを追加する
壊れやすいテスト	実装の詳細に依存するテスト	実装ではなく動作をテストする
アサーションの欠落	何もアサートしないテスト	適切なアサーションを追加する

言語別ガイドライン

TypeScript

• 型が指定されていない値には any ではなく unknown を使用する
• 公開 API には interface を、ユニオン型には type を優先する
• strict モード設定を使用する
• 可能な限り as による型アサーションを避ける

React

• Hooks のルールに従う
• useCallback／useMemo を適切に使用する（早まって使用しない）
• 関数コンポーネントを優先する
• リストでは適切な key props を使用する
• Context を使って prop drilling を避ける

Python

• PEP 8 スタイルガイドに従います
• 型ヒントを使用します
• フォーマットには f-string を使用します
• map/filter よりもリスト内包表記を優先します
• リソースにはコンテキストマネージャーを使用します

Go

• エラーを明示的に処理します
• 明確さのために名前付き戻り値を使用します
• goroutine はシンプルに保ちます
• 通信にはチャネルを使用します
• パッケージレベルの状態を避けます

承認する前に

以下を確認してください：

• すべての重大な問題に対処している
• テストがローカルで合格する
• マージの競合がない
• コミットメッセージが明確である
• ドキュメントが更新されている
• 破壊的変更が文書化されている

スクリプト

レビューチェックリストのスクリプトを実行します：

python3 scripts/review_checklist.py --base main --output review-checklist.md

参考資料

• references/checklist.md - レビューチェックリストの全項目
• references/security.md - セキュリティレビューのガイドライン
• references/patterns.md - よくあるパターンとアンチパターン