| name | pull-request |
| description | Prepares and creates a pull request from the current branch targeting dev (or a custom branch via --branch:"<name>"). Inspects all non-merge commits introduced by this branch, generates a clear title, and fills in the PR template automatically. |
Create a pull request for the current branch by following these steps exactly.
Argument parsing
Before doing anything else, check whether the invocation included a --branch:"<name>" argument (e.g. /pull-request --branch:"staging"). If present, use that branch name as the base branch throughout every step below. If absent, default to dev.
Call this value $BASE from this point forward.
Step 1 — Gather branch information
Run all of these in parallel:
git branch --show-current
git merge-base HEAD $BASE
git log --no-merges --format="%H %s" $(git merge-base HEAD $BASE)..HEAD
git diff --stat $(git merge-base HEAD $BASE)...HEAD
git diff --no-merges $(git merge-base HEAD $BASE)...HEAD
Also read the file .github/pull_request_template.md.
Step 2 — Analyze the work
From the outputs above, determine:
- What changed: which files were modified and in what way (feature, fix, refactor, etc.)
- Scope: UI only, logic only, both, tests, docs, etc.
- Type of change: map to one of the checklist items in the template (bug fix, new feature, refactor, tests, docs, release)
Only consider commits that are not merge commits (already filtered in Step 1). Do not include noise from branch merges.
Step 3 — Generate the PR title
Write a concise, descriptive title (under 72 characters) that summarizes the actual work done. Use imperative mood (e.g. "Fix pull-to-refresh behavior on Android", "Add send flow with WDK integration"). Do not include the branch name literally.
Step 4 — Fill in the PR description
Use the PR template as the exact base structure. Fill each section as follows:
DESCRIPTION: Write 2–4 sentences summarizing what was done, why, and any notable implementation decisions. Be specific and professional. No filler phrases.
TYPE OF CHANGE: Replace ◻️ with 🔳 only for the types that actually apply based on the diff. Leave all others as ◻️. Keep all options in the list — do not remove any.
CHANGELOG: List each meaningful change as a bullet point. Be specific (e.g. "Added progressViewOffset to RefreshControl to fix Android pull gesture anchor"). Omit WIP or noise commits.
DEMO UI: Write -- (this cannot be filled automatically).
OBSERVATIONS: Add any relevant implementation notes, known limitations, or follow-up items found during the diff analysis. If none, write --.
RELATED TICKETS: Write -- (ticket links are not available automatically).
RELATED PRs: Write -- (pull request links are not available automatically).
Step 5 — Create the pull request
Run:
gh pr create --base $BASE --title "<generated title>" --body "<filled description>"
Use a heredoc to pass the body to avoid shell escaping issues:
gh pr create --base $BASE --title "..." --body "$(cat <<'EOF'
<filled template content>
EOF
)"
After creation, output the PR URL so it is visible in the conversation.
Arguments
--dry-run — Skip Step 5. Instead, print the generated title and full PR body as a markdown code block so the user can copy and paste manually. Do not run any gh commands.
Rules
- Never invent changes that are not in the diff
- Never skip checklist items from the template — always include the full list
- Only mark checklist items that correspond to real work in the diff
- Do not add AI attribution anywhere in the PR content
- Do not add a "Co-authored-by" or "Generated by" line
- If the branch has no commits beyond
$BASE, stop and inform the user
