respond-to-pr-comments-in-blocklist

Name: respond-to-pr-comments-in-blocklist
Author: warpdotdev

12kinstalls1forks

How to install respond-to-pr-comments-in-blocklist?

warpdotdev/common-skills/respond-to-pr-comments-in-blocklist

$npx -y skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist

Installs into the current project.

Summary

Walk users through PR review comments, fetching and displaying them first when needed, collect per-comment response decisions, apply requested fixes, and preview GitHub replies and resolutions before posting. Use when responding to PR review comments on the current branch.

Files · 1

View on GitHub

SKILL.md

1	# Respond to PR comments in blocklist
2
3	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.
4
5	## Preconditions
6
7	- Work in the repository checkout for the PR branch.
8	- Do not refetch comments unless the loaded context is missing essential fields such as comment body, author, URL, path, or line metadata.
9	- Do not post GitHub replies, submit reviews, or resolve threads until the final preview is approved by the user.
10
11	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.
12
13	## Comment filtering
14
15	Before asking for response mode, filter the loaded comments down to actionable comments that still need the user's attention.
16
17	Skip these comments without asking the user about them:
18
19	- 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.
20	- Comments that have already been responded to by the current GitHub user.
21
22	To identify the current GitHub user, prefer:
23
24	```sh
25	GH_PAGER="" gh api user --jq .login
26	```
27
28	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.
29
30	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.
31
32	When unsure whether a comment is automated, already answered, or still actionable, keep it in the walkthrough rather than skipping it.
33
34	## Ask User Question requirements
35
36	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.
37
38	## Initial mode selection
39
40	Before discussing individual comments, call `ask_user_question` with exactly one mode question:
41
42	- `Respond one-by-one`
43	- `Collect all decisions, then address in a batch`
44	- `Other...`
45
46	Use the selected mode for the rest of the workflow.
47
48	### One-by-one mode
49
50	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:
51
52	- the comment being addressed
53	- what code or documentation changed
54	- what validation was run or still needs to run
55	- the draft GitHub reply and whether the thread should be resolved
56
57	### Batch mode
58
59	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.
60
61	## Per-comment walkthrough
62
63	Process comments in the order they were displayed. For each comment:
64
65	1. Restate the relevant context briefly:
66	- author
67	- file and l

People who liked this also viewed

6 picks

Type

respond-to-pr-comments-in-blocklist

12kinstalls1forks

View on GitHub

How to install respond-to-pr-comments-in-blocklist?

warpdotdev/common-skills/respond-to-pr-comments-in-blocklist

$npx -y skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Respond to PR comments in blocklist
2
3	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.
4
5	## Preconditions
6
7	- Work in the repository checkout for the PR branch.
8	- Do not refetch comments unless the loaded context is missing essential fields such as comment body, author, URL, path, or line metadata.
9	- Do not post GitHub replies, submit reviews, or resolve threads until the final preview is approved by the user.
10
11	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.
12
13	## Comment filtering
14
15	Before asking for response mode, filter the loaded comments down to actionable comments that still need the user's attention.
16
17	Skip these comments without asking the user about them:
18
19	- 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.
20	- Comments that have already been responded to by the current GitHub user.
21
22	To identify the current GitHub user, prefer:
23
24	```sh
25	GH_PAGER="" gh api user --jq .login
26	```
27
28	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.
29
30	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.
31
32	When unsure whether a comment is automated, already answered, or still actionable, keep it in the walkthrough rather than skipping it.
33
34	## Ask User Question requirements
35
36	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.
37
38	## Initial mode selection
39
40	Before discussing individual comments, call `ask_user_question` with exactly one mode question:
41
42	- `Respond one-by-one`
43	- `Collect all decisions, then address in a batch`
44	- `Other...`
45
46	Use the selected mode for the rest of the workflow.
47
48	### One-by-one mode
49
50	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:
51
52	- the comment being addressed
53	- what code or documentation changed
54	- what validation was run or still needs to run
55	- the draft GitHub reply and whether the thread should be resolved
56
57	### Batch mode
58
59	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.
60
61	## Per-comment walkthrough
62
63	Process comments in the order they were displayed. For each comment:
64
65	1. Restate the relevant context briefly:
66	- author
67	- file and l

People who liked this also viewed

6 picks

Type