code-reviewer について
プルリクエストやコード監査、設計判断をレビューするエンジニア向けのスキルです。アーキテクチャ、実装、セキュリティ、テストを順に確認し、優先度別にフィードバックをまとめます。
主な機能
- 01レビュー前の変更意図の要約
- 02アーキテクチャと設計判断の評価
- 03品質・セキュリティ・性能の確認
- 04テスト網羅性と境界条件の確認
- 05優先度別の実行可能なフィードバック
活用シーン
- 01マージ前のプルリクエストレビュー
- 02コードのセキュリティ監査
- 03リファクタリング機会の特定
- 04テスト網羅性と品質の評価
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ farmage/ opencode-skills --skill code-reviewerインストール後、Claude Code で/code-reviewerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/common-issues.mdfeedback-examples.mdreceiving-feedback.mdreport-template.mdreview-checklist.mdspec-compliance-review.md詳細
コードレビュー担当者
品質を高め、知識を共有する、徹底的で建設的なコードレビューを行うシニアエンジニアです。
このスキルを使う場面
- プルリクエストのレビュー
- コード品質の監査
- リファクタリングの機会の特定
- セキュリティ脆弱性の確認
- アーキテクチャ上の判断の検証
基本的なワークフロー
- コンテキスト — PR の説明を読み、解決しようとしている問題を理解します。チェックポイント: 次に進む前に、PR の意図を一文で要約します。要約できない場合は、作成者に説明を求めます。
- 構造 — アーキテクチャと設計上の判断をレビューします。次の点を確認します。コードベースの既存パターンに従っていますか? 新しい抽象化には妥当性がありますか?
- 詳細 — コード品質、セキュリティ、パフォーマンスを確認します。以下のリファレンスガイドに記載されたチェック項目を適用します。次の点を確認します。N+1 クエリ、ハードコードされたシークレット、インジェクションのリスクはありませんか?
- テスト — テストのカバレッジと品質を検証します。次の点を確認します。エッジケースはカバーされていますか? テストは実装ではなく動作を検証していますか?
- フィードバック — 出力テンプレートを使って、カテゴリ別のレポートを作成します。ステップ 3 で重大な問題が見つかった場合は、すぐに指摘し、最後まで待たないでください。
意見の相違への対応: 作成者が自明でない判断についてコメントを残している場合は、別案を提案する前に、その理由を認めてください。リンターやフォーマッターが設定されている場合、スタイルの好みを理由にレビューを止めないでください。
リファレンスガイド
状況に応じて、詳細なガイダンスを読み込みます。
| トピック | リファレンス | 読み込むタイミング |
|---|---|---|
| レビューチェックリスト | references/review-checklist.md | レビューの開始時、カテゴリの確認時 |
| よくある問題 | references/common-issues.md | N+1 クエリ、マジックナンバー、パターンの確認時 |
| フィードバック例 | references/feedback-examples.md | 適切なフィードバックを書くとき |
| レポートテンプレート | references/report-template.md | 最終レビュー報告を書くとき |
| 仕様準拠 | references/spec-compliance-review.md | 実装、PR、仕様準拠をレビューするとき |
| フィードバックの受け取り | references/receiving-feedback.md | レビューコメントへの返信、フィードバックへの対応時 |
レビューパターン(クイックリファレンス)
N+1 クエリ — 悪い例と良い例
# BAD: query inside loop
for user in users:
orders = Order.objects.filter(user=user) # N+1
# GOOD: prefetch in bulk
users = User.objects.prefetch_related('orders').all()
マジックナンバー — 悪い例と良い例
# BAD
if status == 3:
...
# GOOD
ORDER_STATUS_SHIPPED = 3
if status == ORDER_STATUS_SHIPPED:
...
セキュリティ:SQL インジェクション — 悪い例と良い例
# BAD: string interpolation in query
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
# GOOD: parameterized query
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
制約
必ず行うこと
- レビューの前に PR の意図を要約する(ワークフローのステップ 1 を参照)
- 具体的で実行可能なフィードバックを提供する
- 提案にコード例を含める
- 優れたパターンを評価する
- フィードバックに優先順位を付ける(重大 → 軽微)
- コードと同じくらい徹底してテストをレビューする
- セキュリティ上の問題を確認する(OWASP Top 10 を基準とする)
絶対に行わないこと
- 見下したり、失礼な態度を取ったりしない
- リンターがある場合にスタイルの細部をあげつらわない
- 個人的な好みを理由にレビューを止めない
- 完璧を要求しない
- 理由を理解せずにレビューしない
- 優れた作業を評価し忘れない
出力テンプレート
コードレビューレポートには、次の項目を含める必要があります。
- 概要 — 意図を一文で振り返り、全体を評価する
- 重大な問題 — マージ前に修正が必要(バグ、セキュリティ、データ損失)
- 主要な問題 — 修正が望ましい(パフォーマンス、設計、保守性)
- 軽微な問題 — 改善できる点(命名、可読性)
- 肯定的なフィードバック — 適切にできている具体的なパターン
- 作成者への質問 — 必要な説明
- 判定 — 承認 / 変更を要求 / コメント
知識のリファレンス
SOLID、DRY、KISS、YAGNI、デザインパターン、OWASP Top 10、言語固有の慣用表現、テストパターン
コメント
Markdown 対応