메뉴
Review a GitHub PR by loading PR context, running or reusing the core request-review findings, drafting comments for approval, and posting only after explicit go-ahead.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Turn a repo-local spec, rollout doc, design note, or implementation plan into a compact /goal prompt. Use when the user wants to run Codex /goal from an existing spec-first workflow and needs the goal to preserve scope, non-goals, validations, and local constraints.
Evaluate a repository's first-rung readiness for high-quality AI code contributions and produce concrete, copy-pasteable file changes that make the repo AI-ready. Use when asked to audit AI contribution quality, diagnose why AI PRs are low quality, prepare a repo for AI-assisted engineering, or move a repo from no harness toward a basic v0.5 contribution harness.
Bootstrap a small, deterministic repo-local AI harness by adding only the docs, skills, or checks that have concrete repo-specific content. Use when a repo already has basic AI contribution readiness and the user wants continuous harness improvement without placeholder process.
Evaluate a real AI-assisted work session against the repo-local harness, classify reusable misses, and update or propose updates to docs, skills, scripts, MCP/tooling, or sensors. Use after substantial work, review feedback, failed validation, or human correction in a repo with an AI harness.
Investigate established Pulumi-vs-Terraform parity gaps in bridged providers by creating or refining bridge cross-tests, after routing has already determined that bridge parity work is the next step, or when the user explicitly asks for that help. Use when the agent already knows that Pulumi has the problem and Terraform does not, and the next step is to capture, narrow, and explain that parity gap inside pulumi-terraform-bridge without debating alternate harnesses.
Run Claude Code as a chat-only reviewer for a local diff or branch, including adversarial pressure-testing when requested. Use when the user explicitly wants a Claude second opinion without posting GitHub comments.
| name | review-pr |
| description | Review a GitHub PR by loading PR context, running or reusing the core request-review findings, drafting comments for approval, and posting only after explicit go-ahead. |
Use this skill for GitHub PR review IO.
review-pr does not define the technical review lens. Use request-review for
the actual review, then turn approved findings into GitHub review comments.
Nothing posts without explicit approval.
Use request-review directly when the user only wants local technical analysis
and no draft GitHub comments.
Accept PR input as:
Use gh for GitHub work:
gh pr view <number> --json title,body,author,baseRefName,headRefName,headRefOid,files,additions,deletions,commits,reviewDecision
gh pr diff <number>
gh pr checks <number>
PR context rules:
baseRefName, headRefName, and headRefOid as the source of truth.
Do not assume origin/master, origin/main, or a local origin/pr-* ref.git diff, fetch the exact base/head refs first and
verify them with git rev-parse --verify before diffing.gh pr checks may exit non-zero when checks are failing or still pending.
Read the returned CI state before treating that exit code as a workflow
problem.gh pr diff does not support path filtering. For file-bounded review, fetch
the PR refs locally and run a verified git diff -- <paths> instead.gh pr diff on this local CLI supports --name-only but not
--name-status. If you need status letters, fetch verified PR refs and use
git diff --name-status <base>...<head> locally.gh pr view --json fields. For review comments, reviews,
or thread metadata, use gh api on the pull-request endpoints instead of
guessing extra JSON field names.Summarize the PR briefly:
Keep setup read-only. Do not rebase, merge, reset, cherry-pick, or otherwise rewrite local history unless the user explicitly asks for branch surgery.
Use the core review flow for technical findings.
request-review against the PR diff and relevant
local context.repo_instructions_reviewer lane when applicable instructions
exist.Do not duplicate the generic review rubric here. request-review owns reviewer
lens selection and findings synthesis.
Convert only actionable findings into draft GitHub comments.
For each draft, include:
Prefer inline review comments for specific findings. The overall review body should be brief and high-level; do not list all specific comments in the body. Use body-only comments only for feedback that cannot be anchored to a changed line.
Use gh pr diff to confirm that each inline comment can be anchored to a
changed line:
side: "RIGHT" for added or changed lines in the PRside: "LEFT" for deleted or base-side linesstart_line and start_side only for multi-line commentsPrefer fewer high-quality comments. Skip praise, non-issues, and correctness narration unless they belong in a short overall review body.
Use blocking only for genuine bugs, security issues, data loss risks, serious regressions, or significant maintainability hazards.
Show the draft review before posting:
## Draft Review: PR #<number>
Overall assessment: <APPROVE / COMMENT / REQUEST CHANGES>
Review body: <brief high-level summary>
### Blocking
- `<file>:<line>`: <draft comment>
### Suggestions
- `<file>:<line>`: <draft comment>
### Questions
- `<file>:<line>`: <draft comment>
### Nits
- `<file>:<line>`: <draft comment>
### Body-only Comments
- <draft comment that cannot be anchored to a changed line>
Ask for approval with clear options:
Post only after explicit approval.
Use gh pr review only when there are no inline comments to submit:
gh pr review <number> --approve --body "<summary>"
gh pr review <number> --comment --body "<summary>"
gh pr review <number> --request-changes --body "<summary>"
Use the GitHub review API for inline comments so all approved comments are batched into a single review. Specific findings should be posted as inline review comments on the relevant changed lines; the review body should stay brief.
Create a review payload:
PR=<number>
HEAD_SHA="$(gh pr view "$PR" --json headRefOid --jq .headRefOid)"
jq -n \
--arg commit_id "$HEAD_SHA" \
--arg body "Thanks. I left a couple of inline comments." \
'{
commit_id: $commit_id,
event: "REQUEST_CHANGES",
body: $body,
comments: [
{
path: "pkg/example.go",
line: 42,
side: "RIGHT",
body: "This can return nil here, which would panic below. Can we handle the empty result explicitly?"
},
{
path: "pkg/example_test.go",
line: 88,
side: "RIGHT",
body: "This test only checks that the call succeeds. Can we assert the behavior that regressed?"
}
]
}' > /tmp/review.json
Submit the review:
gh api \
-X POST \
repos/{owner}/{repo}/pulls/$PR/reviews \
--input /tmp/review.json
Use event: "APPROVE", event: "COMMENT", or event: "REQUEST_CHANGES" to
match the approved overall assessment. Use REQUEST_CHANGES when any blocking
finding is being posted.
After posting, report:
If nothing was posted, say so plainly.