菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 — when invoked fresh, e.g. "/readout on how github webhook events are processed" — by sharpening scope with clarifying questions and researching the codebase before documenting. The work runs in a child agent so the main conversation's context stays clean. Use whenever the user invokes /readout, says "write this up", "turn this into a doc/page", "make a readout", or asks for a readable, shareable document capturing findings or explaining how something works.
Scan warpdotdev/warp and warp-server for recently merged PRODUCT.md specs that don't yet have a corresponding docs PR in warpdotdev/docs. When a complete spec is found, auto-generates a full docs draft PR and tags the engineer. When a spec is too thin to draft from, pings the engineer directly. Designed to run as a scheduled Oz ambient agent (e.g., every 2-3 days). Use when setting up the automated docs trigger or running a manual docs coverage sweep.
Draft a complete documentation page for a new Warp feature from its PRODUCT.md and/or TECH.md spec. Use when an engineer has written a spec and needs to produce a first-pass MDX draft for the warpdotdev/docs repo. Also handles features without specs by researching the codebase first. Invoke this skill whenever an engineer mentions writing docs for a feature, drafting a docs page, creating feature documentation, starting the eng-docs workflow, or converting a spec into documentation. Works from warp-internal or warp-server.
Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents. Use this skill whenever the user invokes /saga, asks to autonomously build a sizable feature end-to-end with minimal human intervention, wants a comprehensive spec broken into milestones and tasks with airtight validation criteria before parallelized implementation, or wants an orchestrator to delegate implementation to worker agents while preserving its own context window. Trigger on phrases like "run a saga", "autonomously implement this feature", "spec it out then build it with subagents", "orchestrate this big feature end-to-end", or "build this with workers and validate each step". Also use this skill when asked to continue, resume, or pick up an existing saga from its saga directory (e.g. under ~/.sagas).
Run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision — architecture tradeoffs, code review disagreements, design choices, competing root-cause theories — and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills; reach for it liberally whenever proposals diverge.
Delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys — i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally before reading a pile of files inline.
| name | respond-to-pr-comments-in-blocklist |
| description | 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. |
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.
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:
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.
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: Oz <oz-agent@warp.dev> in the commit message.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:
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:
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:
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:
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.
After posting approved responses and resolving approved threads, summarize:
origin