Respond To Pr Comments In Blocklist
Work through PR review comments one by one—fetch them if needed, decide how to respond, apply code fixes, and preview GitHub replies before anything is posted.
Overview
Respond to PR comments in blocklist is an agent skill most often used in Ship (also Build when fixes are required) that walks you through PR review comments, applies approved fixes, and previews GitHub replies and resolu
Install
npx skills add https://github.com/warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklistWhat is this skill?
- Reuses `/pr-comments` context when already loaded; otherwise fetches PR, review, and inline comments via GitHub CLI
- Walks each actionable comment with an explicit per-comment user decision before edits or replies
- Applies requested code changes in the repo checkout on the PR branch
- Final preview of GitHub replies and thread resolutions—no posts or resolves until user approves
- Guards against refetching when conversation already has bodies, authors, URLs, paths, and line metadata
Adoption & trust: 271 installs on skills.sh; 18 GitHub stars.
What problem does it solve?
You have open review threads on your PR and need a safe, ordered way to address each comment without your agent posting replies or resolving threads before you agree.
Who is it for?
Solo builders on a feature branch with actionable GitHub PR review comments who want human-in-the-loop control over replies and thread resolution.
Skip if: Opening new PRs, drafting specs, or bulk-merge automation when you do not want per-comment review and an explicit posting approval step.
When should I use this skill?
Responding to PR review comments on the current branch when you need to fetch or continue from existing comment context, decide per comment, apply fixes, and preview GitHub actions before posting.
What do I get? / Deliverables
Each comment gets a recorded decision, optional code changes land on the branch, and you approve a final preview before GitHub replies and resolutions go live.
- Per-comment response decisions and applied code changes on the branch
- User-approved preview of GitHub replies and thread resolutions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Pull-request comment response is a canonical ship-phase review activity: you are closing the loop with reviewers before merge. The skill is scoped to code review threads, resolutions, and optional fixes on the current branch—not general issue triage or deployment.
Where it fits
Reviewer asked for naming changes on three inline comments—you decide per thread, patch, then preview replies.
A comment requests an API contract tweak; you implement it on the PR branch before resolving the thread.
Pre-merge cleanup: last blocking review comments get explicit responses so the PR can ship.
How it compares
A structured PR-comment ritual with preview gates—not a one-shot “fix everything” refactor or a passive linter report.
Common Questions / FAQ
Who is respond-to-pr-comments-in-blocklist for?
Indie and solo developers using agent-assisted coding on GitHub who receive PR review feedback and need step-by-step handling with approval before anything is published to the review thread.
When should I use respond-to-pr-comments-in-blocklist?
Use it during Ship when responding to comments on the current branch; use it in Build when reviewers requested code changes you will implement before replying; skip it if comments are already fully handled or you only need to read threads without responding.
Is respond-to-pr-comments-in-blocklist safe to install?
The skill is designed not to post replies, submit reviews, or resolve threads until you approve the final preview; review the Security Audits panel on this Prism page and your org’s token scopes before granting GitHub access to your agent.
SKILL.md
READMESKILL.md - 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. ## 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 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 ea