code-review

コードレビュー

GitLab のマージリクエストを包括的にレビューし、コード品質、セキュリティ、パフォーマンス、ベストプラクティスに関する実行可能なフィードバックを提供します。

前提条件

• glab（GitLab CLI）：すべての MR およびパイプライン操作に必須です。https://gitlab.com/gitlab-org/cli または brew install glab からインストールしてください。

GitLab インスタンスの設定

このスキルはセルフホストの GitLab インスタンス用に設定されています。

• GitLab URL: https://gitlab-erp-pas.dedalus.lan
• すべてのプロジェクト ID、URL、参照には、このセルフホストのインスタンスを使用してください。
• この GitLab サーバーに適切なアクセス認証情報が設定されていることを確認してください。

このスキルを使用する場面

次の場合にこのスキルを有効にします。

• ユーザーが「review」または「code review」と入力した場合（スラッシュコマンドの有無は問いません）
• ユーザーが特定のマージリクエストをレビューするために「review MR-123」または「review !123」と入力した場合
• ユーザーが「review ISSUE-ID」（例：「review #456」）と入力し、GitLab イシューに関連する MR をレビューする場合
• ユーザーがマージリクエストのレビューを依頼した場合
• マージ前にコード変更を分析する場合
• コード品質を評価する場合
• セキュリティの脆弱性やパフォーマンスの問題を確認する場合
• マージリクエストの差分をレビューする場合

重要なルール

重要：マージリクエストをレビューする前に、必ず project_id を確認してください

建設的なフィードバックは、指示ではなく質問の形で必ず伝えてください

無関係なコードではなく、マージリクエストで導入された変更のみをレビューしてください

ワークフロー

1. マージリクエストを特定する

マージリクエスト IID が指定されている場合

マージリクエスト IID が指定されている場合（例：「review !123」または「review MR 123」）：

1. ユーザーの入力から MR IID を抽出します
2. プロジェクトのコンテキストを確認します（不明な場合はユーザーに尋ねます）
3. glab mr view <iid> を使用してマージリクエストの詳細を取得します

GitLab イシュー ID が指定されている場合

GitLab イシュー ID が指定されている場合（例：「review #456」）：

1. glab issue view <iid> を使用してイシューの詳細を取得し、コンテキストを把握します
2. glab mr list --search "<issue reference>" を使用して関連するマージリクエストを探します
3. 複数の MR が見つかった場合は、レビュー対象をユーザーに選んでもらいます
4. 選択された MR のレビューに進みます

特定の MR が指定されていない場合

MR が指定されていない場合（例：「review」のみ）：

1. glab mr list --state opened を使用して最近のオープン中のマージリクエストを一覧表示します
2. 一覧をユーザーに提示します
3. レビュー対象の MR を選んでもらいます

2. マージリクエストのコンテキストを収集する

セルフホストの GitLab インスタンス： https://gitlab-erp-pas.dedalus.lan

glab mr view <iid> を使用して以下を取得します。

• タイトルと説明
• ソースブランチとターゲットブランチ
• 作成者情報
• 状態（オープン、マージ済み、クローズ）
• ラベルとマイルストーン
• 承認状況
• パイプラインの状態
• 正確な差分比較に必要な diff_refs（base_sha、head_sha、start_sha）

重要な情報を抽出します：

Project: namespace/project
MR: !123 - "Feature: Add user authentication"
Author: @username
Source: feature/auth -> Target: main
Status: Open | Pipeline: Passed | Approvals: 1/2

3. 変更を分析する

ファイルの変更を取得する

glab mr diff <iid> を使用して以下を取得します。

• 変更されたファイルの一覧
• ファイルごとの追加と削除
• 各ファイルの差分内容

ページネーション： 変更されたファイルが多い場合、差分の出力が大きくなることがあります。セクションごとにレビューしてください。

ファイルの詳細な内容を取得する

複雑な変更の場合、git show <ref>:<file_path> を使用して以下を行います。

• ファイル全体のコンテキストを確認する
• 周辺のコードを把握する
• 既存のパターンとの一貫性を確認する

パラメーター：

• <ref>：ソースブランチ、または diff_refs の head_sha を使用します
• <file_path>：ファイルへのパス

コミットを分析する

git log --oneline <source_branch> を使用してコミットを一覧表示し、続いて git show <sha> を使用して以下を行います。

• コミット履歴を把握する
• 個々のコミットの変更をレビューする
• コミットメッセージの品質を確認する

4. 既存のディスカッションを確認する

glab api /projects/:id/merge_requests/:iid/discussions を使用して以下を行います。

• 既存のフィードバックやディスカッションを確認する
• コメントの重複を避ける
• 進行中のやり取りを把握する
• 未解決のスレッドを確認する

5. パイプラインの状態を確認する

glab ci list および glab ci view <pipeline_id> を使用して以下を行います。

• CI/CD パイプラインの状態を確認する
• 失敗したジョブを確認する
• テスト結果を確認する

パイプラインが失敗した場合は、glab ci trace <job_id> を使用して失敗の原因を把握します。

6. 包括的なコードレビューを実施する

このマージリクエストで導入された変更のみを対象に、徹底的にレビューしてください。

コード品質の評価

• コードスタイルとフォーマットの一貫性
• 変数と関数の命名規則
• コードの整理と構成
• DRY（Don't Repeat Yourself）原則の遵守
• 適切な抽象化レベル

技術レビュー

• ロジックの正確性とエッジケース
• エラー処理とバリデーション
• パフォーマンスへの影響
• セキュリティ上の考慮事項（入力バリデーション、SQL インジェクション、XSS など）
• リソース管理（メモリーリーク、接続処理）
• 該当する場合は並行処理の問題

ベストプラクティスの確認

• デザインパターンの使用
• SOLID 原則の遵守
• テストカバレッジへの影響
• ドキュメントの完全性
• API の一貫性
• 下位互換性

依存関係と統合

• 新たに追加された依存関係
• 既存インターフェースへの破壊的変更
• システムの他の部分への影響
• データベースのマイグレーション要件

7. レビューレポートを作成する

以下の内容を含む、構成化されたコードレビューレポートを作成してください。

1. 概要：変更内容の概要と全体的な評価

2. 統計情報：

   • 変更されたファイル数、追加・削除された行数
   • レビューしたコミット数
   • 見つかった重大な問題

3. 良かった点：適切に対応されている点

4. 優先度別の問題：

   • 🔴 重大：マージ前に必ず修正が必要（バグ、セキュリティ上の問題）
   • 🟡 重要：対応が望ましい（パフォーマンス、保守性）
   • 🟢 提案：改善するとよい点

5. 詳細な指摘事項：各問題について、以下を記載してください。

   • ファイルと行番号
   • 懸念点を質問形式で示す
   • 質問する理由を説明する背景情報
   • 参考になる場合はコード例

6. セキュリティレビュー：具体的なセキュリティ上の考慮事項

7. パフォーマンスレビュー：パフォーマンスへの影響

8. テストに関する推奨事項：追加すべきテスト

9. ドキュメントに関する要件：更新すべきドキュメント

8. マージリクエストにコメントを追加する（任意）

重要：MR にコメントを追加する前に、必ずユーザーに確認してください

ユーザーが MR に直接フィードバックを追加したい場合：

全般コメント

glab mr note <iid> --message "<comment>" を使用して全般コメントを追加します。

• <iid>：MR の内部 ID
• <comment>：Markdown 形式のコメント内容

行に紐づくディスカッション

glab api POST /projects/:id/merge_requests/:iid/discussions を使用して、コードに固有のフィードバックを追加します。以下を指定します。

• body：ディスカッションの内容
• position：差分の位置情報を含むオブジェクト：
  • base_sha：diff_refs から取得
  • head_sha：diff_refs から取得
  • start_sha：diff_refs から取得
  • new_path：ファイルパス
  • new_line：新しいコードの行番号
  • old_path：ファイルパス（変更の場合）
  • old_line：削除されたコードの行番号

フィードバックのスタイル：指示ではなく質問にする

フィードバックはすべて、命令ではなく質問として表現してください。 これにより、対話を促し、作者の背景事情に配慮できます。

例

❌ 次のようには書かないでください：

• 「ここでは早期リターンを使うべきです」
• 「ここにはエラー処理が必要です」
• 「これを独立した関数に切り出してください」
• 「null チェックを追加してください」

✅ 次のように書いてください：

• 「早期リターンを使うと、ここを簡潔にできるでしょうか？」
• 「この API 呼び出しが失敗した場合はどうなりますか？ここにエラー処理を追加するとよいでしょうか？」
• 「再利用性を高めるため、これを独立した関数に切り出すのはいかがでしょうか？」
• 「これが null になるケースはありますか？ある場合、どのように処理すべきでしょうか？」

質問形式が効果的な理由

• 作者は、あなたが知らない背景事情を把握しているかもしれません
• 質問は、相手の防御的な反応を招くのではなく、説明を促します
• レビュアーの理解に不確かさがあることを認められます
• チェックリストではなく、対話を生み出します

レビューレポートのテンプレート

# Code Review: !{MR_IID} - {MR_TITLE}

## Executive Summary
{Brief overview of changes and overall assessment}

## Merge Request Details
- **Project**: {project_path}
- **Author**: @{author}
- **Source Branch**: {source_branch} → **Target**: {target_branch}
- **Pipeline Status**: {status}
- **Approvals**: {current}/{required}

## Statistics
| Metric | Count |
|--------|-------|
| Files Changed | {count} |
| Lines Added | +{additions} |
| Lines Removed | -{deletions} |
| Commits | {commit_count} |

## Strengths
- {strength_1}
- {strength_2}

## Issues Found

### 🔴 Critical
{critical_issues_or_none}

### 🟡 Important
{important_issues_or_none}

### 🟢 Suggestions
{suggestions_or_none}

## Security Review
{security_findings}

## Performance Review
{performance_findings}

## Testing Recommendations
- {test_recommendation_1}
- {test_recommendation_2}

## Documentation Needs
- {doc_need_1}

## Verdict
{APPROVED | CHANGES_REQUESTED | NEEDS_DISCUSSION}

例

例 1：特定のマージリクエストをレビューする

User: Review !42 in namespace/project

Assistant actions:
1. glab mr view 42 — fetch MR details
2. glab mr diff 42 — get file changes
3. glab api /projects/:id/merge_requests/42/discussions — check existing feedback
4. glab ci list — check CI status
5. Analyze changes and generate report
6. Present review to user
7. Ask if user wants comments added to the MR

例 2：イシューに関連する MR をレビューする

User: Review the MR for issue #123

Assistant actions:
1. glab issue view 123 — fetch issue details
2. glab mr list --search "#123" — find related MRs
3. Present found MRs and ask user to confirm
4. Proceed with code review workflow

例 3：レビュー対象のオープンな MR を一覧表示する

User: Show me open merge requests to review

Assistant actions:
1. glab mr list --state opened — list open MRs
2. Present list with key details (title, author, pipeline status)
3. Ask user which MR to review

重要な注意事項

• このマージリクエストで変更された内容のみをレビューしてください - 変更されていないコードにはコメントしないでください
• 対話を促すため、フィードバックは質問形式にしてください
• 建設的で具体的なフィードバックを心がけてください
• 改善案にはコード例を提示してください
• 優れたプラクティスや改善点を認めてください
• 問題の優先度を明確にしてください（重大 > 重要 > 提案）
• 変更の背景や目的を考慮してください
• レビューを終える前に、パイプラインのステータスを確認してください
• 同じフィードバックを重複して送らないよう、既存の議論を確認してください
• マージリクエストにコメントを追加する前に、必ず許可を求めてください
• イシューにリンクがある場合は、レビューで受け入れ条件に対応できているか確認してください