respond-to-pr-comments-in-blocklist

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: respond-to-pr-comments-in-blocklist
description: Interactively walk a user through PR review comments one at a time, collect a per-comment decision, then post agent-authored replies on GitHub and resolve the review threads once the user approves a preview. Use only when the user wants to reply to or resolve review threads on GitHub. Skip when the user only wants comments fetched or displayed (use `pr-comments`), or only wants the code changes made without posting anything back to GitHub.
---

# Respond to PR comments in blocklist

Use this skill to respond to PR comments on the current branch. If comments are already visible in the conversation, typically from the built-in `/pr-comments` skill, continue from that context. If comments are not already visible, fetch and display them first, then guide the user through each actionable comment, collect an explicit decision, make requested code changes, and only then ask for approval before posting GitHub replies or resolving review threads.

## When not to use this skill

Skip this skill when the user only wants PR comments fetched or displayed (use `pr-comments` instead) or only wants the underlying code changes made, with no intent to post replies or resolve threads on GitHub. Read this skill only once the user has confirmed they want replies posted or threads resolved.

## Preconditions

- Work in the repository checkout for the PR branch.
- Do not refetch comments unless the loaded context is missing essential fields such as comment body, author, URL, path, or line metadata.
- Do not post GitHub replies, submit reviews, or resolve threads until the final preview is approved by the user.

If no PR comments are present in context, fetch and display them before continuing. Prefer invoking the built-in `/pr-comments` workflow when available. Otherwise use the equivalent GitHub CLI fallback: identify the current PR, fetch PR-level comments, review comments, and review bodies, then display them with `insert_code_review_comments`. After displaying fetched comments, ask the user whether to continue with this response workflow before making changes.

## Comment filtering

Before asking for response mode, filter the loaded comments down to actionable comments that still need the user's attention.

Skip these comments without asking the user about them:

- Automated PR-level overview or status comments from Warp/Oz/code-review bots, especially comments with no attached file location that summarize review status, check progress, or say no code change is requested.
- Comments that have already been responded to by the current GitHub user.

To identify the current GitHub user, prefer:

```sh
GH_PAGER="" gh api user --jq .login
```

For review threads, use `reply_metadata.parent_comment_id`, thread metadata, resolution state, and comment ordering from the loaded context when available. Skip the original comment and thread only when the thread is already resolved or when the latest relevant reply in that thread was authored by the current GitHub user. If a reviewer added a newer follow-up after the current user's reply, keep the thread in the walkthrough. For PR-level comments without explicit thread metadata, skip only when the loaded context clearly shows a current-user response to that specific comment, such as a direct reply, quote, link, or immediately following response that references it.

If an automated or already-answered comment is skipped, keep a short internal skipped list with the comment URL and reason. Do not create decision records for skipped comments, do not include them in the per-comment walkthrough, and do not include them in the final GitHub reply/resolution preview except as a brief skipped-count summary.

When unsure whether a comment is automated, already answered, or still actionable, keep it in the walkthrough rather than skipping it.

## Ask User Question requirements

Every `ask_user_question` call in this skill must include an `Other...` option that use