New skill: respond-to-pr-feedback — triage PR review comments, apply agreed fixes, reply to threads

Summary

A new skill that closes the loop after /deep-review (or any reviewer): pull the feedback on a PR, triage each comment into decision buckets, get the user's call, apply the agreed fixes, push, and reply to the threads — resolving the clear-cut ones and leaving the debatable ones open. It's the natural counterpart to deep-review (produces feedback) and craft-pr (opens the PR). Today, acting on review feedback is ad-hoc; this standardizes it.

Source detection (GitHub or ADO)

Same dual-source pattern as start-work / craft-pr:

• No arg → the PR for the current branch.
• #N / N / PR URL → that PR.
• GitHub via gh pr view / gh api; ADO via repo_list_pull_request_threads etc. (resolve the repo GUID first, per the ADO MCP standard).

Workflow

1. Resolve the target PR and fetch all unresolved review threads/comments (skip already-resolved/outdated threads and the author's own comments).
2. Triage each comment into one of the five buckets (below), with a one-line rationale and, for fixes, the concrete change proposed.
3. Present the bucketed triage to the user — grouped by bucket, each item showing file:line, the reviewer's point, the proposed decision, and the rationale. The user can ask questions, add context, or override any decision.
4. Batching: when comments are too numerous to decide in one pass, offer to batch — by bucket (default), by file, or by reviewer — and process one batch at a time.
5. Prepare the workspace — worktree by default. Before editing, ensure the fixes happen in a git worktree for the PR's branch:
   • First check whether a worktree for that branch already exists on the machine (git worktree list). If so, reuse it and bring the branch up to date (git fetch + fast-forward / pull) before editing — never create a duplicate.
   • If none exists, create one (e.g. .claude/worktrees/<branch>/), matching the start-work convention.
   • If the session is already in that branch's worktree, this is a no-op.
6. On the user's go-ahead, apply fixes for the agreed items: make the edits, run any relevant tests, commit (new commit, never --amend) and push.
7. Reply to each thread:
   • Buckets 1 & 3 (fixed): reply referencing the fix (commit SHA / "done in <sha>"), and resolve the thread.
   • Bucket 2 (real but deferred): reply acknowledging; offer to file a follow-up issue and link it; leave open or mark won't-fix per the user.
   • Buckets 4 (nit declined) & 5 (spurious/wrong): reply with a brief, respectful rationale; leave open for the reviewer unless the user says resolve.
   • Rule: auto-resolve only where the resolution is unambiguous; leave open anything with room for discussion.
8. Prompt the user to notify reviewers that the comments were addressed, and offer to draft the message.
9. Offer to tear down the worktree created/used for the fixes (keep it if follow-up work is likely; remove it for a clean exit). Never tear down a worktree the skill did not create/enter this session without confirming.

Decision buckets

1. Real defect, worth fixing → fix now.
2. Real defect, but out of scope / too costly → defer; offer to file a follow-up issue.
3. Nit, worth doing → fix now.
4. Nit, not worth doing → decline with a short rationale.
5. Spurious or wrong → reject with explanation.

Design considerations

• Worktree-first, reuse-aware. Fixes are applied in a worktree by default. Always probe git worktree list for an existing worktree on the PR's branch and reuse + update it rather than creating a duplicate (a start-work run on the same card likely already created one). Offer teardown when done; default to keeping if more review rounds are expected.
• Thread-state semantics differ by platform. GitHub resolves review threads via the GraphQL resolveReviewThread mutation; ADO sets a comment thread status (Active / Fixed / WontFix / Closed / ByDesign). Map buckets to the right status per platform (e.g. 1/3 → Fixed, 4 → WontFix/ByDesign, 2/5 → leave Active for discussion unless told otherwise).
• Never resolve a thread that needs discussion — bias toward leaving open when unsure.
• Follow team standards: new commits, not --amend; never push to main; no attribution trailers; anchor any new inline replies on changed lines (per the PR Review Comment Anchoring standard).
• Script vs. inline (per repo CLAUDE.md): the deterministic parts — worktree probe/create/update, fetching threads, posting replies, resolving, commit/push — belong in a committed, smoke-tested script under plugins/<plugin>/scripts/; the triage/bucketing is agent judgment and stays in the command markdown.
• Idempotency / re-runs: don't double-reply to threads already answered in a prior run; track which threads were handled this session.
• Self/bot filter: ignore the PR author's own comments and bot noise unless asked to include them.
• Plumbing reuse: model source-detection, GUID-resolution, and worktree helpers on start-work / craft-pr.

Acceptance criteria

• New skill (suggested name respond-to-pr-feedback) registered in the marketplace and installable.
• Detects the PR from the current branch, or #N / N / URL, on both GitHub and ADO.
• Fetches unresolved review threads and presents a bucketed triage with per-item rationale.
• Supports user override of any decision and Q&A before acting.
• Supports batching (by bucket at minimum) for high comment volume.
• Applies fixes in a worktree by default; reuses + updates an existing worktree for the branch instead of creating a duplicate.
• Commits (new commit) and pushes, honoring push-safety standards.
• Replies to every handled thread; resolves clear-cut ones, leaves debatable ones open.
• Prompts the user to notify reviewers and offers to draft the message.
• Offers to tear down the worktree when done.
• Deterministic logic lives in a tested script; smoke test included.

Out of scope

• Auto-merging the PR after addressing feedback.
• Re-running deep-review (separate skill; the user can chain them).
• Resolving threads without user sign-off.

Start by reading the existing start-work and craft-pr patterns, then inspect the repository's CLAUDE.md and the plugins//scripts/ layout. Trace how source detection, worktree handling, review-thread operations, and smoke tests are currently organized. Done means the new skill is registered and installable, supports GitHub and ADO workflows, and meets the listed acceptance criteria without auto-merging or resolving threads without sign-off.