resolve-review-threads

# Resolving PR Review Threads This is a component skill within the **process-pr-review** workflow. Use this skill after the requested code or documentation changes are already implemented, validated, committed, and pushed. **Part of larger workflow**: See **process-pr-review** for the full end-to-end process. ## Preconditions - The feedback has actually been addressed in the branch. - Validation has been run for the touched scope (`linter all`, tests, or a targeted executable check). - You have the target PR number and unresolved review thread IDs. Do not resolve a thread just because a suggestion exists. Resolve it only when the underlying concern is fixed or intentionally declined with a clear reason. ## Workflow 1. Read the active PR and collect unresolved review threads. 2. Group threads by file and confirm each one is truly addressed. 3. Implement and validate any missing fixes before resolving anything. 4. Resolve the addressed threads. 5. Re-check the PR state if needed. ## Preferred Resolution Path Use GitHub CLI GraphQL to gather thread IDs and resolve threads directly from the terminal. This is reliable for all PRs, including fork-based PRs. > **Fork-based PR limitation**: The VS Code `currentActivePullRequest` and `pullRequestInViewport` > tools do **not** detect PRs opened from a fork (e.g. `contributor:branch` → `upstream/repo`). > In this repository all contributor PRs are fork-based, so the GitHub CLI GraphQL approach > is the reliable primary path. Do not rely on the VS Code active PR tools for thread IDs. Resolve only threads where `isResolved == false` and the fix is already on the branch. ## GitHub CLI GraphQL Command Use GitHub CLI GraphQL when you need to resolve a thread directly from the terminal: ```bash gh api graphql \ -F threadId=THREAD_ID \ -f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { isResolved } } }' ``` Successful output should report `isResolved: true`. ## Batch Pattern Before any batch resolution, confirm every targeted thread already has a reply. Run the `github-review-threads reply-status` command first. Provide the GitHub login that must have replied. A missing reply is an answer, not a failure: the command prints one JSON result on stdout and exits 0 for both outcomes, with `kind` `all_replied` or `missing_reply`, the unresolved threads with their `has_reply` flag, and a `summary`. Branch on `kind`, not on the exit code. Exit code 1 (JSON diagnostic on stderr, empty stdout) means the command could not answer, for example the threads file is unreadable; exit code 2 is a usage error or a terminal on stdout. Only proceed with the batch resolver when `kind` is `all_replied`. This preserves the workflow rule that every resolvable thread is replied to before it is resolved. ```bash set -o pipefail cargo run --package github-review-threads -- reply-status \ --threads-file /tmp/pr_threads_<PR_NUMBER>.json \ --login <AUTHOR_LOGIN> | jq -e '.kind == "all_replied"' > /dev/null ``` With `pipefail` the pipeline succeeds only when `reply-status` exited 0 and `jq -e` found `kind` equal to `all_replied`. A `reply-status` failure (exit 1 or 2) leaves stdout empty, so `jq -e` exits 4 on the empty input and the pipeline fails as well; a `missing_reply` result fails it through `jq -e` exit 1. Only a successful pipeline means every thread was replied to. To list the threads still needing a reply, filter the result: `jq '.threads[] | select(.has_reply | not)'`. For multiple threads, resolve them one by one and check each result: Preferred script usage: ```bash bash scripts/resolve-all-unresolved-threads.sh \ --threads-file /tmp/pr_threads_<PR_NUMBER>.json ``` Use `--dry-run` to preview without mutating GitHub state. ```bash for thread_id in \ THREAD_ID_1 \ THREAD_ID_2 do gh api graphql \ -F threadId="$thread_id" \ -f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { isResolved } } }' done ``` ## Notes - Thread IDs are GraphQL node IDs, not PR numbers or comment IDs. - This resolves the review thread, not the entire review. - If a thread should remain open, leave it open and explain why. - Not every identity may resolve a thread. GitHub only lets the pull request author and users with write access resolve threads. Before resolving, read `viewerCanResolve` (and `viewerCanReply`) on each thread through GraphQL. When `viewerCanResolve` is `false`, still post the reply (a reply needs no write access), leave the thread open, and state in the reply or the PR conversation that the reviewer or PR author is expected to resolve it. Do not switch to a different identity or broaden permissions to work around this unless the maintainer explicitly asks. - If you do not know the thread IDs yet, query the active PR first instead of guessing. ## Completion Checklist - [ ] All targeted threads were verified against the current branch state - [ ] Validation passed before resolution - [ ] Every thread had a reply before any batch resolution (`github-review-threads reply-status` result has `kind` `all_replied`) - [ ] `viewerCanResolve` was `true` for every thread resolved; threads the current identity cannot resolve got a reply and were left open for the reviewer or PR author - [ ] Each resolved mutation returned `isResolved: true` - [ ] Any intentionally unresolved feedback is documented with reasoning