Menu
Reply to GitHub PR review comments as threaded responses using the GitHub API replies endpoint.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Orchestrate Birdhouse child agents to investigate PR review feedback in parallel, classify it as strengthened, weakened, or invalidated, then address approved items serially with fixes or threaded replies.
Create isolated working directories using git worktrees without affecting the main workspace. Use when you want to use worktree, git worktree, worktree workflow, isolated development, work in worktree, create worktree, or worktree best practices.
Generate release notes from git branch commit history and analyze changes. Use when you want to generate release notes, prepare release notes, prep for a PR, find what changed in this branch, or get branch change summary.
Create GitHub pull requests using gh CLI with proper formatting for multi-line descriptions. Use when you want to create a pr, submit a pr, pull request, create a pull request, submit a pull request, open a pr, or new pr.
Core software development principles: code for readability and changeability, apply DRY wisely, test for confidence, and crash loudly on unexpected conditions.
Frame an agent as a junior engineer who looks things up, cites sources, and doesn't rely on potentially stale training knowledge. Use instead of "you are an expert in X" when you want fresh, grounded research over confident guessing.
| name | github-reply |
| description | Reply to GitHub PR review comments as threaded responses using the GitHub API replies endpoint. |
| trigger_phrases | ["github reply","reply to github comment","reply in github thread","threaded github reply"] |
| tags | ["github","pull-request"] |
Use this skill when you need to reply to an existing GitHub PR review comment thread.
Always use the GitHub /replies endpoint so the response appears in the existing thread instead of as a new top-level comment.
Use the numeric review comment id, usually the last_comment_id from thread data.
gh api \
"/repos/OWNER/NAME/pulls/PR_NUMBER/comments/COMMENT_ID/replies" \
--method POST \
-f body="Your reply text here"
Read the file contents first, then pass the content to -f body=.
Correct:
REPLY_BODY=$(cat /path/to/reply.txt)
gh api \
"/repos/OWNER/NAME/pulls/PR_NUMBER/comments/COMMENT_ID/replies" \
--method POST \
-f body="$REPLY_BODY"
Also correct:
gh api \
"/repos/OWNER/NAME/pulls/PR_NUMBER/comments/COMMENT_ID/replies" \
--method POST \
-f body="$(cat /path/to/reply.txt)"
Wrong:
gh api \
"/repos/OWNER/NAME/pulls/PR_NUMBER/comments/COMMENT_ID/replies" \
--method POST \
-f body=@/path/to/reply.txt
That wrong form posts the filename literally instead of the file contents.
Always @ mention the author(s) you're replying to at the start of your message. This ensures they receive a notification since GitHub threaded replies do not auto-notify participants.
Examples:
@reviewer Thanks for the feedback...PR=6313
COMMENT_ID=2508381598
OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
OWNER=${OWNER_REPO%/*}
NAME=${OWNER_REPO#*/}
cat > /tmp/pr-reply-${COMMENT_ID}.txt << 'EOF'
@reviewer Thanks for the feedback! I've addressed this by...
EOF
REPLY_BODY=$(cat /tmp/pr-reply-${COMMENT_ID}.txt)
gh api \
"/repos/$OWNER/$NAME/pulls/$PR/comments/$COMMENT_ID/replies" \
--method POST \
-f body="$REPLY_BODY"
Do not use these for threaded review replies:
gh pr review --commentgh pr comment-f body=@filenameThose create top-level comments or malformed replies instead of threaded responses.
After posting, report back with: