skills/pr-review-responder/SKILL.md
Use when a PR has review comments to address - fetches inline comments from GitHub, fixes code issues, replies to each comment, and resolves threads. Trigger on "address the review", "fix PR comments", "handle review feedback on PR
npx skillsauth add razbakov/skills pr-review-responderInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
End-to-end workflow for addressing PR review comments: fetch, categorize, fix, reply inline, resolve threads.
Core principle: Fix code first, then reply with the commit reference. Never reply "fixed" without actually fixing.
Fetch comments → Categorize → Fix code → Run tests → Reply inline → Resolve threads
# Get all inline review comments with essential fields
gh api repos/{owner}/{repo}/pulls/{number}/comments \
--jq '.[] | {id: .id, path: .path, line: .line, body: (.body | split("\n") | first)}'
This returns review comments (inline code comments), not PR-level comments.
Group comments by priority before fixing:
| Category | Action | |----------|--------| | Code fix needed | Fix in code, commit, reply with commit SHA | | Acknowledged (missing feature) | Create a GitHub issue, reply with issue link. "Acknowledged" without a tracking issue means the work gets lost. | | Acknowledged (product decision) | Reply explaining the trade-offs. Don't create an issue — design questions need discussion first, not a ticket. | | By design | Reply with reasoning for the design choice | | Already fixed | Reply noting which commit addressed it |
Fix all actionable items, then run tests before replying:
# Make fixes...
# Then verify
bun run test:e2e # or project-specific test command
bun run build # check for type errors
Never reply "fixed" without passing tests.
Commit all fixes in one commit with a clear message referencing the review:
git commit -m "Address PR review feedback
- Fix A (P1)
- Fix B (P2)
..."
git push
Note the commit SHA — you'll reference it in replies.
# Reply to a specific inline comment by its ID
gh api -X POST repos/{owner}/{repo}/pulls/{number}/comments \
-f body="Fixed in abc1234 — added unique constraint." \
-F in_reply_to={comment_id}
Reply format: Start with "Fixed in {sha}" or "Acknowledged" — be concise.
First, get thread IDs via GraphQL:
gh api graphql -f query='
query {
repository(owner: "{owner}", name: "{repo}") {
pullRequest(number: {number}) {
reviewThreads(first: 50) {
nodes {
id
isResolved
comments(first: 1) {
nodes { body }
}
}
}
}
}
}' --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | .id'
Then resolve each thread:
gh api graphql -f query='mutation {
resolveReviewThread(input: {threadId: "{thread_id}"}) {
thread { isResolved }
}
}'
Batch resolve in a loop:
threads=("PRRT_abc" "PRRT_def" "PRRT_ghi")
for t in "${threads[@]}"; do
gh api graphql -f query="mutation { resolveReviewThread(input: {threadId: \"$t\"}) { thread { isResolved } } }" --silent 2>/dev/null
done
| Mistake | Fix |
|---------|-----|
| Reply "fixed" without fixing | Fix code and verify tests pass first |
| Use gh pr review for inline replies | Use gh api -X POST .../pulls/{n}/comments with in_reply_to |
| Try to resolve with comment IDs | Thread IDs (PRRT_...) are different from comment IDs — use GraphQL query |
| Reply via general PR comment | Reply inline so each thread gets its own response |
| Resolve without replying | Reply first, then resolve — reviewer needs to see what was done |
| Use shell function keyword in zsh | Use array + for loop instead — zsh aliases conflict with function |
| Task | Command |
|------|---------|
| List inline comments | gh api repos/{o}/{r}/pulls/{n}/comments --jq '.[] \| {id, path, body}' |
| Reply to comment | gh api -X POST repos/{o}/{r}/pulls/{n}/comments -f body="..." -F in_reply_to={id} |
| Get thread IDs | GraphQL reviewThreads query (see Step 6) |
| Resolve thread | GraphQL resolveReviewThread mutation |
| Check resolution | --jq '.data...reviewThreads.nodes[] \| select(.isResolved == false)' |
development
Seed a new or empty Instagram account with a 9-post grid (3×3) so the profile looks established the moment a new visitor lands. Designed for festivals, new businesses, product launches, conferences, communities — any time an empty IG profile would hurt conversion from external traffic (QR scans, flyer drops, cross-promo). Generates assets via /image-from-gemini (per content-publishing rules — never HTML), writes captions with hashtag sets, and outputs a posting order + cadence plan. Trigger generously: phrases like '9 posts for instagram', 'fill my IG', 'starter grid', 'launch grid', 'instagram seed', '9-post grid', 'IG account not to look empty', 'first instagram posts', 'feed bootstrap', '3x3 grid', 'instagram launch content'. Even if the user mentions only one piece (just the images, just the captions, just the order), use this skill — the grid only works as an integrated bundle.
testing
Translate one English blog post into multiple target languages via parallel sub-agents, preserving frontmatter conventions, hero image, and brand voice. Use when the user shares a published English post URL or markdown path and says 'translate it', 'add other languages', 'publish in DE/ES/RU/UK', 'translate to 5 languages', or asks for localized versions of a specific post.
development
Build a complete press kit for an event, product launch, or campaign — in multiple languages — and publish it as a shareable Google Drive folder ready to send to journalists, partners, or a delegate. Produces press releases (typically DE/EN/ES, or configurable), uploads press photos and flyers, creates an Overview document for at-a-glance briefing, and creates a Handover document with pending tasks, contacts, risks, and decisions so press distribution can be delegated. Use when the user says 'I need a press release', 'create a press kit', 'press release in X languages', 'set up a Drive folder for press', 'handover doc for someone else to run press', or has an upcoming announcement that needs to be sent to media. Trigger generously: even partial requests (just a press release, just a flyer folder) typically evolve into the full kit.
development
Track ticket sales for a live event (concert, festival, conference, workshop) with daily snapshots, generate a burndown chart comparing actual sales to ideal-linear targets and tier-cumulative milestones, and report whether the event is on pace. Use when the user asks how sales are going, wants to know if their event will sell out, asks for a daily sales report, wants to set up sales tracking for an upcoming event, or asks about ticket pace / velocity / projection. Trigger generously: phrases like 'how is concert sales going', 'burndown for my event', 'are we going to sell out', 'sales velocity', 'daily ticket chart', 'how many tickets do we need to sell', or any case where the user has a ticketed event with a fixed sales window and wants visibility on pacing.