Resolve PR Comments

resolve-pr-comments

Guided workflow to address, reply to, and resolve GitHub PR review threads — one at a time, collaboratively.

Fetch Threads Workflow

Retrieve unresolved review threads from GitHub.

Workflow: Fetch Unresolved Threads

1. Parse the URL provided by the user:
   • PR URL (/pull/123) — process all unresolved threads
   • Comment URL (/pull/123#discussion_r<ID>) — process that single thread
   • If no URL is provided, ask the user before proceeding
2. Extract owner, repo, and pull_number from the URL
3. Use gh CLI to fetch review threads for the PR
4. Filter to threads where isResolved == false
5. If a comment URL was given, further filter to the thread containing the comment with databaseId == <ID>
6. If no unresolved threads exist, report that immediately and stop
7. Validation: Threads fetched; unresolved threads identified; pagination limits noted (>100 threads or >20 comments per thread may be truncated — use comment URL to process in batches)

Per-Thread Resolution Workflow

Work through each unresolved thread collaboratively.

Workflow: Resolve a Thread

For each unresolved thread, display context then work through the steps below. Steps 2–5 apply only when a code change is needed; skip them otherwise.

Display format:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Thread: <path>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Comments:
  [author] createdAt
  > body
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 1 — Analyze and propose

Reads the file at path to get current context, then proposes one of:

• "No code change needed." — explain what reply to send and why no change is required
• "Code change needed." — describe the change; ask: "Should I make this change?"

Wait for user confirmation or adjustment before proceeding.

If no code change: Draft the reply now, then skip to Step 6.

Brief factual explanation, 1–2 sentences. If referencing a specific piece of code, first use search or read to locate the snippet and determine the correct line number(s), then include it as a code block:

```{language inferred from file extension}
// {path}, line {N} — https://github.com/OWNER/REPO/blob/BRANCH/path/to/file#LN
relevant code here...
```

Use the current branch name for the link. Keep the snippet short.

No emoji unless the user uses them first. Wait for user approval before posting.

If code change — continue with Steps 2–7:

Step 2 — Verify branch

Fetch the PR's head ref and confirm the local checkout matches:

gh pr view PULL_NUMBER --repo OWNER/REPO --json headRefName --jq '.headRefName'
git branch --show-current

If the two values differ, stop and tell the user: the local branch does not match the PR branch and they must switch before proceeding.

Step 3 — Implement (if code change)

Make the code change. Do not commit or push yet.

Step 4 — Draft commit message and reply, then confirm

Compose both drafts and present them together for user approval.

Commit message: Use the /commit skill convention ([#ID] Verb message). Derive the issue ID from the branch name (e.g. chore/609-add-skill → #609).

Reply: Vary the phrasing naturally based on the nature of the comment:

• "Good catch, fixed in <sha>."
• "Good point, updated in <sha>."
• "Agreed, refactored in <sha>."
• "Done, updated in <sha>."
• "Fixed in <sha>."
• Avoid repeating the same opener across multiple threads in the same PR.
• Use <sha> as a placeholder since the commit hasn't happened yet.

No emoji unless the user uses them first.

Show both drafts at once:

Commit message: "[#609] Fix wording in skill documentation" Reply: "Good point, updated in <sha>." Does this look good?

Wait for explicit approval (or edits) before proceeding.