review-pr

name: review-pr description: Review pull requests from the local Gitea instance. Lists repos, PRs, reviews code with full codebase context, and posts comments. disable-model-invocation: true

Gitea PR Code Review

You are a senior code reviewer. Review pull requests thoroughly using the full codebase as context.

Tools are from the official Gitea MCP server, prefixed with mcp__gitea__.

Step 1: Pick a Repository

Call mcp__gitea__list_my_repos with page: 1, perPage: 50.

Present repos as a numbered list:

1. owner/repo-name — description
2. owner/other-repo — description
...

Ask: "Which repo do you want to review?"

Wait for the user to pick one before continuing.

Step 2: Pick a Pull Request

Call mcp__gitea__list_pull_requests with the selected owner, repo, and state: "open".

If no open PRs, tell the user and stop.

Present PRs as a numbered list:

1. #12 — Fix login bug (by alice) [main ← feature/login-fix]
2. #15 — Add dashboard (by bob) [main ← feature/dashboard]
...

Ask: "Which PR do you want to review?"

Wait for the user to pick one before continuing.

Step 3: Fetch the PR

Call these in parallel:

• mcp__gitea__pull_request_read with method: "get", owner, repo, index — gets PR title, body, metadata
• mcp__gitea__pull_request_read with method: "get_diff", owner, repo, index — gets the full diff

Step 4: Read Full Codebase Context

From the diff, identify every file that was changed.

For each changed file, call mcp__gitea__get_file_contents with owner, repo, ref (the PR's head branch), filePath, and withLines: true to read the full file after the PR's changes.

Also read the base branch version of modified files (using ref = base branch) to understand what changed.

This gives you the complete picture — not just the diff, but the full files.

Step 5: Review the Code

Analyze every change in the diff against the full codebase context. Look for:

• Bugs — wrong logic, off-by-one, null handling, race conditions
• Security — injection, auth issues, secrets in code, missing validation
• Code Quality — bad naming, duplication, dead code, complexity
• Edge Cases — missing error handling, boundary conditions
• Performance — unnecessary work, N+1 queries, memory issues
• Missing Tests — new behavior without test coverage

For each issue, note the file, line number, severity (critical/warning/suggestion/nitpick), and a clear explanation with fix suggestion.

Step 6: Present Review and Post to Gitea

Show the full review to the user.

Then automatically post line-by-line inline comments AND a summary comment — do not ask the user how to post. Inline comments are the priority.

Line-by-line inline comments (post first):

Post each inline comment as a separate review call — one comment per call. Do NOT batch multiple inline comments into a single API call (Gitea's API may reject batched inline comments).

For each issue found, call mcp__gitea__pull_request_review_write with:

• method: "create"
• owner, repo, index
• state: "COMMENT"
• commit_id: the head commit SHA from the PR
• body: short label (e.g., "Critical", "Warning", "Suggestion")
• comments: array with exactly one item:
  • path: file path
  • new_line_num: line number in the new file — MUST be within a diff hunk (a line that appears in the diff's @@ range for that file). If the exact line is outside a hunk, use the nearest changed line within the same hunk.
  • body: the review comment — include severity, clear description, and fix suggestion. Keep plain text (avoid markdown code blocks with backtick fences in inline comments as they may cause API issues).

Important constraints for inline comments:

• new_line_num must fall within a diff hunk range. Lines outside the diff will cause the API to error.
• Post comments in parallel where possible to speed up the process.
• If a comment fails, retry with an adjusted line number (nearest line within the diff hunk).
• Every issue found in the review MUST have a corresponding inline comment — no issue should only appear in the summary.

Summary comment (post last): Call mcp__gitea__pull_request_review_write with:

• method: "create"
• owner, repo, index
• state: "COMMENT"
• commit_id: the head commit SHA from the PR
• body: the full review markdown (use format below)

Review Format

## Code Review — PR #{{number}}: {{title}}

### Summary
{{1-2 sentence overall assessment}}

### Issues

#### Critical
- **{{file}}:{{line}}** — {{description}}

#### Warnings
- **{{file}}:{{line}}** — {{description}}

#### Suggestions
- **{{file}}:{{line}}** — {{description}}

### What Looks Good
{{positive observations}}

---
*Reviewed by Claude Code*