Respond To PR Comments In Blocklist

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:

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 uses the tool's freeform other field. Use that option to let the user enter a custom mode, response, rationale, posting instruction, or next step without returning control in normal chat solely to collect custom text.

Initial mode selection

Before discussing individual comments, call ask_user_question with exactly one mode question:

• Respond one-by-one
• Collect all decisions, then address in a batch
• Other...

Use the selected mode for the rest of the workflow.

One-by-one mode

For each comment, collect the user's decision and immediately perform any requested code change before moving to the next comment. After each change, keep a note of:

• the comment being addressed
• what code or documentation changed
• what validation was run or still needs to run
• the draft GitHub reply and whether the thread should be resolved

Batch mode

For each comment, interactively collect the user's decision without editing code yet. Batch mode does not batch or skip the information-gathering phase: the user must still be able to ask for more context, request an explanation, inspect the referenced code, or provide a custom approach for any individual comment before deciding. After all comments have a decision, apply the requested code changes in one batch, then validate and prepare the final GitHub reply preview.

Per-comment walkthrough

Process comments in the order they were displayed. For each comment:

1. Restate the relevant context briefly:

• author
• file and line or PR-level location
• a clickable file reference formatted as path:line for single-line comments or path:start-end for ranged comments when location metadata is available
• a concise summary of the comment
• any obvious code context needed to understand it

1. If the fix is not obvious from the loaded context, inspect the relevant files before presenting options.
2. Call ask_user_question with options tailored to the specific comment.

When a comment is attached to code, print the file reference before asking the question so the user can quickly open the relevant section. Use repository-relative paths, for example src/lib.rs:42 or src/lib.rs:40-48. For PR-level comments with no file location, state that there is no attached code location.

Always include options with these meanings:

• Apply the agent's recommended fix for this comment.
• Explain what this comment means before deciding.
• Acknowledge the comment but do not make code changes.
• Other...

Use the Other... option's freeform field for custom responses or approaches. Do not return control to the user in normal chat solely to collect custom freeform text.

When the user selects "explain", provide concise context about the comment, why the reviewer likely raised it, and what tradeoffs are involved. Then ask about the same comment again with updated options; do not skip the decision.

This explanation loop applies in both one-by-one mode and batch mode. In batch mode, only the eventual code edits and GitHub comment updates are deferred; per-comment information gathering remains interactive.

When the user selects "acknowledge without changes", give them the option to provide more information about why no code changes are being made. Preserve any provided rationale for the final GitHub reply draft.

Decision records

Maintain an internal decision record for every comment. Each record should include:

• comment identifier or URL
• comment type: review-thread comment, thread reply, PR-level comment, or review body
• selected disposition: fix, explain-then-fix, acknowledge-without-changes, custom, or no-action
• planned code change, if any
• validation needed
• draft reply body
• whether to resolve the review thread

For draft replies, be concise and concrete. Prefer replies that say what changed or why the comment is intentionally not addressed. Prefix every draft reply that may be posted to GitHub with [Warp Agent] so reviewers can clearly see the response was agent-authored. If the fix has already been committed and pushed before replies are posted, include a link to the commit that resolved the comment so the response is auditable.

Applying fixes

Follow the user's selected mode:

• In one-by-one mode, edit and validate each accepted fix before continuing to the next comment.
• In batch mode, wait until all comment decisions are collected, then make all accepted edits together.

When making changes: