OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist
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.
npx skills add warpdotdev/common-skills --skill 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.
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.
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.
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:
To identify the current GitHub user, prefer:
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.
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.
Before discussing individual comments, call ask_user_question with exactly one mode question:
Respond one-by-oneCollect all decisions, then address in a batchOther...Use the selected mode for the rest of the workflow.
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:
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.
Process comments in the order they were displayed. For each comment:
path:line for single-line comments or path:start-end for ranged comments when location metadata is availableask_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:
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.
Maintain an internal decision record for every comment. Each record should include:
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.
Follow the user's selected mode:
When making changes:
After all accepted fixes are applied:
git diff to confirm the changes match the collected decisions.Do not commit changes unless the user explicitly asks.
After validation and before posting any GitHub replies or resolving review threads, ask whether the user wants to commit the changes and push them to origin. This order ensures reviewers see pushed code before they see agent-authored comment responses.
If there are no working tree changes from addressing comments, skip the commit/push question and continue to the GitHub reply preview.
Call ask_user_question with options like:
Commit and push these changes to origin before posting repliesDo not commit or push; continue to the GitHub reply previewStop before posting GitHub repliesOther...If the user chooses to commit and push:
git status and the final diff so only intended comment-response changes are included.Other... option for custom commit instructions.origin.Co-Authored-By: Warp Agent <agent@warp.dev> in the commit message (never in a PR description), and do not add it again if the commit already has one.After the commit/push decision is complete, and before posting anything to GitHub, show a preview grouped by comment. For each comment include:
Then call ask_user_question to ask whether to proceed:
Post replies and resolve approved threadsEdit the draft responses firstDo not post anythingOther...If the user chooses to edit, collect their edits, update the preview, and ask for approval again. Do not post until the user selects the approval option.
Use the GitHub CLI only after approval. Clear the pager for all gh commands.
Before running any GitHub CLI command that posts a reply or PR comment, verify the outgoing body begins with [Warp Agent]. If it does not, add the prefix before posting.
For review comments, post replies with the REST API endpoint. Write the reply body to a temporary JSON file and pass it with --input instead of putting the response text directly in command-line arguments:
For PR-level comments or review-body comments that cannot be directly threaded, post a normal PR comment and quote or link to the original comment:
To resolve review threads, use GraphQL. If the thread node ID is not already known, query all review threads for the PR and map loaded comment IDs to their containing thread. Use pagination so threads beyond the first 100 can still be resolved:
Resolve an approved thread with:
If a comment cannot be replied to or resolved through the available metadata, report the limitation and suggest a manual GitHub action instead of guessing.
After posting approved responses and resolving approved threads, summarize:
originREPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"
rm -f "$REPLY_BODY_FILE"GH_PAGER="" gh api graphql --paginate \
-f owner="{owner}" \
-f repo="{repo}" \
-F number={pull_number} \
-f query='
query($owner: String!, $repo: String!, $number: Int!, $endCursor: String) {
repository(owner: $owner, name: $repo) {
pullRequest(number: $number) {
reviewThreads(first: 100, after: $endCursor) {
pageInfo {
hasNextPage
endCursor
}
nodes {
id
isResolved
comments(first: 100) {
nodes {
databaseId
url
}
}
}
}
}
}
}'GH_PAGER="" gh api graphql \
-f threadId="$THREAD_ID" \
-f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { id isResolved } } }'