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 and Changelog 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").
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; the Milestone section is required in every PR body, ticked or not — its
<!-- milestone-target-selection --> markers drive PR automation
- Changelog checkboxes must match CI automation format
1---2name: woocommerce-git-draft-pr3description: Create a high-quality draft PR for the current branch. Use when the user says "create a PR", "draft PR", "open a PR", "make a PR", "push and create PR", or "submit PR".4---5
6# Create Draft PR
7
8Create a concise, reviewer-friendly draft PR from the current branch.
9
10## Dynamic Context
11
12- Current branch: !`git branch --show-current`
13- Commits: !`git log trunk..HEAD --format="%h %s" --reverse 2>/dev/null || echo "No commits ahead of trunk"`
14- Diff stat: !`git diff trunk...HEAD --stat 2>/dev/null`
15- Uncommitted changes: !`git status --short`
16- Existing changelogs: !`git diff trunk...HEAD --name-only -- '*/changelog/*' 2>/dev/null`
17- PR template: !`cat .github/PULL_REQUEST_TEMPLATE.md`
18
19## Procedure
20
21### 1. Preflight and Analyze
22
23Verify from dynamic context: not on trunk (stop if so), commits exist ahead of trunk (stop if none), no uncommitted changes (stop if dirty).
24
25**Base branch**: use `release/*` if the branch was created from one, otherwise `trunk`.
26
27From the dynamic context above (read full diffs only if the stat summary is ambiguous), determine:
28
29- **Change type**: Fix, Add, Update, Dev, Tweak, Performance, or Enhancement
30- **Significance**: Patch (most common), Minor (new features), Major (breaking — rare)
31- **Bug fix?** Look for issue refs in commits/branch name (e.g., `#12345`, `fix/issue-12345`)
32- **UI changes?** Changes in `client/`, `templates/`, CSS/SCSS, JSX/TSX
33- **Plugin-affecting?** Code shipped to users = yes. CI/CD, workflows, tooling, docs = no. This drives the Milestone and Changelog decisions in Step 3.
34
35### 2. Gather Context
36
37Extract issue/PR refs from commits and branch name:
38
39- **Issue ref**: use what's in commits/branch if present; otherwise omit `Closes #` (Linear refs are internal — only reference GitHub issues in PRs).
40- **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.
41- **Motivation**: infer from diff and commit messages. Use the strongest summary you can; don't block on missing context.
42
43### 3. Generate PR Title + Body
44
45**Title** (under 70 chars, verb-first — the repo convention):
46
47- `Fix <what was broken>`, `Add <what>`, or other verb (Restore, Bump, Prepare, etc.)
48- Optional area prefix: `[Email Editor] Fix double margin-top in flex layout`
49- No `fix:`/`feat:` prefixes. No Linear ticket refs — Linear is internal, PRs are public.
50
51**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:
52
53- **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.
54- **Milestone**: tick the auto-assign box only for plugin-affecting changes. The section itself stays — the template marks it do-not-remove.
55- **Changelog entry**:
56 - Plugin-affecting, no changelog files in the diff → tick `Automatically create` with Significance, Type, and a user-facing Message.
57 - Plugin-affecting with changelog files already in the diff → tick `does not require` with the Comment "Created manually."
58 - Not plugin-affecting → tick `does not require` with a Comment explaining why (e.g., "Internal tooling, not shipped to merchants").
59
60After 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 # .`).
61
62### 4. Preview
63
64State the generated title and body before executing.
65
66### 5. Push and Create
67
68```sh
69git push -u origin $(git branch --show-current)
70gh pr create --draft --title "<title>" --base <base-branch> --body "$(cat <<'PRBODY'
71<full PR body>
72PRBODY
73)"
74```
75
76Output the PR URL. If UI changes need screenshots, remind the user.
77
78## Constraints
79
80- No Co-Authored-By lines or self-attribution
81- Never commit code — pushing is fine
82- Preserve the PR template section headings and HTML comments exactly; the Milestone section is required in every PR body, ticked or not — its `<!-- milestone-target-selection -->` markers drive PR automation
83- Changelog checkboxes must match CI automation format
woocommerce