vs-fix-pr
Fix PR
Step 0: Resolve PR & Ensure Correct Branch
0a. Determine Target PR
Check if the user mentioned a PR number or URL in the conversation.
If yes — use that:
PR_NUM=$(gh pr view <number-or-url> --json number --jq .number)
PR_BRANCH=$(gh pr view <number-or-url> --json headRefName --jq .headRefName)
If no — use the current branch's PR:
PR_NUM=$(gh pr view --json number --jq .number)
PR_BRANCH=$(gh pr view --json headRefName --jq .headRefName)
If gh pr view fails (no PR found): tell user "No PR found" and stop.
REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
0b. Check Current Branch
CURRENT_BRANCH=$(git branch --show-current)
If CURRENT_BRANCH equals PR_BRANCH — proceed to Step 1.
0c. Handle Branch Mismatch
Check for uncommitted changes:
git status --porcelain
If uncommitted changes exist: Ask the user with the file list. Options:
- Stash & switch —
git stash --include-untracked --message "fix-pr: auto-stash from $CURRENT_BRANCH", then checkout - Switch without stashing — Checkout directly (changes carry over if no conflicts)
- Cancel — Stop, keep current branch
If clean: Ask the user:
- "You're on
$CURRENT_BRANCHbut PR #$PR_NUM is on$PR_BRANCH. Switch branch?" - Options: Switch / Stay
If switching:
git checkout $PR_BRANCH && git pull
Step 1: Check Build Status
SHA=$(gh pr view $PR_NUM --json commits --jq '.commits[-1].oid')
BUILD_STATE=$(gh api repos/$REPO/commits/$SHA/status --jq '.state')
echo "Build: $BUILD_STATE"
Also check for CI status via checks API:
gh pr checks $PR_NUM
| Build Status | Action |
|---|---|
| success | Proceed to Step 2 |
| failure | Analyze failure (Step 1a), then ask user |
| pending | Tell user: "Build still running. Proceed with comments or wait?" |
| No status | Proceed to Step 2 |
If Build Failed
Step 1a: Analyze the Failure
# Check for CI bot comments with build output
gh pr view $PR_NUM --json comments --jq '.comments[-1].body' | head -50
- Identify the error — parse for test failures, type errors, lint errors, build errors.
- Check if caused by this PR:
gh pr view $PR_NUM --json files --jq '.files[].path'
| Error Location | Action |
|---|---|
| File in PR diff | Fix it — it's your change |
| File NOT in PR diff | Likely flaky/external — explain to user |
If caused by PR: Read the failing file, fix, commit: fix: [description]
If external: Present options to user:
- Post explanation as PR comment
- Re-run the build (if CI supports re-trigger comments)
- Skip and proceed with PR comments
Step 2: Fetch Comments
# General PR comments
gh pr view $PR_NUM --json comments --jq '.comments[] | {id, body, author: .author.login}'
# Inline code review comments
gh api repos/$REPO/pulls/$PR_NUM/comments --jq '.[] | {id, body, author: .user.login, path, line}'
If no comments: "No PR comments to address."
Step 3: Create TODO List
One TODO per comment. Include file:line for inline comments.
Step 4: For Each Comment
4a. Evaluate
Is this valid feedback?
- Does it improve correctness or quality?
- Is it based on accurate understanding of the code?
4b. Decide Action
| Confidence | Action |
|---|---|
| High (agree) | Implement the fix |
| Low (disagree/unsure) | Ask the user before implementing |
For low confidence, explain your concern then ask:
- "The reviewer suggested X, but [concern]. What should we do?"
- Options: "Skip and reply why" / "Implement it anyway"
4c. Draft Reply & Get Approval
Show the comment and your draft reply:
> [original comment text]
Draft reply: [your draft reply]
Why: [brief reasoning]
After posting: resolve this review thread?
Options: "Post reply and resolve" / "Post reply only" / "Edit reply first"
4d. Post Reply (after approval only)
# Reply to inline review comment
gh api repos/$REPO/pulls/$PR_NUM/comments/$COMMENT_ID/replies \
-f body="<reply>"
# Reply to general PR comment
gh pr comment $PR_NUM --body "<reply>" --reply-to $COMMENT_ID
4e. Resolve Thread (inline review comments only, after approval)
Resolve via GraphQL — find the review thread containing this comment, then resolve it:
OWNER=$(echo "$REPO" | cut -d/ -f1)
NAME=$(echo "$REPO" | cut -d/ -f2)
THREADS_JSON=$(gh api graphql -f query='
query($owner:String!,$name:String!,$pr:Int!) {
repository(owner:$owner,name:$name) {
pullRequest(number:$pr) {
reviewThreads(first:100) {
nodes { id isResolved comments(first:50) { nodes { databaseId } } }
}
}
}
}' -f owner="$OWNER" -f name="$NAME" -f pr="$PR_NUM")
THREAD_ID=$(echo "$THREADS_JSON" | jq -r --argjson cid "$COMMENT_ID" '
.data.repository.pullRequest.reviewThreads.nodes[]
| select(.isResolved == false)
| select([.comments.nodes[].databaseId] | contains([$cid]))
| .id
' | head -1)
if [ -n "$THREAD_ID" ]; then
gh api graphql -f query='mutation($id:ID!){ resolveReviewThread(input:{threadId:$id}) { thread { isResolved } } }' -f id="$THREAD_ID"
fi
If THREAD_ID is empty: tell user the reply was posted and they can resolve manually in the PR UI.
Mark TODO complete, move to next comment.
Critical Rules
- Never post or resolve without explicit approval — show draft first, wait for confirmation
- Always reply to the specific comment — use replies API, not a new top-level comment
- Never post a general PR comment when addressing inline review comments (stay on-thread)
- Default: reply + resolve for inline threads after user approves (unless they opt out)
Summary
| Scenario | Response |
|---|---|
| No comments | "No PR comments to address." |
| All addressed | "All done! Addressed X comments." |
| Some skipped | "Addressed X comments, skipped Y. Let me know if you want to revisit." |
Workflow
Prev: /vs-ship-it (PR created, reviewers left comments)
Next: /vs-ship-it (re-push after fixes) | /vs-roast-my-code (self-review before re-push) | done
More from vltansky/vladstack
vs-fix
Autonomous bug fix pipeline. Investigates root cause, reproduces with a failing test, fixes, verifies, reviews, and hands back a clean branch. Use when the user says 'fix', 'fix this bug', 'fix this', 'something is broken', 'this doesn't work', or describes a bug to fix. Unlike /debug-mode (investigation only), /fix goes end-to-end: find it, prove it, fix it, verify it.
1vs-tdd
Test-driven development loop. Write failing test first, then implement to make it pass. Use when the user says 'tdd', 'test first', 'write the test first', 'failing test', 'red green refactor', or for any bug fix where the fix should be proven by a test. Also use when autopilot or other skills need test-first execution.
1vs-qa
Systematically QA test a web application and fix bugs found. Runs browser-based testing, iteratively fixes bugs in source code, commits each fix atomically, and re-verifies. Use when asked to 'qa', 'QA', 'test this site', 'find bugs', 'test and fix', or 'fix what's broken'. Three tiers: Quick (critical/high only), Standard (+medium, default), Exhaustive (+cosmetic). Produces before/after health scores, fix evidence, and a ship-readiness summary. For report-only mode, use /qa-only.
1vs-debug-mode
Systematic root-cause debugging with optional runtime log server for frontend/UI bugs. Hypothesis-driven investigation. Use when the user says 'debug', 'debug this', 'investigate', 'why is this broken', 'root cause', 'trace this bug', 'figure out why', 'this doesn't work', 'unexpected behavior', 'UI not updating', 'state is wrong', 'value is null/undefined', 'click doesn't work'. Also use instead of adding console.log — this skill collects logs automatically.
1vs-autopilot
Autonomous plan-to-code pipeline. If no plan is provided, auto-generates one via a plan-mode subagent. Stress-tests the plan (using grill-me), fixes issues found, creates a branch, executes step by step with guardrails, runs code review and QA, then hands back a shippable branch. Zero human interaction until the final handoff. Use when the user says 'autopilot', 'just build it', 'auto execute', 'implement this plan', 'take it from here', or wants to go from plan to working code without babysitting.
1vs-grill-me
Structured adversarial review that pushes back on a plan, challenges the premise, compares alternatives, and stress-tests the design until the main risks are explicit. Use when the user asks to "grill me", stress-test a plan, poke holes in an approach, challenge assumptions, pressure-test a design, or validate an early-stage idea before building ("I have an idea", "is this worth building", "grill me on this idea").
1