gitlab-code-review

GitLab コードレビュー

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

GitLab インスタンスの設定

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

• GitLab URL: https://gitlab-erp-pas.dedalus.lan
• すべてのプロジェクト識別子、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：diff の位置情報を含むオブジェクト：
  • 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：Issue に関連する 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

重要な注意事項

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