New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Respond To PR Comments In Blocklist

by warpdotdev in warpdotdev/common-skills

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…

MITAuto-check: warningsDevelopment

Install Respond To PR Comments In Blocklist

The automated check flagged lines worth reading first. See the safety section below.

skills CLI
$ npx skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev/common-skills respond-to-pr-comments-in-blocklist --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev/common-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/respond-to-pr-comments-in-blocklist .claude/skills/respond-to-pr-comments-in-blocklist && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
respond-to-pr-comments-in-blocklist
GitHub stars
611
Used in
1 other repo
Token cost
~3.6k tokens
SKILL.md length
1,831 words
Files
1
Skills in repo
28
Repo updated
First seen
Licence
MIT

At a glance

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…

  • Works in 3 steps: Restate the relevant context briefly → If the fix is not obvious from the… → Call ask_user_question with options…
  • Wants to reply to
  • SKILL.md covers When not to use this skill, Preconditions, Comment filtering and Ask User Question requirements, plus 9 more sections
  • Calls gh, git and python3

What it does

Respond To PR Comments In Blocklist is an agent skill from warpdotdev/common-skills. 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.

Its SKILL.md is about 3.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Pull requests. It works with GitHub. The licence is MIT.

When your agent uses it

  • Wants to reply to
  • Resolve review threads on GitHub
  • Only wants comments fetched
  • Displayed (use pr-comments)

Example prompts

  • “/respond-to-pr-comments-in-blocklist”

Requirements

  • Python 3

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

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

What it can do on your machine

Read from SKILL.md and the folder at commit 2a03b40. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git
    • python3

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Respond To PR Comments In Blocklist loads about 3.6k tokens when it runs. Until then it costs about 120 tokens; SKILL.md has 1,831 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~120
When it runs · the whole SKILL.md, loaded when a task matches
~3.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: warnings

The automated check found patterns that need a careful read before installing.

  • WarningTells the agent its actions are pre-authorized / not to stop for confirmationSKILL.md:26
    Skip these comments without asking the user about them:

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from warpdotdev/common-skills at commit 2a03b40, republished under its MIT licence (© warpdotdev). 1,831 words, ~3,564 tokens.

Download SKILL.mdSave it as .claude/skills/respond-to-pr-comments-in-blocklist/SKILL.md (or your agent's skills folder).
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 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
  2. If the fix is not obvious from the loaded context, inspect the relevant files before presenting options.
  3. 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.

Show full SKILL.md (693 more words)Show less

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:

  • Apply only changes related to the selected PR comments.
  • Preserve unrelated local changes.
  • Follow repository-specific coding, testing, and style rules.
  • Run the narrowest useful validation after each one-by-one fix, and run final validation after all fixes are applied.
  • If a requested fix is unsafe, ambiguous, or conflicts with another comment, stop and ask the user before editing.

Final validation

After all accepted fixes are applied:

  1. Review git diff to confirm the changes match the collected decisions.
  2. Run relevant formatting, linting, typechecking, build, or tests based on the repository's conventions and the files changed.
  3. If validation cannot be run, explain why in the final summary and include that caveat in the preview.

Do not commit changes unless the user explicitly asks.

Commit and push before GitHub responses

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 replies
  • Do not commit or push; continue to the GitHub reply preview
  • Stop before posting GitHub replies
  • Other...

If the user chooses to commit and push:

  1. Review git status and the final diff so only intended comment-response changes are included.
  2. Ask for or propose a concise commit message if one is not already clear; preserve the Other... option for custom commit instructions.
  3. Stage the intended changes, commit in a non-interactive command, and push the current branch to origin.
  4. Include 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.
  5. If commit or push fails, stop before posting GitHub replies and report the failure.

GitHub reply and resolution preview

After the commit/push decision is complete, and before posting anything to GitHub, show a preview grouped by comment. For each comment include:

  • comment URL or short identifier
  • action: reply only, resolve only, reply and resolve, or no GitHub action
  • reply body
  • commit link, when a pushed commit exists for the fix
  • validation relevant to that comment

Then call ask_user_question to ask whether to proceed:

  • Post replies and resolve approved threads
  • Edit the draft responses first
  • Do not post anything
  • Other...

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.

Posting with GitHub CLI

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:

sh
REPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
REPLY_PAYLOAD_FILE="$(mktemp)"
python3 - "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE" <<'PY'
import json
import sys
from pathlib import Path

body_file = Path(sys.argv[1])
payload_file = Path(sys.argv[2])
payload_file.write_text(json.dumps({"body": body_file.read_text()}))
PY
GH_PAGER="" gh api \
  --method POST \
  /repos/{owner}/{repo}/pulls/{pull_number}/comments/{comment_id}/replies \
  --input "$REPLY_PAYLOAD_FILE"
rm -f "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE"

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:

sh
REPLY_BODY_FILE="$(mktemp)"
cat > "$REPLY_BODY_FILE"
GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"
rm -f "$REPLY_BODY_FILE"

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:

sh
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
                }
              }
            }
          }
        }
      }
    }'

Resolve an approved thread with:

sh
GH_PAGER="" gh api graphql \
  -f threadId="$THREAD_ID" \
  -f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { id isResolved } } }'

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.

Final response

After posting approved responses and resolving approved threads, summarize:

  • comments addressed
  • files changed
  • validation results
  • whether changes were committed and pushed to origin
  • GitHub replies or resolutions posted
  • anything left for the user

© warpdotdev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/respond-to-pr-comments-in-blocklist of warpdotdev/common-skills.

Open the folder on GitHubat commit 2a03b40

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in warpdotdev/common-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Respond To PR Comments In Blocklist next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Respond To PR Comments In Blocklist compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Respond To PR Comments In Blocklist this skillwarpdotdev/common-skills6111 repos~3.6kAutomated safety check: WarnMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Check PRonyx-dot-app/onyx32k2 repos~2.3kAutomated safety check: PassMIT
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0
Pull Request Title and Body Writeropeninterpreter/openinterpreter69k2 repos~1.1kAutomated safety check: PassApache-2.0

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Check PR

    onyx-dot-app/onyx

    Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.

    32k GitHub starsUsed in 2 repos~2.3k tokens
    DevelopmentAuto-check passed

  • Contributor-First PR Merge

    HKUDS/OpenHarness

    Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed

  • Create Pull Request

    cline/cline

    Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed

  • Pull Request Title and Body Writer

    openinterpreter/openinterpreter

    Rewrites the title and body of one or more pull requests with gh, leading with why the change was made, then what changed, and describing only the net result.

    69k GitHub starsUsed in 2 repos~1.1k tokens
    DevelopmentAuto-check passed

  • GitHub Review Iteration

    prisma/orm

    Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed

More from warpdotdev/common-skills

All 28 skills in this repo

  • Skill Doctor

    warpdotdev/common-skills

    Grades agent skills by scoring agent conversations for efficiency, code quality, procedure compliance, and verbosity, then drafts concrete skill edits and a shareable report.

    611 GitHub starsUsed in 2 repos~2.6k tokens
    Auto-check passed

  • Readout

    warpdotdev/common-skills

    Produce a polished, self-contained HTML "readout" document under ~/.readouts (with an auto-maintained index page), either by snapshotting the findings accumulated in the current conversation or —…

    611 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • Resolve Merge Conflicts

    warpdotdev/common-skills

    Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context.

    611 GitHub stars~733 tokensUpdated yesterday
    Auto-check passed

  • Review PR

    warpdotdev/common-skills

    Review a pull request diff and write structured feedback to review.json for the workflow to publish.

    611 GitHub stars~2.6k tokensUpdated yesterday
    Auto-check passed

  • Saga

    warpdotdev/common-skills

    Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents.

    611 GitHub stars~4.1k tokensUpdated yesterday
    Auto-check passed

  • PR Walkthrough

    warpdotdev/common-skills

    Generate a static interactive D3 walkthrough of a pull request.

    611 GitHub starsUsed in 1 repo~7.2k tokens
    Auto-check passed

Works with

Categories

Questions about Respond To PR Comments In Blocklist

What does Respond To PR Comments In Blocklist do?

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…. Respond To PR Comments In Blocklist is an agent skill from warpdotdev/common-skills. 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.

When should I use Respond To PR Comments In Blocklist?

Respond To PR Comments In Blocklist fits situations like: wants to reply to; resolve review threads on GitHub; only wants comments fetched; displayed (use pr-comments).

How do I install Respond To PR Comments In Blocklist in Claude Code?

Run `npx skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist -a claude-code`. Or copy the skill folder (.agents/skills/respond-to-pr-comments-in-blocklist in warpdotdev/common-skills) into .claude/skills/respond-to-pr-comments-in-blocklist in your project. Claude Code loads it when a task matches its description.

How do I install Respond To PR Comments In Blocklist in Codex?

Run `npx skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist -a codex`. Or copy the skill folder (.agents/skills/respond-to-pr-comments-in-blocklist in warpdotdev/common-skills) into .agents/skills/respond-to-pr-comments-in-blocklist in your project. Codex loads it when a task matches its description.

Can I use Respond To PR Comments In Blocklist in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev/common-skills --skill respond-to-pr-comments-in-blocklist -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/respond-to-pr-comments-in-blocklist, .gemini/skills/respond-to-pr-comments-in-blocklist, .github/skills/respond-to-pr-comments-in-blocklist and .opencode/skills/respond-to-pr-comments-in-blocklist in your project.

What does Respond To PR Comments In Blocklist need to run?

Going by SKILL.md and its folder, Respond To PR Comments In Blocklist needs the command-line tools its instructions call (gh, git and python3). Our summary lists: Python 3.

Does Respond To PR Comments In Blocklist access the network?

SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Respond To PR Comments In Blocklist safe to install?

Our automated static check of SKILL.md flagged 1 warning(s): tells the agent its actions are pre-authorized / not to stop for confirmation. Read the flagged lines before installing; the check is not a guarantee either way.

What licence does Respond To PR Comments In Blocklist use?

Respond To PR Comments In Blocklist is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Respond To PR Comments In Blocklist use?

About 3.6k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Respond To PR Comments In Blocklist?

Skills that share tags, products or a category with Respond To PR Comments In Blocklist: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars), Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars) and Create Pull Request (cline/cline, 70k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Respond To PR Comments In Blocklist?

warpdotdev (a GitHub organization) maintains it in warpdotdev/common-skills, which has 611 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on October 7, 2026.

Source: warpdotdev/common-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.