pr-review-resolution

Skill detail with category, linked agents, and source metadata.

pr-review-resolution

Fetches CI/Copilot review comments from a PR, triages them by severity, implements fixes (with a test gate for code changes), commits, pushes, replies to every inline comment with a resolution summary, and resolves all addressed threads. Use whenever a developer asks to address PR review comments, fix Copilot feedback, or respond to CI review findings.

Category: code-generation Used by 1 agents

Source: .github/skills/code-generation/pr-review-resolution/SKILL.md

Used By Agents

5 - DELIVER - Code Review Agent

Preview

View source preview (first 3000 chars)


# PR Review Resolution Workflow

Invoke this skill when the user wants to address review comments on an open GitHub PR.

**Trigger phrases:**
- "fix PR comments"
- "address the review"
- "respond to Copilot review"
- "see what reviews need to be fixed"

Refer to the `github-interactions` skill for the Windows Credential Manager token extraction helper, header setup, and `gh` CLI patterns. Set `$BASE` and `$headers` from that skill before running any REST API calls here.

---

## Step 1 — Fetch Reviews and Comments

```powershell
$BASE = "https://api.github.com/repos/{OWNER}/{REPO}"
$PR   = {PR_NUMBER}   # replace with the actual PR number

# 1a. Formal reviews (overview body)
$reviews = Invoke-RestMethod -Uri "$BASE/pulls/$PR/reviews" -Headers $headers

# 1b. Inline code comments (the actionable ones)
$comments = Invoke-RestMethod -Uri "$BASE/pulls/$PR/comments?per_page=100" -Headers $headers

# 1c. Issue-level comments (general PR discussion)
$issueComments = Invoke-RestMethod -Uri "$BASE/issues/$PR/comments?per_page=100" -Headers $headers
```

Or via `gh` CLI:

```bash
gh pr view {PR_NUMBER} --comments
gh api "repos/{OWNER}/{REPO}/pulls/{PR_NUMBER}/comments?per_page=100"
```

Present the count to the user before triaging:
> "Found X inline comments from Y reviewers. Triaging now..."

---

## Step 2 — Triage into a Priority Table

Present findings in three tiers. Use plain English — avoid jargon.

### Triage rules

| Tier | Criteria | Label |
|---|---|---|
| High / Must Fix | Lint error, TypeScript or compile error, ESLint rule violation, broken import, CI will fail, security issue | Fix before merge |
| Medium / Should Fix | Misleading comment, wrong documentation, dead code, minor anti-pattern, performance suggestion | Fix in this PR if possible |
| Low / Nitpick | Style preference, optional rename, cosmetic suggestion | Nice to have, can skip |

### Output format (always use this table)

```
### [HIGH] Must Fix

| # | File | What is wrong | Why it matters |
|---|------|---------------|----------------|
| 1 | TaskRouter.ts L47 | Unsafe type cast with `as any` | Lint rule violation — CI will fail |
| 2 | TaskRouter.ts L62 | Same unsafe cast, second occurrence | Same failure, two locations |

### [MEDIUM] Should Fix

| # | File | What is wrong | Why it matters |
|---|------|---------------|----------------|
| 3 | routeUtils.ts L29 | JSDoc describes wrong behavior | Misleads future developers, though no runtime bug |

### [LOW] Nitpick

(none in this review)
```

Always end the triage with:
> "Which items would you like me to fix? (e.g., 'all', 'high only', '1 and 3')"

---

## Step 3 — Classify Each Fix

Before writing any code, classify every item as:

| Type | Definition | Gate before commit |
|---|---|---|
| Code change | Any production code modification with logic or typing impact | MUST ask user to run local tests first |
| Doc/comment only | Only comments, documentation strings, or string literals with no runtime effect | Proceed directl