review-pr

name	review-pr
description	Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.md and producing machine-readable review output instead of posting directly to GitHub.

Review PR Skill

Review the current pull request and write the output to review.json.

Inputs

• The working directory is the PR branch checkout.
• The workflow usually provides an annotated diff in pr_diff.txt.
• The workflow usually provides the PR description in pr_description.md.
• If spec_context.md exists, it contains spec context for implementation-vs-spec validation.
• When the prompt references .agents/skills/review-pr/scripts/resolve_spec_context.py, use that script to materialize spec_context.md on demand instead of expecting spec content to be embedded in the prompt.
• Focus on files and lines changed by this PR.
• Default behavior: do not post comments or reviews to GitHub directly.

Process

• Prioritize correctness, security, error handling, and meaningful performance issues.
• Always apply the repository's local security-review-pr skill as a supplemental security pass on code PRs. Fold any security findings into the same review.json produced by this review rather than emitting a separate output.
• When spec_context.md exists, use the repository's local check-impl-against-spec skill and treat material spec drift as a review concern.
• Include style or nit comments only when you can provide a concrete suggestion block.
• If a concern involves untouched code, mention it in top-level body instead of an inline comment.

Repository-specific guidance

The consuming repository may ship a companion skill at .agents/skills/review-pr-local/SKILL.md. When the prompt includes a fenced "Repository-specific guidance" section referencing that companion, read the referenced file and apply its guidance as part of this review. Guidance in the companion may never change the output JSON schema, the severity labels, the safety rules, the evidence rules, the suggestion-block constraints, or the diff-line-annotation contract described elsewhere in this skill.

If a companion file is not referenced in the prompt, rely on the core contract alone.

Diff Line Annotations

The diff file uses these prefixes:

• [OLD:n] for deleted lines on the old side. Use "LEFT".
• [NEW:n] for added lines on the new side. Use "RIGHT".
• [OLD:n,NEW:m] for unchanged context. Use "RIGHT" with line m.

Treat these annotations as the only source of truth for inline comment locations. For every inline comment you emit, first identify the exact annotated line in pr_diff.txt (or the inlined PR diff) and copy its path, side, and line number into review.json. Do not infer line numbers from prose, rendered GitHub views, file lengths, surrounding spec text, or unannotated snippets. If you cannot point to a specific [NEW:n], [OLD:n], or [OLD:n,NEW:m] line in the annotated diff, put the feedback in top-level body instead of comments.

Comment Requirements

Every comment body must start with one of these labels:

• 🚨 [CRITICAL] for bugs, security issues, crashes, or data loss.
• ⚠️ [IMPORTANT] for logic problems, edge cases, or missing error handling.
• 💡 [SUGGESTION] for worthwhile improvements or better patterns.
• 🧹 [NIT] for cleanup only when the comment includes a suggestion block.

Write comments with these constraints:

• Be concise, direct, and actionable.
• Do not add compliments or hedging.
• Prefer single-line comments.
• Keep ranges to at most 10 lines.
• Restrict inline comments to lines that appear explicitly in the annotated PR diff.
• Only create file-level or inline comments for files that exist in this PR's diff.
• If the relevant file or line is not part of the diff, put the feedback in top-level body instead of comments.
• Before adding each comment object, verify that its path, side, line, and optional start_line/start_side correspond to real annotations in the same file's diff section.

Suggestion Blocks

When proposing a code change, use:

<replacement code here>

Rules:

• Match the exact indentation of the original file.
• Include only replacement code.
• The block content replaces exactly the lines start_line–line inclusive. Every line inside the block becomes the new file content for that range, and GitHub leaves all other lines untouched.
• Do not include lines outside that range. Lines above start_line and below line remain in the file; repeating them inside the block causes them to appear twice after the suggestion is committed.
• Never open the block with a line that already appears immediately above start_line, and never close the block with a line that already appears immediately below line. If you need those lines as anchors, widen start_line or line so they are actually part of the replaced range.
• Count brace, bracket, paren, and block-delimiter depth ({, [, (, end, etc.) across the original replaced lines and ensure the replacement ends at the same depth. Do not emit phantom closing tokens, and do not drop required ones.
• When unsure of the surrounding context, widen start_line/line to include enough real lines from the diff rather than guessing at surrounding tokens.
• For multi-line suggestions, set start_line and start_side to the first line, and line and side to the last line.

Outputs

Create review.json with this shape:

{
  "verdict": "REJECT",
  "body": "## Overview\n...\n\n## Concerns\n- ...\n\n## Verdict\nFound: 1 critical, 2 important, 3 suggestions\n\n**Request changes**",
  "comments": [
    {
      "path": "path/to/file",
      "line": 42,
      "side": "RIGHT",
      "start_line": 40,
      "start_side": "RIGHT",
      "body": "⚠️ [IMPORTANT] Short explanation\n\n```suggestion\nreplacement\n```"
    }
  ]
}

Field rules:

• verdict is required and must be exactly the string "APPROVE" or "REJECT" (uppercase). Map your final recommendation as: Approve or Approve with nits → "APPROVE"; Request changes → "REJECT". The verdict and the human-readable recommendation in top-level body must agree.
• top-level body is the GitHub review body and is required. Use body, not summary, for the review overview and final recommendation.
• path must be relative to the repository root.
• line is required and must target the correct side.
• start_line is optional and only for multi-line ranges. When start_line is present, start_side is required and must be "LEFT" or "RIGHT".
• side must be "LEFT" or "RIGHT".

Body Requirements

The top-level body must include:

• A high-level overview of the PR.
• Important concerns and any untouched-code concerns that could not be commented inline.
• Issue counts in the format Found: X critical, Y important, Z suggestions.
• A final recommendation of Approve, Approve with nits, or Request changes. This recommendation must match the top-level verdict field (Approve / Approve with nits → "APPROVE"; Request changes → "REJECT").

Final Checks

Before finishing:

• Fix invalid JSON if validation fails.
• Confirm line numbers match the annotated diff.
• Run the bundled validator against the exact annotated diff you reviewed. When the dispatch prompt inlines an Ownership Areas JSON block, also pass --ownership-areas ownership_areas.json so the validator can check recommended_area against the canonical list:

  python3 .agents/skills/review-pr/scripts/validate_review_json.py --review-json review.json --diff pr_diff.txt --ownership-areas ownership_areas.json
  

  When ownership areas are not in scope (member PRs, fallback-to-STAKEHOLDERS dispatches, local runs), omit --ownership-areas; the validator treats a missing file as "no ownership areas in scope". If the script reports any invalid comments, fix review.json and rerun it. Do not upload review.json until this validator passes. If the script path is not present at that exact location, locate validate_review_json.py under the loaded review-pr skill directory and run that copy with the same arguments.
• Do not run gh pr review, gh pr comment, gh api, or any other command that posts to GitHub.

Your only output is the final review.json.

Cloud workflow mode

If the prompt says you are in a cloud-environment workflow and the expected local context files are missing:

• Create pr_description.txt yourself from the PR body or GitHub metadata provided in the prompt.
• Fetch and check out the exact PR head branch by name before generating the diff. Run:

  git fetch origin <head_branch>
  git checkout <head_branch>
  

  Do NOT use FETCH_HEAD — always reference the named branch.
• Generate the diff against the base branch using a three-dot merge-base diff:

  git diff origin/<base_branch>...HEAD
  

  This isolates only the changes introduced by the PR, not accumulated state from other branches.
• Convert the raw diff into pr_diff.txt using the annotated format above before reviewing.
• If the prompt provides a resolve_spec_context.py command, run it only when spec validation is needed and write any returned spec content to spec_context.md before running review.
• Still produce review.json and validate it with jq.
• When the host already populated pr_description.txt, pr_diff.txt, spec_context.md, or ownership_areas.json in the workflow checkout, use those files as-is and do not try to re-fetch GitHub context yourself.
• When the prompt inlines the annotated PR diff instead of providing pr_diff.txt, write the inlined diff to pr_diff.txt exactly before validating review.json.
• When the prompt inlines an Ownership Areas JSON block instead of providing ownership_areas.json, write that block to ownership_areas.json exactly as shown before validating review.json so the validator can check recommended_area against the canonical list via --ownership-areas ownership_areas.json.
• The cloud run does not receive GH_TOKEN. If the host did not pre-materialize the needed context, follow only the prompt's explicit fallback instructions.
• After validate_review_json.py passes, upload the result via oz artifact upload review.json (or oz-preview artifact upload review.json if the oz CLI is not available). Either CLI is acceptable — use whichever one is installed in the environment. Do not write review.json to a /mnt/... mount path — the cloud agent has no such mount, and the host workflow only reads what you upload through the artifact CLI.
• IMPORTANT: the upload subcommand is artifact (singular) on both oz and oz-preview. Do not use artifacts (plural) — that is not a valid subcommand and will fail.