Reads and addresses comments from humans and other agents on github

1. Fetch the open PR for the current branch. If no PR exists, notify the human and stop. If multiple PRs exist, ask the human to select one.

2. Fetch all unresolved comments. Separate human comments from bot/automated comments (Copilot, github-actions, etc.).

3. Human comments — assess each:
   • Stale: the issue was already fixed in a later commit — note it, do not add to the implementation plan.
   • Code change needed (nit, low, medium, high severity): add to the implementation plan.
   • Discussion needed (questions, architectural debates): flag for human review rather than acting on them.

   Present this plan to the human — what will be changed, what needs discussion, and what is stale. Wait for explicit approval before proceeding. This is the first approval gate; complete it before moving to step 4.

4. Bot/automated comments (Copilot, github-actions, etc.) — these require explicit human approval before ANY action. Never auto-implement bot suggestions. Skip this step entirely if there are no bot comments. For each bot thread, classify it using the first matching category:
   • Stale: the issue was already fixed in a later commit — recommend resolving without change.
   • Valid code bug: a genuine correctness issue (wrong field name, wrong unit, logic error, not a style or naming preference) — recommend implementing, but wait for approval.
   • Domain/content suggestion: wording, thresholds, naming, business logic — domain experts (vets, PMs, etc.) outrank bots. Flag for human to decide; do NOT implement without explicit approval.
   • Ignorable: misunderstanding of project structure, ticket hierarchy, or context — recommend ignoring.

   Write a markdown triage file to /tmp/{PR_NUMBER}.md (where {PR_NUMBER} is the numeric PR number from the PR URL or gh pr view output). If the file already exists from a prior run, overwrite it entirely. The file MUST contain a table with these columns:

   | Author | Thread ID | File:Line | Summary | Agent Assessment | Decision | |——–|———–|———–|———|——————|———-|

   • Author: the GitHub login of the comment author (bot name, username, etc.)
   • Thread ID: the GitHub review thread ID as output by list-unresolved-threads.sh
   • File:Line: path and line number the comment is anchored to
   • Summary: what the comment is actually saying, in plain English, one sentence
   • Agent Assessment: your classification (Stale / Valid code bug / Domain suggestion / Ignorable) and a one-sentence reason

   • Decision: leave this column blank — the human fills it in. Valid values the human may enter: implement

     ignore

     discuss

     defer

   Tell the human the file path and instruct them to open it, fill in the Decision column, and return it. Do not implement or resolve any bot threads until the human returns the filled-in file. If the human never returns the file or says to skip, proceed without addressing bot comments.

   Once the human returns the filled-in file, act on each thread according to its Decision value:

   • implement: Make the code change. Then reply inside the thread referencing the commit SHA where the fix landed, and resolve the thread.
   • ignore: Reply inside the thread explaining that the suggestion was reviewed and intentionally not adopted (one sentence why). Then resolve the thread.
   • discuss: Reply inside the thread with the agent’s assessment and any relevant context to move the conversation forward. Do not resolve — leave the thread open for human follow-up.
   • defer: Reply inside the thread explaining that the suggestion is valid but being deferred (include a ticket link or note if one exists). Then resolve the thread.

5. Take actions based on human input from both approval gates. For discussion-type comments, post a reply inside the review thread (not as a top-level PR comment) using gh api repos/{owner}/{repo}/pulls/{pull_number}/comments -X POST -f body="..." -f in_reply_to={comment_id}, where {comment_id} is the numeric ID of the original inline comment (from the gh api .../pulls/{pr}/comments response). Never use gh pr comment for thread replies — that posts at the top level.

   Identity disclosure (required on every posted comment): Any comment posted on behalf of the human MUST begin with: _Posted by {your identity} on behalf of @<github-handle>._ (using your identity from CLAUDE.md), then the reply body. Never omit this line.

6. Run /critique to ensure changes are reviewed, committed, and pushed.

7. Attempt to resolve addressed PR comment threads. The gh CLI still has no native resolve command, so use the helper scripts in this skill’s folder:

   # List unresolved threads (tab-separated: id, path:line, author, snippet)
   $HOME/.claude/skills/address-pr-comments/list-unresolved-threads.sh <pr-number|pr-url> [--repo OWNER/REPO]
   
   # Resolve specific threads by ID
   $HOME/.claude/skills/address-pr-comments/resolve-threads.sh <thread-id> [<thread-id>...]
   
   # Or resolve every unresolved thread on a PR
   $HOME/.claude/skills/address-pr-comments/resolve-threads.sh --all <pr-number|pr-url> [--repo OWNER/REPO]
   

   Always use the absolute paths above — these scripts live in $HOME/.claude/skills/, not in the user’s repo. Only resolve threads whose feedback you actually addressed. Skip discussion-type threads that are still waiting on a human reply. Resolution requires triage/write permission on the repo — report any failures to the human.

8. Re-request review from the original commenters if they had requested changes or notify them via a PR comment that their feedback has been addressed. Any notification comment MUST also open with the same identity disclosure described in step 5.
9. After pushing, check CI status using gh pr checks. If any checks are failing, invoke /resolve-ci-failures to investigate and fix them.
10. This skill covers one round of comments. If new comments arrive after this round is complete, the human should invoke this skill again.