thuanle/claw-email
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
3985b9dae3da0f0bc4b956b90f9fa69cab841317
claw-email/.codex/skills/review-pr/SKILL.codex.md
T
thuanleandClaude Opus 4.7 248a5bdbcd docs: add AGENT.md workflow and local skills 
- AGENT.md: role-based issue-driven workflow (PO → Dev → Reviewer)
- CLAUDE.md: points to AGENT.md
- .codex/skills/: validate-issue, do-task, review-pr with phase gates

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-04-28 00:00:41 +07:00

8.4 KiB
Raw Blame History

name, description
name description
review-pr 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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:

PASS

No blocking issues found in the latest update.

Validation:
- <command 1>
- <command 2>

Non-blocking note:
- <optional note>

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.

Reference in New Issue View Git Blame Copy Permalink