review-pr

注：ローカルに mcporter がインストールされている場合は、MCP ツールを直接呼び出すのではなく、mcporter を使用して呼び出してください。mcporter CLI は、より便利なインターフェースと優れたエラー処理を提供します。

Gitee MCP を使用した PR のレビュー

Gitee リポジトリのプルリクエストを徹底的にコードレビューします。

前提条件

• Gitee MCP サーバーが設定済みであること（ツール：get_pull_detail、get_diff_files、list_comments（resource_type: pull）、create_comment（resource_type: pull））
• ユーザーがリポジトリのオーナー、リポジトリ名、PR 番号を指定する必要があります（または「最新の PR をレビューして」と伝える必要があります）。
• 任意：現在のディレクトリが PR のリポジトリのローカルクローンである場合は、ローカルの git コマンドやファイルアクセスを活用して、より多くのコンテキストを取得できます。

手順

ステップ 1：PR の詳細を取得する

get_pull_detail を使用して PR の情報を取得し、以下を確認します。

• タイトルと説明が変更の目的を明確に説明しているか
• ソースブランチとターゲットブランチが正しいか
• PR の状態（すでにクローズまたはマージされている場合は、レビューを中止します）
• Draft かどうか（Draft の場合は、ユーザーに知らせます）

ステップ 2：差分ファイルを取得する

get_diff_files を使用して変更されたファイルの一覧を取得し、以下を分析します。

• 変更されたファイルの数と範囲
• 機密性の高いファイル（設定ファイル、シークレット、権限関連のコード）が含まれているか

主要な変更ファイルごとに、get_file_content を使用してコンテキストを把握します。

ローカルリポジトリのディレクトリで実行している場合は、ローカルの git コマンドやファイルアクセスを活用し、レビューの追加情報を取得します（例：関連するコミットやファイル、ファイル履歴の確認）。

ステップ 3：既存のコメントを確認する

list_comments（resource_type: pull）を使用して既存のコメントを取得し、すでに議論されている問題を再度指摘しないようにします。

ステップ 4：コードレビュー

以下の観点でコードをレビューします。

正確性

• ロジックは正しいか。エッジケースに対応できているか。
• 明らかなバグやヌルポインターのリスクはないか。
• エラー処理は十分か。

セキュリティ

• SQL インジェクション、XSS、コマンドインジェクションなどのセキュリティリスクはないか。
• 機密情報がハードコードされていないか。
• 権限チェックが実装されているか。

保守性

• 名前は明確で、意味が分かりやすいか。
• 各関数／メソッドが単一の責務を担っているか。
• 複雑なロジックのブロックにコメントが記載されているか。

パフォーマンス

• 不必要な多重ループや N+1 クエリはないか。
• 大きなファイルの操作で、メモリ使用量が考慮されているか。

一貫性

• コードは既存のプロジェクトのスタイルに従っているか。
• 関連するモジュールと一貫しているか。

ステップ 5：問題を分類する

指摘事項を重要度別に分類します。

• 🔴 ブロッカー：正確性に影響する、またはセキュリティリスクがある — 必ず修正が必要です
• 🟡 提案：コード品質に関する問題 — 推奨しますが、必須ではありません
• 🟢 任意：あると望ましい改善

ステップ 6：レビュー結果をユーザーに提示する

停止 — まだ投稿しないでください！

確認を求めるため、レビュー内容をユーザーに提示します。次の形式を使用します。

## Code Review Preview

**Summary**: [One sentence describing the purpose of the PR and overall quality assessment]

### 🔴 Blockers
1. **[filename:line]** [Issue description]
   - Problem: [Specific explanation]
   - Suggestion: [How to fix it]

### 🟡 Suggestions
1. **[filename]** [Issue description]
   - Suggestion: [Direction for improvement]

### 🟢 Optional
1. [Improvement suggestion]

### Conclusion
[Overall assessment — LGTM or key changes needed]

問題が見つからない場合は、次のように表示します。

## Code Review Preview

LGTM! No significant issues found. Code quality looks good.

その後、ユーザーに次のように尋ねます。「请确认以上评审内容是否有问题。确认无误后，我将提交到 PR。」

ステップ 7：レビューコメントを投稿する（ユーザー確認後）

ユーザーがレビュー内容に問題がないことを確認したら、create_comment（resource_type: pull）を使用して PR にレビューを投稿します。次の形式を使用します。

## Code Review

**Summary**: [One sentence describing the purpose of the PR and overall quality assessment]

### 🔴 Blockers
1. **[filename:line]** [Issue description]
   - Problem: [Specific explanation]
   - Suggestion: [How to fix it]

### 🟡 Suggestions
1. **[filename]** [Issue description]
   - Suggestion: [Direction for improvement]

### 🟢 Optional
1. [Improvement suggestion]

### Conclusion
[Overall assessment — LGTM or key changes needed]

🤖 Generated by AI + Gitee MCP

問題が見つからない場合は、次のコメントを投稿します。

## Code Review

LGTM! No significant issues found. Code quality looks good.

🤖 Generated by AI + Gitee MCP

注意事項

• PR で新規または変更されたコードのみを対象とし、既存のコードは対象にしないでください。
• 細かな指摘は避けてください。リンターで自動的に検出できる問題は指摘しないでください。
• コメントは具体的で、実行可能な内容にしてください。単なる所見ではなく、提案を提示してください。
• 不確かな問題については、確実にバグだと断定せず、「確認を推奨します」と伝えてください。