Skip to content
skillsafebeta
← Report library
Purpose / Development

Respond To Pr Comments In Blocklist Skill Security Audit

What the author says it does (original text)

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 ma

Independent security check

Security risks found

Files checked
1
Risks found
2
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.No risks found
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Low risk

Reply-body temporary files may remain after a failed or interrupted post

Source references: 4
What we found

The workflow writes the reply and JSON payload to temporary files, but performs an ordinary `rm -f` only after the GitHub command. There is no exit trap or failure-path cleanup, so an error, agent termination, or interrupted process can bypass deletion.

Why this matters

An unpublished reply, quoted review material, or user-supplied rationale may remain in the local temporary directory, subject to that machine's temporary-file permissions and cleanup policy.

The active workflow writes the reply and JSON payload to temporary files, with deletion only after the network-posting command. If execution is interrupted before deletion, the reply could remain in the system temporary directory and may contain non-public review details. The shown procedure has no exit trap or equivalent guaranteed cleanup. A user can ask for guaranteed cleanup and restricted temporary-file permissions and retention.

SKILL.md:185In the instructionsOpen original file
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:```shREPLY_BODY_FILE="$(mktemp)"cat > "$REPLY_BODY_FILE"REPLY_PAYLOAD_FILE="$(mktemp)"python3 - "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE" <<'PY'import jsonimport sysfrom pathlib import Pathbody_file = Path(sys.argv[1])payload_file = Path(sys.argv[2])payload_file.write_text(json.dumps({"body": body_file.read_text()}))PYGH_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"```
Show 3 other places
SKILL.md:207In the instructionsOpen original 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:```shREPLY_BODY_FILE="$(mktemp)"cat > "$REPLY_BODY_FILE"GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"rm -f "$REPLY_BODY_FILE"```
SKILL.md:188In the instructionsOpen original file
```shREPLY_BODY_FILE="$(mktemp)"cat > "$REPLY_BODY_FILE"REPLY_PAYLOAD_FILE="$(mktemp)"python3 - "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE" <<'PY'import jsonimport sysfrom pathlib import Pathbody_file = Path(sys.argv[1])payload_file = Path(sys.argv[2])payload_file.write_text(json.dumps({"body": body_file.read_text()}))PYGH_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"```
SKILL.md:210In the instructionsOpen original file
```shREPLY_BODY_FILE="$(mktemp)"cat > "$REPLY_BODY_FILE"GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"rm -f "$REPLY_BODY_FILE"```
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Medium risk

Mandatory Warp Agent attribution can create false authorship records

Source references: 4
What we found

Every reply that may be posted must be labeled `[Warp Agent]`, and each commit must add `Warp Agent <agent@warp.dev>` as a co-author. The Skill never verifies that its actual executing agent is affiliated with Warp, so these records may be factually incorrect.

Why this matters

Reviewers and future readers of the Git history may misidentify who wrote a response or contributed to a change, weakening provenance, accountability, and identity-based trust decisions.

The Skill requires every prospective GitHub reply to carry a `[Warp Agent]` prefix and, when the user chooses to commit, records `Warp Agent <agent@warp.dev>` as a co-author without requiring verification of the actual agent identity or contribution. Although posting and committing require user approval, these fixed attributions could mislead reviewers or commit-history readers. A user can ask the author to use the actual agent identity or permit removal of inaccurate attribution during preview.

SKILL.md:112In the instructionsOpen original file
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 3 other places
SKILL.md:157In the instructionsOpen original file
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.
SKILL.md:181In the instructionsOpen original file
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.
SKILL.md:183In the instructionsOpen original file
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.
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

The Skill collects the user's decision for each actionable review comment and edits code according to the selected mode. It instructs the agent to preserve unrelated local changes, inspect the final diff, and run relevant validation before publishing.

View source
SKILL.md:118In the instructionsOpen original file
- 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.
SKILL.md:131In the instructionsOpen original file
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.

The Skill can commit changes and push the current branch to `origin`, but only after presenting that choice and the user selects it. It instructs the agent to stop before posting GitHub replies if the commit or push fails.

View source
SKILL.md:141In the instructionsOpen original file
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...`
SKILL.md:152In the instructionsOpen original file
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.

Posting GitHub replies and resolving review threads are external account mutations. The Skill requires a per-comment preview and explicit approval first, and says to report a limitation rather than guess when metadata cannot be matched reliably.

View source
SKILL.md:162In the instructionsOpen original file
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 commentThen 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.
SKILL.md:248In the instructionsOpen original file
Resolve an approved thread with:```shGH_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.
Start here · InstructionsSKILL.md
respond-to-pr-comments-in-blocklist
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 5 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Read files
SKILL.md:189In the instructionsOpen original file
REPLY_BODY_FILE="$(mktemp)"cat > "$REPLY_BODY_FILE"REPLY_PAYLOAD_FILE="$(mktemp)"
SKILL.md:198In the instructionsOpen original file
payload_file = Path(sys.argv[2])payload_file.write_text(json.dumps({"body": body_file.read_text()}))PY
SKILL.md:211In the instructionsOpen original file
REPLY_BODY_FILE="$(mktemp)"cat > "$REPLY_BODY_FILE"GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"
Change files
SKILL.md:198In the instructionsOpen original file
payload_file = Path(sys.argv[2])payload_file.write_text(json.dumps({"body": body_file.read_text()}))PY
SKILL.md:204In the instructionsOpen original file
  --input "$REPLY_PAYLOAD_FILE"rm -f "$REPLY_BODY_FILE" "$REPLY_PAYLOAD_FILE"```
SKILL.md:213In the instructionsOpen original file
GH_PAGER="" gh pr comment {pull_number} --body-file "$REPLY_BODY_FILE"rm -f "$REPLY_BODY_FILE"```
Lines read
268
File checksum (to compare versions)
864831a5bf3d2613a6832fa10df5aa77aa798a71a578aeb203c1d1ff8ef09db3