Pr Address Feedback

Let's look at each review comment on this pull request one-by-one and make a plan to either take action on the feedback or reply with reasoning.

PR target: use the PR number/URL I passed with this command, if any; otherwise the PR for the current branch.

You are in plan mode. Until I approve the final plan, do NOT edit files, commit, push, resolve threads, or post anything to GitHub. Read-only commands (gh, git log/diff/show, viewing files) are fine.

The PR may live on github.com or on another GitHub host (e.g. GitHub Enterprise Server). Take the host from the PR's url and pass --hostname <host> to every gh api call (or export GH_HOST=<host> once). gh api defaults to github.com even inside an Enterprise Server checkout.

1. Gather the feedback

• Resolve the PR: use the target above if provided (number, URL, or owner/repo#N); otherwise use the PR for the current branch (gh pr view --json number,url,headRefName,headRefOid,baseRefName,headRepository,headRepositoryOwner). If none is found, ask me.

• Fetch all review threads with GraphQL (paginate), including for each thread: id, isResolved, isOutdated, path, line, startLine, originalLine, diffSide, and every comment's databaseId, url, author.login, body, diffHunk, createdAt.

• Also fetch top-level review bodies (reviews with non-empty body) and general PR conversation comments, since those can contain feedback too.

• Skip resolved threads and threads where I (the PR author) had the last word unless they still look unaddressed. Mention outdated threads but check whether the feedback still applies to current code.

• git fetch <base remote> refs/pull/<n>/head first and check that the fetched SHA matches the PR's headRefOid. Read code from that SHA (<headSha> below), not from origin/<headRef>, which may not exist for PRs from forks. If my local branch is behind it, say so.

• Order the items so the review reads coherently, not just by position in the diff:

  • Before ordering, read every item and spot dependencies and patterns. Some comments point back to others ("same as above", "ditto", "as I mentioned on foo.go", "same issue here"). Others repeat the same kind of feedback (e.g. the same naming nit or missing error check in several places).

  • Put the comment that sets up a pattern first: the one that explains it fully, usually the earliest-written. Then put every comment that refers back to it or repeats it right after it, so you only have to understand the pattern once.

  • Order the rest by file and line so related feedback stays together. Break ties by comment createdAt.

• In a visible message (not just thinking), tell me up front how many items there are. Give a one-line index in the order you'll present them (N. @reviewer path:line — gist). Mark follow-ons, e.g. (same pattern as #2). Note any skipped or already-addressed threads. Then go through them one at a time in that order.

2. Present each item (one per turn)

CRITICAL — the item must be visible before you ask. I cannot see your thinking/reasoning, tool output, or SQL rows. The only things I see are your assistant message text and the short ask_user prompt. So for every item you MUST write the full item block below as normal assistant message text in the same response, immediately before the ask_user call. Never call ask_user for an item until that block has been written out. Summarizing the item only in your thinking does not count.

This block is exempt from any general brevity / word-limit guidance — completeness here matters more than being short. Do not paraphrase the comment or skip the diff to save space.

Write each item using exactly this template (fill every section; write "n/a" rather than dropping one):

---
### Item N of M — @reviewer · [`path:line`](COMMENT_URL)
Thread: [open on GitHub](COMMENT_URL) · status: open | outdated

**Feedback**
> full text of the first comment, verbatim (keep its code blocks / suggestions)
>
> **@replier:** full text of each reply, in order

**Diff context** (from the review's `diffHunk`, trimmed to ~10 lines around the commented line)
```diff
...
```

**Current code** — `path` Lstart–Lend (always include; this is what I'm deciding against)
```go
214 | ...
```

**Evidence / related context**
- `other/file.go:123` — why it matters (with a short snippet if it helps)
- Related comment: [@who on path:line](url) — how it interacts with this one

**Assessment**: is the reviewer right? What's the trade-off?

**Recommendation**: **Act** — exact files + short sketch of the change · or · **Reply** — draft reply in my voice, short and friendly:
> draft reply text

Rules for the block:

• COMMENT_URL is the comment's url field (e.g. https://github.com/o/r/pull/123#discussion_r456; the host may differ, e.g. on GitHub Enterprise Server). Never omit it.

• Quote the feedback verbatim from the fetched body, not from memory. For top-level review / conversation feedback, use that comment's URL and replace "Diff context" with "n/a (not a line comment)", but still show the relevant current code.

• Get current code with line numbers from the PR head (e.g. git show <headSha>:path | sed -n 'A,Bp' | nl -ba -v A or gh api repos/<headOwner>/<headRepo>/contents/path?ref=<headSha> -H 'Accept: application/vnd.github.raw') — don't rely on a local branch that may be stale. Use the file's language for the code fence.

• Every claim in Assessment should be backed by something in "Evidence" (a path:line + snippet, a commit, a doc link, a related comment). If you investigated something while thinking, put the finding there so I can see it.

Then call ask_user to get my decision:

• Make the question self-contained enough to identify the comment even if I only see the prompt: Item N of M — @reviewer on path:line: "<first ~15 words of the comment>…" How should I handle it?

• Offer choices like: Act as proposed (Recommended), Reply with reasoning, Act differently, Skip / defer. Put your recommendation first.

• For an item that follows an earlier pattern, say which earlier item it refers to and what I decided there, in both the item block (under Evidence) and the prompt. Offer Same as item K (Recommended) as the first choice when that decision clearly applies.

• If I pick a freeform option, work it through with me before moving on.

• If I ask to see an item again, re-print its full block (re-fetch if needed) rather than summarizing.

Keep a running record of each item and decision (for example in the session SQL database: comment id, url, path, line, decision, planned change, reply text) so nothing gets lost and items can be re-rendered.

3. Build the resolution plan

When every item is decided, write a single plan that lists, for each item: the comment link, the decision, the code change (if acting), the exact reply text to post (if replying, or to confirm an action), and whether the thread will be resolved (see defaults in §4). End the plan with the list of reviewers whose review will be re-requested. Then call exit_plan_mode so I can review and approve it.

4. Rules for carrying out the approved plan

• Before any edits, make sure the working tree is a clean checkout of the PR head: gh pr checkout <n> (which also sets the push destination for PRs from forks), then check that HEAD matches the verified <headSha>. If it doesn't, or the tree is dirty, stop and ask me.

• Make the code changes as small, focused commits. Where it makes sense, use one commit per feedback item so replies can point to a specific commit.

• Push before you reply. Any reply that mentions a commit SHA must only be posted after that commit is on GitHub. Otherwise the SHA won't render as a link. In order:

  1. Commit, then git push.

  2. Re-read the PR's headRefOid (gh pr view <n> --json headRefOid) and confirm each referenced commit is reachable from it: git fetch <base remote> refs/pull/<n>/head, then git merge-base --is-ancestor <sha> FETCH_HEAD. If it isn't, stop and fix that before posting.

  3. Only then post the replies. Use the full 40-character SHA (or a https://{host}/{owner}/{repo}/pull/{n}/commits/{sha} link, using the PR's host) so GitHub links it.

• Reply inside the existing thread (gh api repos/{owner}/{repo}/pulls/{n}/comments/{comment_id}/replies -f body=...), not as a new top-level comment. For top-level review or conversation feedback, post one PR comment that quotes what it's answering.

• Post the reply text I approved. Changing only the SHAs is fine.

• Resolve only threads the plan marks for resolution, and only after their reply is posted. Defaults (I can override per item in the plan):

  • Act items: resolve.

  • Reply with reasoning items: leave open so the reviewer can respond.

  • Skip / defer items: leave open, don't reply.

  • Top-level review / conversation feedback has no thread to resolve; skip.

  • For threads marked for resolution, prefer the reply_and_resolve_review_thread tool when available (only some Copilot surfaces provide it; pass the thread id + root comment databaseId), which replies and resolves in one step. Otherwise post the reply with gh api as above, then resolve via GraphQL: gh api graphql -f query='mutation($id:ID!){resolveReviewThread(input:{threadId:$id}){thread{isResolved}}}' -f id=<thread id>.

  • For threads staying open, use a reply-only call (reply_to_review_thread if available, otherwise the gh api …/replies call above). Never use the reply-and-resolve tool for them.

• Re-request review last. After all commits are pushed, replies posted, and threads resolved, re-request review from every human reviewer whose feedback was addressed in this pass (excluding me and bot accounts): gh api -X POST repos/{owner}/{repo}/pulls/{n}/requested_reviewers -f 'reviewers[]=<login>' (repeat reviewers[] for each). Skip anyone who already has a pending review request. If a call fails, report it rather than retrying blindly.

• At the end, give me a short summary with links to each reply you posted, each commit you pushed, which threads were resolved, and who was re-requested.