Woocommerce Git Draft Pr

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 changelog, milestone, and PR body complexity — non-plugin PRs use a simplified body (see Step 3).

2. Gather Context from User

Extract issue/PR refs from commits and branch name. Ask the user (combine into one prompt):

• If no issue ref: "Is there a GitHub issue?" (Linear is internal — only reference GitHub issues in PRs)
• If bug fix, no origin PR found: "Which PR introduced this bug?"
• If motivation unclear from code: "What's the context?"

3. Generate PR Title + Body

Use the PR template from the dynamic context above.

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 — depends on whether the change is plugin-affecting:

Non-plugin changes (CI/CD, tooling, docs, .ai/skills/, workflows)

Use a simplified body with only these sections:

• Submission Review Guidelines: Keep as-is from template.
• Changes proposed: 2-3 sentences. Lead with WHY, then WHAT.

Skip Screenshots, Testing instructions, Testing done, Milestone, and Changelog sections entirely.

Plugin-affecting changes

Use the full template:

• Submission Review Guidelines: Keep as-is from template.
• Changes proposed: 2-3 sentences. Lead with WHY, then WHAT. No filler ("This PR addresses..."). Include Closes #1234. if applicable. For bugs: Bug introduced in PR #XXXX. (omit this line entirely if not a bug fix).
• Screenshots: Remove section if no UI changes. For UI changes, use Chrome DevTools MCP to capture screenshots if available; otherwise remind user to add them before marking ready.
• Testing instructions: Concrete numbered steps with expected outcomes. Ask user to verify before finalizing. Each step must be actionable — don't reference links that won't exist yet.
• Testing done: Ask user what testing they've performed.
• Milestone: Check auto-assign [x] if plugin-affecting.
• Changelog: If changelogs already in diff → "does not require" (created manually). Otherwise → "Automatically create" [x] with Significance, Type, and a user-facing Message.

Strip all HTML comments (<!-- -->) and unfilled placeholder lines (e.g., Closes # ., Bug introduced in PR # .) from output.

4. Preview and Confirm

Show the user the generated title and body. Apply any corrections before proceeding.

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 exactly (for plugin-affecting PRs)
• Changelog checkboxes must match CI automation format