Create Draft PR

Create a concise, reviewer-friendly draft PR from the current branch.

Dynamic Context

• Current branch: !git branch --show-current
• Commits: !git log trunk..HEAD --format="%h %s" --reverse 2>/dev/null || echo "No commits ahead of trunk"
• Diff stat: !git diff trunk...HEAD --stat 2>/dev/null
• Uncommitted changes: !git status --short
• Existing changelogs: !git diff trunk...HEAD --name-only -- '*/changelog/*' 2>/dev/null
• PR template: !cat .github/PULL_REQUEST_TEMPLATE.md

Procedure

1. Preflight and Analyze

Verify from dynamic context: not on trunk (stop if so), commits exist ahead of trunk (stop if none), no uncommitted changes (stop if dirty).

Base branch: use release/* if the branch was created from one, otherwise trunk.

From the dynamic context above (read full diffs only if the stat summary is ambiguous), determine:

• Change type: Fix, Add, Update, Dev, Tweak, Performance, or Enhancement
• Significance: Patch (most common), Minor (new features), Major (breaking — rare)
• Bug fix? Look for issue refs in commits/branch name (e.g., #12345, fix/issue-12345)
• UI changes? Changes in client/, templates/, CSS/SCSS, JSX/TSX
• Plugin-affecting? Code shipped to users = yes. CI/CD, workflows, tooling, docs = no. This drives the Milestone, Changelog, and Release Communication decisions in Step 3.

2. Gather Context

Extract issue/PR refs from commits and branch name:

• Issue ref: use what's in commits/branch if present; otherwise omit Closes # (Linear refs are internal — only reference GitHub issues in PRs).
• Bug-fix origin PR: if a bug fix and no PR ref is in the diff/commits, search history (git log -S on touched lines) to find the introducing PR; omit Bug introduced in PR #XXXX. if not found.
• Motivation: infer from diff and commit messages. Use the strongest summary you can; don't block on missing context.

3. Generate PR Title + Body

Title (under 70 chars, verb-first — the repo convention):

• Fix <what was broken>, Add <what>, or other verb (Restore, Bump, Prepare, etc.)
• Optional area prefix: [Email Editor] Fix double margin-top in flex layout
• No fix:/feat: prefixes. No Linear ticket refs — Linear is internal, PRs are public.

Body — fill in .github/PULL_REQUEST_TEMPLATE.md (loaded in dynamic context above) section by section, in order. The template's HTML comments describe what each section is for — follow them as the per-section instructions. Repo-specific rules that the template doesn't carry, layered on top:

• Changes proposed: 2-3 sentences. Lead with WHY, then WHAT. No filler ("This PR addresses..."). Drop the Closes # . line if you don't have a GitHub issue ref. Drop the Bug introduced in PR # . line if not a bug fix or origin PR unknown.
• Milestone: tick the auto-assign box only for plugin-affecting changes. The section itself stays — the template marks it do-not-remove.
• Changelog entry:
  • Plugin-affecting, no changelog files in the diff → tick Automatically create with Significance, Type, and a user-facing Message.
  • Plugin-affecting with changelog files already in the diff → tick does not require with the Comment "Created manually."
  • Not plugin-affecting → tick does not require with a Comment explaining why (e.g., "Internal tooling, not shipped to merchants").
• Release Communication: tick Feature Highlight for user-visible features merchants will notice, or Developer Advisory for changes affecting extension/theme developers (hook signatures, deprecations, REST API field changes). Otherwise leave both unchecked. Make sure you surface to the human you are working with when you mark either of these as checked, and emphasize they need to review the posted draft after the automation to validate the output.

After filling, keep the template's HTML comments (<!-- -->) — they support PR automation and GitHub tests. Remove only unfilled placeholder lines that are actual visible placeholders (e.g., Closes # ., Bug introduced in PR # .).

4. Preview

State the generated title and body before executing.

5. Push and Create

git push -u origin $(git branch --show-current)
gh pr create --draft --title "<title>" --base <base-branch> --body "$(cat <<'PRBODY'
<full PR body>
PRBODY
)"

Output the PR URL. If UI changes need screenshots, remind the user.

Constraints

• No Co-Authored-By lines or self-attribution
• Never commit code — pushing is fine
• Preserve the PR template section headings and HTML comments exactly
• Changelog checkboxes must match CI automation format