ワンクリックで
respond-pr-feedback
Respond to review comments on a PR after evaluation and fixes
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Respond to review comments on a PR after evaluation and fixes
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | respond-pr-feedback |
| description | Respond to review comments on a PR after evaluation and fixes |
| disable-model-invocation | true |
Post replies to review comments after you've evaluated the feedback and made fixes. Resolves conversation threads by default.
/beagle-core:respond-pr-feedback [--pr <number>] [--no-resolve]
Flags:
--pr <number> - PR number to target (default: current branch's PR)--no-resolve - Skip thread resolution after posting replies (default: resolve all)Run /beagle-core:fetch-pr-feedback first to evaluate the feedback and make any necessary fixes.
Extract flags from $ARGUMENTS:
--pr <number> or detect from current branch--no-resolve flag (boolean, default false)# Get PR info (if --pr not specified, uses current branch)
gh pr view --json number,author --jq '{number, author: .author.login}'
# Get repo owner/name
gh repo view --json owner,name --jq '{owner: .owner.login, name: .name}'
# Get current authenticated user
gh api user --jq '.login'
Store as $PR_NUMBER, $PR_AUTHOR, $OWNER, $REPO, $CURRENT_USER.
Note: $OWNER, $REPO, etc. are placeholders. Substitute actual values from previous steps.
Fetch review comments, excluding PR author and current user, filtering to root comments that haven't been replied to.
Write the jq filter to a temp file using a heredoc with single-quoted delimiter (prevents shell escaping issues with !=, regex patterns, and angle brackets):
cat > /tmp/unreplied_comments.jq << 'JQEOF'
add // [] |
# Root comments from reviewers (not replies, not PR author, not current user)
[.[] | select(
.in_reply_to_id == null and
.user.login != $pr_author and
.user.login != $current_user
)] as $roots |
# IDs that current user has already replied to
[.[] | select(.user.login == $current_user) | .in_reply_to_id] as $replied |
# Filter to unreplied only
$roots | map(select(. as $c | $replied | index($c.id) == null)) |
# Dedup: group by path + line + reviewer, pick newest per group
group_by({
p: .path,
l: (.line // .original_line),
u: .user.login
}) |
map(sort_by(.created_at) | last) |
# Output needed fields
map({
id,
user: .user.login,
path,
line_display: (
.line as $end | .start_line as $start |
if $start and $start != $end then "\($start)-\($end)"
else "\($end // .original_line)" end
),
body
})
JQEOF
gh api --paginate "repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments" | \
jq -s --arg pr_author "$PR_AUTHOR" --arg current_user "$CURRENT_USER" \
-f /tmp/unreplied_comments.jq
If no unreplied comments found, output: "All review comments have been addressed." and stop.
Fetch review thread IDs to enable resolution after posting replies:
gh api graphql -f query="
query {
repository(owner: \"$OWNER\", name: \"$REPO\") {
pullRequest(number: $PR_NUMBER) {
reviewThreads(first: 100) {
nodes {
id
isResolved
comments(first: 1) {
nodes { databaseId }
}
}
}
}
}
}
"
Build a lookup map: comment databaseId → thread id (unresolved threads only). This enables immediate resolution after posting each reply.
For each unreplied comment, determine the appropriate response based on your evaluation:
| Evaluation Outcome | Response |
|---|---|
| Feedback was incorrect/unfounded | Explain why the current code is correct |
| Feedback lacked context | Explain the design decision |
| Feedback was valid and fixed | "Fixed in $COMMIT_SHA" or brief description of change |
| Feedback was valid but won't fix | Explain the tradeoff/decision |
Tagging guideline: @-tag bot reviewers (e.g., @coderabbitai) to trigger their processing. Do not @-tag human reviewers.
Post reply to each comment:
gh api "repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments/$COMMENT_ID/replies" \
-X POST --raw-field body="$RESPONSE"
This step runs by default. Skip only if --no-resolve was passed.
After posting each reply, look up the $THREAD_ID from the step 3b mapping using the comment's $COMMENT_ID:
gh api graphql -f query="
mutation {
resolveReviewThread(input: {threadId: \"$THREAD_ID\"}) {
thread { isResolved }
}
}
"
$COMMENT_ID has a matching thread ID in the lookup, resolve itGroup by reviewer:
### Reviewer: coderabbitai[bot]
| File:Line | Response Type | Thread |
|-----------|---------------|--------|
| `src/foo.ts:42` | Fixed in `abc1234` | Resolved |
| `src/bar.ts:15` | Explained design | Resolved |
### Reviewer: octocat
| File:Line | Response Type | Thread |
|-----------|---------------|--------|
| `src/baz.ts:7` | Won't fix | Resolved |
Footer:
**Threads resolved: 3/3**
@-tag bot reviewers to trigger re-processing; do not tag human reviewers# Respond to all reviewers on current PR (resolves threads)
/beagle-core:respond-pr-feedback
# Respond on a specific PR
/beagle-core:respond-pr-feedback --pr 123
# Respond without resolving threads
/beagle-core:respond-pr-feedback --no-resolve
Create Claude Code skills with best practices, structure, validation, and testing. Use when designing or refining skills, prompts, references, or supporting files.
Use when the user wants a cited, structured read of local documents and project knowledge. Triggers on: "analyze these docs", "scan my project for context", "read the docs folder", "summarize what's in .beagle/concepts/", "extract context from docs/", "what's in this folder", "go read everything in X and tell me what's there". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), web research (use web-research), LLM-as-judge evaluation (use llm-judge), or document editing (use humanize-beagle). Produces a written scan plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
Use when the user has a fuzzy idea and wants to shape it into a concrete project spec before planning or building. Triggers on: "brainstorm this", "I have an idea for...", "help me think through this project", "what should I build", "spec this out". Also catches vague feature descriptions needing structured questioning to clarify scope. Does NOT write code, plan implementation, review strategy docs, or run strategy interviews — produces a WHAT/WHY spec through dialogue, not a HOW plan.
Use when the user wants to pressure-test a product, internal-tool, or OSS concept against Amazon's Working Backwards PRFAQ gauntlet before committing to a spec. Triggers on: "work backwards", "write a PRFAQ", "press release first", "is this idea worth building", "pressure-test this concept", "filter this before brainstorm", "is this a real product". Also catches solution-first pitches ("I want to build X that does Y") and technology-first pitches ("use AI to...") that need customer-first filtering. Produces a binary pass/fail verdict, not a polished doc. Hardcore coaching — direct, skeptical, concrete. On pass, hands off to brainstorm-beagle with a concept brief. Does NOT write code, plan implementation, scaffold projects, or draft specs.
Use when the user wants web research: gathering cited, multi-angle evidence on a specific question. Triggers on: "research X for me", "do web research on", "look up sources for", "find citations for", "gather evidence on", "what does the web say about X". Also invoked programmatically by other beagle skills (prfaq-beagle Ignition, brainstorm-beagle reference points, strategy-interview context grounding) via the companion contract. Does NOT trigger on codebase lookups ("find this function", "search the repo"), local file search, LLM-as-judge evaluation, or paywalled/auth-gated scraping. Produces a written plan, parallel-subagent findings, and a cited synthesis report on disk — never inline prose, never unsourced claims.
generate release notes for changes since a given tag