pr-comments

/pr-comments: triage and close out review threads

Load .claude/harness/profile.md for REPO, LINT_CMD, UNIT_TEST_CMD, E2E_TEST_CMD, BUILD_CMD. Infer from the repo if there is no profile.

The policy this encodes

Stated repeatedly and unchanged: if you agree, fix it and resolve; if you do not agree, justify it and resolve. Nothing is left open and nothing is resolved silently.

Step 1: read the threads, do not guess them

gh api graphql -f owner=<OWNER> -f repo=<REPO> -F pr=<N> -f query='
query($owner:String!,$repo:String!,$pr:Int!){
  repository(owner:$owner,name:$repo){
    pullRequest(number:$pr){
      reviewThreads(first:100){
        nodes{
          id isResolved isOutdated path line
          comments(first:20){nodes{author{login} body createdAt}}
        }
      }
    }
  }
}'

nodes[].id is the PRRT_... thread id both mutations need. Filter to isResolved == false. Read every comment in a thread, not just the first: a reviewer often narrows or answers their own point further down. Separate human reviewers from the CI reviewbot (github-actions); bot threads are still triaged, but a human reviewer's thread is the one with a person's time attached to it.

Also check top-level PR comments, which are not review threads: gh pr view <N> --json comments --jq '.comments[] | {a:.author.login, b:.body}'

Step 2: ground every claim before classifying it

Review feedback is a claim to verify, not an instruction to obey. Agreeing is as much a decision as disagreeing, and it needs the same evidence. Before writing down a verdict, check the claim against the grounds that can settle it: the INSTALLED library source in node_modules at the version this repo pins, the version-matched official docs, real-world discussion of the same failure (the high-signal Stack Overflow thread or upstream issue), and the repo's own gotchas and prior decisions. A reviewer's suggested FIX gets the same treatment as their diagnosis: the diagnosis can be right while the proposed remedy is wrong, so where the mechanism is subtle (effect ordering, layout timing, framework internals), pin it with a failing test before you write the fix, not after.