pr-pilot
PR Pilot
Push a branch, create a PR, loop through reviews until clean, then squash-merge.
Input
The skill works in the current working directory (or a specified worktree path). It needs:
- A branch with committed changes ready to push
- Optionally a Transit ticket reference (
T-{id}) for status tracking - Optionally an existing PR number (skips push and PR creation)
If invoked with arguments, parse them for:
T-{number}— Transit ticket to track#{number}or a PR number — existing PR to work with- A path — working directory override
Workflow
1. Push and Create PR
If no existing PR number was provided:
-
Push the branch:
git push -u origin HEAD -
Create the PR:
PR_NUM=$(gh pr create --fill --json number --jq '.number')If the branch name contains a
T-{number}prefix, include it in the PR title.
If an existing PR was provided, fetch its details:
gh pr view {pr_number} --json number,headRefName,state
2. Review Loop
2.1 Wait for CI and Reviews
Wait 10 minutes after the PR was created (or after the last push) to allow CI checks and reviewer comments to arrive.
2.2 Run PR Review Fixer
Run the /pr-review-fixer skill to fetch unresolved PR comments and CI failures, validate them, and fix any issues found.
After the skill completes, evaluate the results:
- CLEAN: No blockers, critical, or major issues were found. Minor and nitpick items are acceptable.
- HAS_ISSUES: There were blockers, critical, or major items that were fixed and pushed. Another round is needed.
2.3 Evaluate and Repeat
- HAS_ISSUES: Wait 10 minutes, then go back to step 2.1.
- CLEAN: Proceed to merge.
Cap the loop at 5 iterations. If still not clean after 5 rounds, inform the user and stop. Do not merge.
If a Transit ticket is tracked, add a comment: "Automated review loop did not converge after 5 iterations — manual review needed."
3. Rebase and Merge
3.1 Rebase onto Latest Main
git fetch origin main
git rebase origin/main
If conflicts arise, resolve them. After resolving:
git rebase --continue
Run the project's test suite and linter to verify the rebase is clean.
3.2 Push Rebased Branch
git push --force-with-lease
3.3 Wait for CI
gh pr checks {pr_number} --watch
If CI fails after rebase, run /pr-review-fixer once more to fix CI issues. If it still fails, inform the user and stop.
3.4 Squash and Merge
gh pr merge {pr_number} --squash --delete-branch
4. Update Transit Ticket
If a Transit ticket is being tracked, move it to done:
mcp__transit__update_task_status(displayId={id}, status="done", comment="Merged via squash-and-merge — PR #{pr_number}", authorName="claude[bot]")
If no Transit ticket is tracked, skip this step.
5. Summary
Report the outcome:
PR #{pr_number} — {MERGED|FAILED}
- Review rounds: N
- Transit: T-{id} → done (or N/A)
More from arjenschwarz/agentic-coding
ui-ux-reviewer
Evaluate and improve user experience of interfaces (CLI, web, mobile)
120efficiency-optimizer
Analyze code for performance and efficiency improvements
41design-critic
Critical review of design documents, architecture proposals, and requirements
26fix-bug
Systematic bug investigation, resolution, and documentation. Use when fixing bugs that need thorough analysis, test coverage, and a formal bugfix report. Applies systematic debugging methodology, creates regression tests, and generates a standardized report in specs/bugfixes/<bug-name>/. For complex bugs, spawns competing implementation agents (including alternative harnesses like Kiro) and selects the best solution. Triggers on requests like "fix this bug", "debug and document this issue", or when a bug needs both resolution and documentation.
22permission-analyzer
Generate Claude Code permissions config from session history. Use when setting up autonomous mode, configuring .claude/settings.json, avoiding --dangerously-skip-permissions, or analyzing what permissions a project needs. Reads session logs to extract Bash commands and MCP tools actually used, then generates appropriate allow/deny rules.
22performing-systematic-debugging-for-stubborn-problems
Applies a modified Fagan Inspection methodology to systematically resolve persistent bugs and complex issues. Use when multiple previous fix attempts have failed repeatedly, when dealing with intricate system interactions, or when a methodical root cause analysis is needed. Do not use for simple troubleshooting. Triggers after multiple failed debugging attempts on the same complex issue.
20