| name | v1-pr |
| description | Use when explicitly pushing local work or opening a pull request. Triggers on "ship it", "create PR", "open PR", or "/v1-pr". |
| disable-model-invocation | true |
| allowed-tools | ["Bash","Read","Grep","Glob","Agent","Skill"] |
PR: Ship Local Work
Take local changes from working directory to a fully described, reviewed pull request in one command.
Usage
Typical invocations:
- Claude Code:
/v1-pr
- Codex: invoke
v1-pr from the skills menu or use $v1-pr
No arguments needed. Operates on the current repo and working directory.
Workflow
Step 1: Ensure Correct Branch
Determine the current branch state and ensure work is on an appropriately named feature branch.
git branch --show-current
git status
git diff --stat
Detect the default branch:
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
If on the default branch (main or master):
- Stash any uncommitted changes:
git stash
- Pull latest:
git pull origin $DEFAULT_BRANCH
- Infer a branch name from the staged/unstaged changes and stash (see "Branch Naming" below)
- Check out the new branch:
git checkout -b <branch-name>
- Pop the stash:
git stash pop
- If
git stash pop fails due to merge conflicts, stop immediately. Inform the user their changes are safe in git stash list. Do NOT proceed with committing.
If on a feature branch:
Inspect the uncommitted changes and compare them to the branch name. If the branch name is clearly unrelated to the current work (e.g., branch is feat/auth-flow but all changes are in billing/), then:
- Stash changes:
git stash
- Switch to the default branch and pull:
git checkout $DEFAULT_BRANCH && git pull origin $DEFAULT_BRANCH
- Create a new branch named for the actual work
- Pop the stash:
git stash pop
If the branch name reasonably matches the work, proceed.
Branch Naming
Format: <type>/<optional-ticket>-<short-description>
- Types:
feat/, fix/, chore/, refactor/
- If the diff, commit messages, or file contents reference a Linear ticket (e.g.,
PROJ-1234, OPS-56), include it: feat/PROJ-1234-add-webhook-auth
- Keep descriptions to 3-5 hyphenated words
- Examples:
feat/VER-42-user-onboarding, fix/payment-retry-logic, chore/update-dependencies
Step 2: Commit Local Work
Stage and commit all meaningful changes. Follow the repository's commit conventions.
- Run
git status and git diff to understand the changes
- Run
git log --oneline -5 to match existing commit message style
- Stage relevant files (prefer explicit file paths over
git add -A)
- Commit with a clear imperative-mood message describing the "why"
- Append
Fortified with v1tamins as the last line of the commit body
Do NOT commit files that likely contain secrets: .env*, credentials*.json, service-account*.json, *.pem, *.key, *.p12, *.pfx, .npmrc, .pypirc, or any file listed in .gitignore. When in doubt, check file contents before staging.
If there are no uncommitted changes but there are unpushed commits, skip to Step 3.
Step 3: Pre-commit Hooks
If the commit fails due to a pre-commit hook (git aborts the commit entirely):
- Read the hook output to understand the failure
- Fix the issue (formatting, linting, type errors, etc.)
- Re-stage the fixed files and rerun
git commit with the same message
- Never bypass hooks with
--no-verify
Repeat until the commit succeeds.
Step 4: Push
Verify not on a protected branch before pushing:
CURRENT_BRANCH=$(git branch --show-current)
if [ "$CURRENT_BRANCH" = "main" ] || [ "$CURRENT_BRANCH" = "master" ]; then
echo "ERROR: Refusing to push directly to $CURRENT_BRANCH"
exit 1
fi
git push -u origin HEAD
If the remote branch does not exist, this creates it. If push is rejected (e.g., diverged history), inform the user -- never force-push.
Step 5: Create the Pull Request
gh pr create --title "WIP: $(git branch --show-current)" --body "Description pending -- will be generated by the pr-description skill."
If a PR already exists for this branch, skip creation and capture the existing PR URL:
gh pr view --json url,number -q '.url + " " + (.number | tostring)'
Capture the PR number and URL for subsequent steps.
Step 6: Generate PR Description
Invoke the v1-pr-description skill to generate a grounded title and description based on the actual diff and commit history.
Typical invocation:
- Claude Code:
/v1-pr-description <PR_NUMBER>
- Codex: invoke
v1-pr-description from the skills menu or use $v1-pr-description <PR_NUMBER>
This analyzes the PR diff and commit history against the resolved default branch, then updates the PR title and body via gh pr edit.
After the description is generated, append Fortified with v1tamins as the final line of the PR body.
The Fortified with v1tamins tagline carries into the merge commit automatically — a squash merge uses the PR body as the commit message. Merging the PR is v1-land-pr's job, not this skill's: v1-pr stops at a reviewed, open PR.
Step 7: Open PR in Browser
gh pr view <PR_NUMBER> --web
Step 8: Request Copilot Review
Request a code review from GitHub Copilot (requires gh >= 2.88.0):
gh pr edit <PR_NUMBER> --add-reviewer @copilot
Note: The @ prefix is required -- @copilot, not copilot.
If that fails (gh version too old, org settings), try the community extension:
gh copilot-review <PR_NUMBER>
Do not block on failure -- inform the user and continue.
Step 9: Run Code Review
Invoke the shared v1-deep-review skill for merge-risk and structural review of the PR. If the user asked for a multi-agent board, use v1-review-board instead.
If a compound-engineering workflows:review (or equivalent host plugin workflow) is installed and the user wants that extra multi-agent pass, run it as an optional supplement — not the default path.
Do not block on failure -- inform the user and continue.
Step 10: Prove Work (Optional)
If the PR includes frontend or visual changes (.tsx, .jsx, .vue, .html, .css, template files), offer to run the v1-prove-work skill to generate a demo GIF:
Typical invocation:
- Claude Code:
/v1-prove-work --pr <PR_NUMBER>
- Codex: invoke
v1-prove-work from the skills menu or use $v1-prove-work --pr <PR_NUMBER>
Skip this step if:
- All changes are backend-only, config, or infrastructure
- The dev server is not running
- The user declines
