|
|
|
@@ -1,133 +0,0 @@
|
|
|
|
|
---
|
|
|
|
|
name: review-pr
|
|
|
|
|
description: Review pull requests in Gitea repositories using Gitea MCP for server-side PR metadata, comments, reviews, diffs, workflow state, and PR comments. Use local CLI tools such as git and test runners only for local repository inspection and validation. Use when the user asks to "Review PR", "review pull request", "check PR", "recheck PR after updates", or "post review comment". Inspect PR metadata and discussion, compare the PR head against its base branch, produce a clear PASS/FAIL verdict, and optionally post the result back to the PR.
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# Review PR
|
|
|
|
|
|
|
|
|
|
## Local Preference
|
|
|
|
|
|
|
|
|
|
For repositories on `git.thuanle.me`, prefer the `mcp__gitea__` tools for Gitea-hosted pull request metadata, comments, reviews, server-side diffs, repository contents, branches, commits, workflow runs, and PR comments. Do not use `tea` or other command-line Gitea API clients unless the user explicitly asks for them or the MCP tools are unavailable for the required Gitea operation. Other local CLI tools such as `git`, `go`, `rg`, test runners, and formatters are OK for local repository inspection and validation.
|
|
|
|
|
|
|
|
|
|
## Workflow
|
|
|
|
|
|
|
|
|
|
Follow this sequence:
|
|
|
|
|
|
|
|
|
|
1. Identify the PR and current repo context.
|
|
|
|
|
- Use the current repository when the user is already inside it.
|
|
|
|
|
- If the user gives only a PR number and the repo context is ambiguous, ask a short clarifying question.
|
|
|
|
|
- Do not ask follow-up questions when the repository, PR, and requested reviewer action are already clear.
|
|
|
|
|
- If the user has already given a standing instruction earlier in the same thread such as "if you're confident, post it", carry that instruction forward for later re-reviews until the user changes it.
|
|
|
|
|
- Read the PR first with `mcp__gitea__.pull_request_read` using `method: "get"`, and read issue comments with `mcp__gitea__.issue_read` using `method: "get_comments"`.
|
|
|
|
|
- Read reviews with `mcp__gitea__.pull_request_read` using `method: "get_reviews"` when review state matters.
|
|
|
|
|
- Note the PR status exactly. If it is already merged or closed, say so explicitly before continuing.
|
|
|
|
|
|
|
|
|
|
2. Read the review history before judging the latest update.
|
|
|
|
|
- Find the latest blocking review comments first.
|
|
|
|
|
- If the author says they addressed feedback in a follow-up commit, focus on the new commits after that discussion.
|
|
|
|
|
- Still sanity-check the current full PR diff before concluding `PASS`.
|
|
|
|
|
|
|
|
|
|
3. Compare against the real base branch.
|
|
|
|
|
- Use PR metadata from MCP as the source of truth for base/head refs and SHAs.
|
|
|
|
|
- Prefer the PR base branch from MCP metadata; use `main` only when the base branch is not obvious from PR metadata.
|
|
|
|
|
|
|
|
|
|
4. Inspect the code changes.
|
|
|
|
|
- Use `mcp__gitea__.pull_request_read` with `method: "get_diff"` to read the PR diff.
|
|
|
|
|
- Use `mcp__gitea__.get_file_contents`, `mcp__gitea__.get_repository_tree`, and commit/branch MCP reads for surrounding context.
|
|
|
|
|
- If the user asks for a re-review after updates, optionally diff the latest fix commit range as a helper view, but do not skip the full PR sanity check.
|
|
|
|
|
|
|
|
|
|
5. Validate behavior where it matters.
|
|
|
|
|
- Prefer an isolated worktree when validation should run on the PR snapshot instead of the currently checked out branch.
|
|
|
|
|
- Use a repository-local worktree under `.worktrees/` by default, for example `git worktree add .worktrees/pr-<pr> origin/<head>`. Before creating it, run `git worktree list` and confirm the repo-local `.worktrees/` path.
|
|
|
|
|
- For `/Users/tm/working/thuanle/crypto/crypto-price-bot`, PR validation worktrees must be under `.worktrees/pr-<pr>` from the repository root. Do not use `/tmp` for this repo; if `.worktrees/` is unavailable, stop and ask the user before using any fallback path.
|
|
|
|
|
- Run validation commands inside that worktree.
|
|
|
|
|
- Remove it afterward with `git worktree remove .worktrees/pr-<pr>` when it is no longer needed.
|
|
|
|
|
- For other repositories, if `git worktree add` fails because the environment blocks writes to `.git/worktrees`, fall back to exporting a temporary snapshot for validation and say that you used the fallback.
|
|
|
|
|
- Run repo-appropriate checks when feasible.
|
|
|
|
|
- Prefer targeted checks first, then broader validation such as `go test ./...` and `go vet ./...` in Go repositories.
|
|
|
|
|
- Say explicitly when validation could not be run.
|
|
|
|
|
|
|
|
|
|
6. Write the verdict for the user.
|
|
|
|
|
- Start with `PASS` or `FAIL`.
|
|
|
|
|
- For `FAIL`, list blocking findings first, ordered by severity.
|
|
|
|
|
- Include file and line references whenever possible.
|
|
|
|
|
- Explain the concrete behavior impact, not style preferences.
|
|
|
|
|
- For `PASS`, say that no blocking issues were found and then add any non-blocking notes.
|
|
|
|
|
|
|
|
|
|
7. Post a review result proactively by default.
|
|
|
|
|
- When acting as a reviewer, prefer an official PR review over a plain issue comment if the result should affect PR state.
|
|
|
|
|
- Default stance: if the verdict is clear and you are confident in it, post the review without waiting for another prompt from the user.
|
|
|
|
|
- If the user has already asked you to post the result, or has given a standing instruction such as "if you're confident, post it", treat that as continuing authority for later re-reviews in the same thread unless the user revokes or narrows it.
|
|
|
|
|
- Ask the user only when there is a real ambiguity you cannot safely resolve, such as unclear repo/PR context, unclear whether they explicitly want a local-only verdict instead of a posted review, or a materially uncertain finding.
|
|
|
|
|
- If the user explicitly asks for a local verdict only, do not post.
|
|
|
|
|
- Use `mcp__gitea__.pull_request_review_write` for review posting.
|
|
|
|
|
- For normal review results, prefer a single `create` call with the final `state` and `body`. This is the default path for `PASS`, `FAIL`, and neutral review comments.
|
|
|
|
|
- Use `submit` only when you intentionally need a multi-step pending review flow, such as staging a pending review first and finalizing it later.
|
|
|
|
|
- Never send the same review narrative through both `create` and `submit`; that is a process bug and can surface as duplicate review content in the UI.
|
|
|
|
|
- Map the verdict to review state:
|
|
|
|
|
- `PASS` -> `APPROVED`
|
|
|
|
|
- `FAIL` -> `REQUEST_CHANGES`
|
|
|
|
|
- neutral/non-blocking note only -> `COMMENT`
|
|
|
|
|
- Use `mcp__gitea__.issue_write` with `method: "add_comment"` only for plain discussion comments that should not change PR review status.
|
|
|
|
|
- Do not add bracketed author/tool tags such as `[codex]`.
|
|
|
|
|
- Start directly with the review result or author response, depending on your role in the thread.
|
|
|
|
|
- Keep the review/comment concise and direct.
|
|
|
|
|
- Mention the validation commands you actually ran when posting review results.
|
|
|
|
|
|
|
|
|
|
## Command Patterns
|
|
|
|
|
|
|
|
|
|
Use these MCP operations directly:
|
|
|
|
|
|
|
|
|
|
- `mcp__gitea__.pull_request_read` with `method: "get"`
|
|
|
|
|
- `mcp__gitea__.pull_request_read` with `method: "get_diff"`
|
|
|
|
|
- `mcp__gitea__.pull_request_read` with `method: "get_reviews"`
|
|
|
|
|
- `mcp__gitea__.pull_request_read` with `method: "get_review_comments"` when a specific review thread is needed
|
|
|
|
|
- `mcp__gitea__.issue_read` with `method: "get_comments"`
|
|
|
|
|
- `mcp__gitea__.get_file_contents`
|
|
|
|
|
- `mcp__gitea__.get_repository_tree`
|
|
|
|
|
- `mcp__gitea__.get_commit`
|
|
|
|
|
- `mcp__gitea__.actions_run_read` for workflow status and logs
|
|
|
|
|
- `mcp__gitea__.pull_request_review_write` with `method: "create"` for the normal one-shot final review path
|
|
|
|
|
- Set the final `state` on `create`
|
|
|
|
|
- Put the final review text on `create`
|
|
|
|
|
- `mcp__gitea__.pull_request_review_write` with `method: "submit"` only when finishing an intentionally pending review
|
|
|
|
|
- `mcp__gitea__.issue_write` with `method: "add_comment"` when posting a plain PR comment
|
|
|
|
|
|
|
|
|
|
Do not use `tea` for Gitea PR review unless the user explicitly requests it or MCP cannot provide the needed data. Local CLI usage such as `git diff`, `git worktree`, and test commands remains acceptable when it materially improves local validation.
|
|
|
|
|
|
|
|
|
|
## Comment Template
|
|
|
|
|
|
|
|
|
|
Use this structure when posting a review result:
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
PASS
|
|
|
|
|
|
|
|
|
|
No blocking issues found in the latest update.
|
|
|
|
|
|
|
|
|
|
Validation:
|
|
|
|
|
- <command 1>
|
|
|
|
|
- <command 2>
|
|
|
|
|
|
|
|
|
|
Non-blocking note:
|
|
|
|
|
- <optional note>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
```text
|
|
|
|
|
FAIL
|
|
|
|
|
|
|
|
|
|
1. [High] <blocking issue with path:line and impact>
|
|
|
|
|
2. [Medium] <blocking issue with path:line and impact>
|
|
|
|
|
|
|
|
|
|
Validation:
|
|
|
|
|
- <command 1>
|
|
|
|
|
- <command 2>
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
When acting as a reviewer and the user asks to approve/reject or otherwise post the result, also submit the matching official review state:
|
|
|
|
|
- `PASS` -> `APPROVED`
|
|
|
|
|
- `FAIL` -> `REQUEST_CHANGES`
|
|
|
|
|
- neutral note only -> `COMMENT`
|
|
|
|
|
|
|
|
|
|
When responding as the PR author rather than reviewer, do not use `PASS`/`FAIL`; write a concise author response that explains what feedback was addressed and which validation ran.
|
|
|
|
|
|
|
|
|
|
Do not add filler. Keep the review specific, technical, and actionable.
|
