Consolidated PR Review Skill

Use this skill to submit code review feedback as a single consolidated GitHub review containing both the summary body and all inline comments.

When to Use

• After completing a code review (use with /code-review, /security-review, /tob-review)
• When you have specific line-by-line feedback to deliver

Instructions

Submit one consolidated review per run using the GitHub API. Do NOT post inline comments individually. Each run produces a new review — nothing is overwritten.

Step 1: Fetch Prior Review Context

Before reviewing, read existing reviews and comments on the PR for context:

# Fetch existing reviews (summaries)
gh api --paginate "repos/$GITHUB_REPOSITORY/pulls/$PR_NUMBER/reviews" --jq '.[] | {user: .user.login, state: .state, body: .body}'

# Fetch inline review comments
gh api --paginate "repos/$GITHUB_REPOSITORY/pulls/$PR_NUMBER/comments" --jq '.[] | {user: .user.login, path: .path, line: .line, body: .body}'

# Fetch general PR discussion comments
gh api --paginate "repos/$GITHUB_REPOSITORY/issues/$PR_NUMBER/comments" --jq '.[] | {user: .user.login, body: .body}'

Use this context to:

• Skip issues already raised — don't re-flag something a prior review already pointed out
• Reference prior discussions — e.g. "As noted in the previous review, ..."
• Flag unresolved issues — if a prior review raised something that still isn't fixed, note it briefly (e.g. "Still unresolved from prior review: ...")
• Avoid contradictions — don't suggest the opposite of what a human reviewer requested

Re-fetch immediately before submitting. Other reviewers may be reviewing concurrently. Critically, the GitHub API does not expose a reviewer's draft/pending comments until they submit — so you can post a review seconds before a concurrent reviewer submits theirs and never have seen their notes. Re-run the fetch right before Step 4, and state the HEAD commit your review is based on in the body (e.g. "Reviewed at <sha>") so readers know the snapshot.

Step 2: Collect All Findings

Complete the full review. Collect:

• Summary — Overall assessment, architecture concerns, non-diff observations
• Inline comments — Specific issues on changed lines (path, line, body)

Step 3: Build Review JSON

Write a JSON file to /tmp/review.json:

{
  "body": "## Review Summary\n\nOverall assessment here.\n\n## Observations Outside This PR\n- `file:line`: description",
  "event": "COMMENT",
  "comments": [
    {
      "path": "src/file.ts",
      "line": 42,
      "body": "Issue description here"
    },
    {
      "path": "src/other.ts",
      "start_line": 10,
      "line": 15,
      "body": "Multi-line comment"
    }
  ]
}

Fields:

• body — Markdown review summary (required)
• event — Always "COMMENT" (never APPROVE or REQUEST_CHANGES)
• comments — Array of inline comment objects (can be empty if no inline findings)
  • path — File path relative to repo root
  • line — Line number in the NEW version of the file
  • start_line + line — For multi-line comments
  • body — Markdown-formatted feedback

Step 4: Submit the Review

gh api "repos/$GITHUB_REPOSITORY/pulls/$PR_NUMBER/reviews" --input /tmp/review.json

The GITHUB_REPOSITORY and PR_NUMBER environment variables are set by the CI workflow.

Limitations

• Inline comments can only target lines in the diff (changed/added lines)
• Comments targeting unchanged lines will cause the API call to fail
• If unsure whether a line is in the diff, put the finding in the summary body instead

Handling Non-Diff Findings

Issues in code NOT changed by the PR go in the review body under a dedicated section:

## Observations Outside This PR

- `src/utils/foo.ts:142`: Pre-existing null check missing
- `src/core/bar.ts:78-82`: Similar pattern to line 45 issue

Feedback Guidelines

Be concise. Group minor style issues together. Never use APPROVE or REQUEST_CHANGES.