| name | piv-create-pr |
| description | Push the current feature branch and open a pull request, ready for review. Use after a ticket's implementation is committed on its own branch — it detects the base branch, pushes, opens the PR with a clear body (summary · what changed · validation status), and returns the URL to hand to a reviewer. |
| argument-hint | [--base <branch>] (default: auto-detected) |
Create PR: Open the Pull Request, Hand Off for Review
This is the ship step of the PIV loop: the implementation is committed on a feature branch; now open the PR
so it can be reviewed (by the piv-review-pr agentic gate, then a human).
Phase 0 — Detect the base branch
Don't hardcode main. Resolve it:
- If
$ARGUMENTS contains --base <branch>, use that.
- Else:
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
- Fallback:
git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}'
- Last resort:
main. Store as {base}.
Phase 1 — Validate git state
git branch --show-current
git status --short
git log origin/{base}..HEAD --oneline
| State | Action |
|---|
On {base} | STOP: "Create a feature branch first (the ticket should be on its own branch)." |
| Uncommitted changes | STOP: "Commit (or stash) before opening the PR." |
No commits ahead of {base} | STOP: "Nothing to PR." |
Existing PR for this branch (gh pr list --head $(git branch --show-current) --json url) | STOP and print the URL. |
| Clean, commits ahead, no PR | PROCEED |
Phase 2 — Gather context for the body
- Project conventions: if
.claude/references/conventions.md exists, read its ## pr section — its rules
win over the default template below (sections, tone, what must be stated). That file is where a project's
specifics live; this skill stays general.
- Commits:
git log origin/{base}..HEAD --pretty=format:"- %s"
- Files:
git diff --stat origin/{base}..HEAD
- Implementation report (if
piv-implement wrote one — .claude/reports/<…>-report.md): pull the summary,
validation results, and documented deviations (these belong in the PR body — they tell the reviewer what
was intentional).
- Linked ticket / issue: look for
ACC-…, #123, Fixes #… in the commits/branch name.
- PR template: if
.github/PULL_REQUEST_TEMPLATE.md exists, fill it; else use the default below.
Phase 3 — Push and open the PR
git push -u origin HEAD
gh pr create --base "{base}" --title "{type}: {concise description}" --body "$(cat <<'EOF'
## Summary
{1-2 sentences: what this ticket delivers}
## What changed
{commit summaries}
## Validation
- Tests / type-check / lint: {pass/fail from the implementation report or a fresh run}
- Manual check: {what was exercised, or "pending review"}
## Notes for the reviewer
{documented deviations from the plan — intentional decisions — or "none"}
## Linked
{ticket / issue refs, or "none"}
_Ready for review._
EOF
)"
({type} = feat/fix/refactor/… from the work. Use --draft if the work isn't ready for a real review.)
Output
gh pr view --json number,url,title,baseRefName,headRefName
Report the PR number + URL, the base ← head branches, and "Ready for review → run piv-review-pr <number>, then a
human approves." This is the handoff point: the agent's loop ends at an open PR; review and merge are the gates.
Notes
- Tool-agnostic in spirit: this skill uses GitHub (
gh); the same motion is "open a merge request" on GitLab,
or "mark ready for review" wherever your team works. Solo with no remote? Skip the PR — commit on {base} and
review your own diff before moving on.
- Sets up parallel work: one branch per ticket → one PR per ticket is exactly what makes worktree parallelism
(running independent tickets at once) clean.
