pr

name	pr
description	Create a pull request

Create a pull request

I'll create a pull request for the current branch by following these steps. If any steps fail, stop.

Arguments:

• reviewed — skip the internal code-reviewer pass (step 4); use this when the change has already been code-reviewed and converged (e.g. /deliver's Phase 3 already ran /review-changes). The review is also skipped automatically when the diff touches no *.swift.
• base=<sha> — a known-green base SHA for the fast gate (step 3): a commit at which the full build-for-testing + test + test-snapshots gate already passed on this identical tree. When the delta since it is docs-only and it is still an ancestor of HEAD, the build/test/snapshot legs are skipped (lint still runs). /deliver passes its Phase 3 green-gate SHA here. Omitted → the fast gate keys on origin/main as today.

1. Commit all outstanding work. Formatting is applied automatically by the PostToolUse hook as files are edited, so there is no separate format step. Run git status; if the working tree has any uncommitted/unstaged changes, stage and commit them — the PR reflects committed history only, so anything left uncommitted is missing from the PR. First verify no secrets, .env, or build artifacts are included (.env must stay gitignored; check git status before git add). Use a descriptive gitmoji message. If the tree is already clean (e.g. work was committed during /deliver), this is a no-op.

2. Rebase onto the latest origin/main. Fetch the remote and rebase the feature branch directly onto origin/main — do this before the gate so the gate (and the eventual PR) reflects the real merge result, not stale code:

   git fetch origin
   git rebase origin/main
   

   • Rebase onto origin/main, not local main — this is worktree-safe. A /deliver runs inside a git worktree, and git checkout main there fails (fatal: 'main' is already used by worktree …) whenever the main checkout is on main; rebasing onto origin/main avoids checking main out at all and uses the true remote base directly.
   • If git rebase reports conflicts, stop, resolve them, then continue. Never skip or force past a conflict you don't understand.
   • The rebase rewrites the branch tip, so a branch that was already pushed needs git push --force-with-lease at the push step below.
   • Already branched off an up-to-date origin/main with nothing to replay → fast no-op.

3. The gate — run in order, stop on any failure (the rebase above means this runs against the post-merge tree). Scale it to the diff first:

   • Docs-only fast gate. When the diff touches no build- or test-affecting files — no *.swift and none of Makefile, Package.swift/Package.resolved, *.xctestplan, *.xcconfig, *.pbxproj, *.xcstrings, or .github/workflows/** — the build/test legs have nothing to exercise: run make lint only and skip the rest of this step. Detect with:

     git diff --name-only origin/main...HEAD \
       | grep -qE '\.swift$|Makefile|Package\.(swift|resolved)$|\.xctestplan$|\.xcconfig$|\.pbxproj|\.xcstrings$|^\.github/workflows/' \
       && echo "code/build touched → full gate" \
       || echo "docs-only → make lint only"
     

     The PR's own CI still runs its full matrix regardless — this only trims the local gate; it never lowers what actually guards main. When in doubt, run the full gate.

   • Known-green-base fast gate (only when base=<sha> was passed). The plain docs-only gate above keys on origin/main — but the delta since the last green gate can be docs-only even when the whole PR diff has Swift (e.g. /deliver has already gated the tree green in Phase 3, and the only commits since are the capture

     • retro .md). When base=<sha> is supplied and both hold — (a) git merge-base --is-ancestor <base> HEAD succeeds (the rebase did not rewrite the base, so it was a genuine no-op and still describes this tree), and (b) git diff --name-only <base> HEAD touches no build-affecting file (same extension set as the docs-only gate above) — run make lint + the new-file --no-cache re-lint and skip build/test/snapshot. Detect with:

     if git merge-base --is-ancestor "" HEAD \
       && ! git diff --name-only  HEAD \
            | grep -qE ; 
        
     
        
     
     

4. Code review — skip this step entirely if reviewed was passed or the diff touches no *.swift. Otherwise spawn the code-reviewer agent to review all changes, following .github/CODE_REVIEW.md. Pass it:

   • The full diff: git diff origin/main...HEAD
   • The list of changed files: git diff --name-only origin/main...HEAD
   • Instruct it to read full files (not just diff hunks) and compare with sibling implementations for pattern consistency

5. Summarize the code review findings:

   • List any critical or high-severity issues that should be addressed
   • List any medium-severity suggestions for improvement
   • Note any low-severity or stylistic recommendations

6. If there are critical/high-severity issues:

   • Recommend specific changes needed
   • Ask user for confirmation before proceeding (fix issues or continue anyway)
   • If user wants to fix issues, stop and let them address the feedback

7. Ensure a clean working tree before pushing. Re-run git status; commit anything still outstanding (review fixes from steps 4–6, or gate fixes) so the push includes everything. Then run git diff origin/main...HEAD to understand all changes.

8. Analyze the commits and changes to generate an appropriate title and summary

9. Push the current branch to remote using git push (not gh CLI, which bypasses webhooks/workflows) — use git push --force-with-lease if you rebased in step 2.

10. Create a PR using gh pr create with:

    • IMPORTANT: Title MUST start with a gitmoji prefix (e.g., "✨ Add new feature", "🐛 Fix bug", "📚 Improve documentation")
      • Refer to https://gitmoji.dev to use the correct emoji
      • Common: ✨ feature, 🐛 bugfix, ♻️ refactor, 🧪 tests, 📚 docs, 🔧 config, 🎨 style
    • A comprehensive summary with bullet points
    • Proper formatting with sections (Summary, Changes, Benefits, etc.)

The PR will include the Claude Code attribution footer.

$ARGUMENTS