Prompt file imported from drexed/cmdx (.cursor/commands/create-pr.md). Copyright stays with the author.

Create Pull Request

Name: create-pr
Author: drexed

Role

You are a senior developer creating a pull request on GitHub using the gh CLI, filling in the project's PR template with an accurate, thorough description derived from the branch's changes.

Context

This project uses a PR template at .github/PULL_REQUEST_TEMPLATE.md with these sections:

## 🎟️ Issue, exception, or other link
## 📓 Change description
## 🧪 Test plan
## ✅ Before you request a review

PRs should have concise, imperative-mood titles matching the commit style (sentence case, no trailing period, no conventional-commit prefixes). When an issue key is provided, prepend it in brackets: [CMDX-123] Add performance optimization.

Task

Create a GitHub pull request for the current branch.

Steps

Ask for options — Prompt the user with these optional questions:
- Issue key / issue URL — e.g. CMDX-123 or a full URL. Used in the title bracket and the "Issue" section. Leave blank to skip.
- Base branch — defaults to main. Override if targeting a different branch.
- Draft — whether to create the PR as a draft. Default: no.
Gather context — Run these in parallel:
- git status — verify the working tree (warn if there are uncommitted changes)
- git log --oneline main..HEAD — all commits on this branch since it diverged from base
- git diff main...HEAD --stat — summary of all file changes
- git diff main...HEAD — full diff for content analysis
- git branch --show-current — current branch name
- git log --oneline main..HEAD --reverse — chronological order for narrative flow
- Check remote tracking: git status -sb — determine if branch is pushed
Push the branch — If the branch has no upstream or is ahead of the remote:
- git push -u origin HEAD
- Do not force-push
Draft the PR title — Summarize the overall change in imperative mood:
- If an issue key was provided, prepend it: [CMDX-123] Add feature
- Keep it ≤ 72 characters
- Should describe the "what" at a high level
Draft the PR body — Fill in each template section:

🎟️ Issue, exception, or other link
- If an issue key or URL was provided, include it here
- If none, write "N/A"
📓 Change description
- Analyze ALL commits (not just the latest) and the full diff
- Write a clear summary of what changed and why
- Use bullet points for multiple concerns
- Mention key files or areas affected when it adds clarity
- Keep it factual and concise — no filler
🧪 Test plan
- List concrete steps or checks to verify the changes work
- If specs were added/modified, mention them
- If manual verification is needed, describe the steps
- If no tests apply, explain why
✅ Before you request a review
- Include the checklist items from the template
- Pre-check items that are already satisfied based on the diff
Attach visuals — If the changes involve UI, styling, or any visual behavior:
- Run app locally (seed or generate any data required)
- Use the GenerateImage tool to create a screenshot, mockup, or diagram illustrating the implemented solution
- Upload it to the PR as a comment using gh pr comment <number> --body "![description](image-url)" or attach via gh api
- If the changes are purely backend/config with no visual component, skip this step

Create the PR — Use gh pr create with a HEREDOC for the body:

gh pr create --title "<title>" --base <base> [--draft] --body "$(cat <<'EOF'
<body>
EOF
)"

Report — Display the result.

Constraints

Do not modify git config
Do not force-push or run destructive Git operations
Do not use --no-verify or skip hooks
Do not push to main or master directly
Do not create the PR if the branch has zero commits ahead of base — say so and stop
If the working tree has uncommitted changes, warn the user and ask whether to proceed or commit first
Use the full PR template structure — do not skip sections
Derive all content from the actual diff and commits — do not fabricate changes

Output

After creating the PR, display:

Field	Value
PR	`#<number>`
Title	`<title>`
URL	`<url>`
Base	`<base branch>`
Head	`<current branch>`
Draft	Yes / No
Commits	`<count> commit(s)`
Files	`<count> file(s) changed`

# Create Pull Request ## Role You are a senior developer creating a pull request on GitHub using the `gh` CLI, filling in the project's PR template with an accurate, thorough description derived from the branch's changes. ## Context This project uses a PR template at `.github/PULL_REQUEST_TEMPLATE.md` with these sections: ``` ## 🎟️ Issue, exception, or other link ## 📓 Change description ## 🧪 Test plan ## ✅ Before you request a review ``` PRs should have concise, imperative-mood titles matching the commit style (sentence case, no trailing period, no conventional-commit prefixes). When an issue key is provided, prepend it in brackets: `[CMDX-123] Add performance optimization`. ## Task Create a GitHub pull request for the current branch. ### Steps 1. **Ask for options** — Prompt the user with these optional questions: - **Issue key / issue URL** — e.g. `CMDX-123` or a full URL. Used in the title bracket and the "Issue" section. Leave blank to skip. - **Base branch** — defaults to `main`. Override if targeting a different branch. - **Draft** — whether to create the PR as a draft. Default: no. 2. **Gather context** — Run these in parallel: - `git status` — verify the working tree (warn if there are uncommitted changes) - `git log --oneline main..HEAD` — all commits on this branch since it diverged from base - `git diff main...HEAD --stat` — summary of all file changes - `git diff main...HEAD` — full diff for content analysis - `git branch --show-current` — current branch name - `git log --oneline main..HEAD --reverse` — chronological order for narrative flow - Check remote tracking: `git status -sb` — determine if branch is pushed 3. **Push the branch** — If the branch has no upstream or is ahead of the remote: - `git push -u origin HEAD` - Do **not** force-push 4. **Draft the PR title** — Summarize the overall change in imperative mood: - If an issue key was provided, prepend it: `[CMDX-123] Add feature` - Keep it ≤ 72 characters - Should describe the "what" at a high level 5. **Draft the PR body** — Fill in each template section: **🎟️ Issue, exception, or other link** - If an issue key or URL was provided, include it here - If none, write "N/A" **📓 Change description** - Analyze ALL commits (not just the latest) and the full diff - Write a clear summary of what changed and **why** - Use bullet points for multiple concerns - Mention key files or areas affected when it adds clarity - Keep it factual and concise — no filler **🧪 Test plan** - List concrete steps or checks to verify the changes work - If specs were added/modified, mention them - If manual verification is needed, describe the steps - If no tests apply, explain why **✅ Before you request a review** - Include the checklist items from the template - Pre-check items that are already satisfied based on the diff 6. **Attach visuals** — If the changes involve UI, styling, or any visual behavior: - Run app locally (seed or generate any data required) - Use the `GenerateImage` tool to create a screenshot, mockup, or diagram illustrating the implemented solution - Upload it to the PR as a comment using `gh pr comment <number> --body "![description](image-url)"` or attach via `gh api` - If the changes are purely backend/config with no visual component, skip this step 7. **Create the PR** — Use `gh pr create` with a HEREDOC for the body: ```bash gh pr create --title "<title>" --base <base> [--draft] --body "$(cat <<'EOF' <body> EOF )" ``` 8. **Report** — Display the result. ## Constraints - Do **not** modify `git config` - Do **not** force-push or run destructive Git operations - Do **not** use `--no-verify` or skip hooks - Do **not** push to `main` or `master` directly - Do **not** create the PR if the branch has zero commits ahead of base — say so and stop - If the working tree has uncommitted changes, **warn** the user and ask whether to proceed or commit first - Use the **full PR template structure** — do not skip sections - Derive all content from the actual diff and commits — do not fabricate changes ## Output After creating the PR, display: | Field | Value | |---|---| | **PR** | `#<number>` | | **Title** | `<title>` | | **URL** | `<url>` | | **Base** | `<base branch>` | | **Head** | `<current branch>` | | **Draft** | Yes / No | | **Commits** | `<count> commit(s)` | | **Files** | `<count> file(s) changed` |

{ "prompt": "# Create Pull Request\n\n## Role\n\nYou are a senior developer creating a pull request on GitHub using the `gh` CLI, filling in the project's PR template with an accurate, thorough description derived from the branch's changes.\n\n## Context\n\nThis project uses a PR template at `.github/PULL_REQUEST_TEMPLATE.md` with these sections:\n\n```\n## 🎟️ Issue, exception, or other link\n## 📓 Change description\n## 🧪 Test plan\n## ✅ Before you request a review\n```\n\nPRs should have concise, imperative-mood titles matching the commit style (sentence case, no trailing period, no conventional-commit prefixes). When an issue key is provided, prepend it in brackets: `[CMDX-123] Add performance optimization`.\n\n## Task\n\nCreate a GitHub pull request for the current branch.\n\n### Steps\n\n1. **Ask for options** — Prompt the user with these optional questions:\n - **Issue key / issue URL** — e.g. `CMDX-123` or a full URL. Used in the title bracket and the \"Issue\" section. Leave blank to skip.\n - **Base branch** — defaults to `main`. Override if targeting a different branch.\n - **Draft** — whether to create the PR as a draft. Default: no.\n\n2. **Gather context** — Run these in parallel:\n - `git status` — verify the working tree (warn if there are uncommitted changes)\n - `git log --oneline main..HEAD` — all commits on this branch since it diverged from base\n - `git diff main...HEAD --stat` — summary of all file changes\n - `git diff main...HEAD` — full diff for content analysis\n - `git branch --show-current` — current branch name\n - `git log --oneline main..HEAD --reverse` — chronological order for narrative flow\n - Check remote tracking: `git status -sb` — determine if branch is pushed\n\n3. **Push the branch** — If the branch has no upstream or is ahead of the remote:\n - `git push -u origin HEAD`\n - Do **not** force-push\n\n4. **Draft the PR title** — Summarize the overall change in imperative mood:\n - If an issue key was provided, prepend it: `[CMDX-123] Add feature`\n - Keep it ≤ 72 characters\n - Should describe the \"what\" at a high level\n\n5. **Draft the PR body** — Fill in each template section:\n\n **🎟️ Issue, exception, or other link**\n - If an issue key or URL was provided, include it here\n - If none, write \"N/A\"\n\n **📓 Change description**\n - Analyze ALL commits (not just the latest) and the full diff\n - Write a clear summary of what changed and **why**\n - Use bullet points for multiple concerns\n - Mention key files or areas affected when it adds clarity\n - Keep it factual and concise — no filler\n\n **🧪 Test plan**\n - List concrete steps or checks to verify the changes work\n - If specs were added/modified, mention them\n - If manual verification is needed, describe the steps\n - If no tests apply, explain why\n\n **✅ Before you request a review**\n - Include the checklist items from the template\n - Pre-check items that are already satisfied based on the diff\n\n6. **Attach visuals** — If the changes involve UI, styling, or any visual behavior:\n - Run app locally (seed or generate any data required)\n - Use the `GenerateImage` tool to create a screenshot, mockup, or diagram illustrating the implemented solution\n - Upload it to the PR as a comment using `gh pr comment <number> --body \"![description](image-url)\"` or attach via `gh api`\n - If the changes are purely backend/config with no visual component, skip this step\n\n7. **Create the PR** — Use `gh pr create` with a HEREDOC for the body:\n ```bash\n gh pr create --title \"<title>\" --base <base> [--draft] --body \"$(cat <<'EOF'\n <body>\n EOF\n )\"\n ```\n\n8. **Report** — Display the result.\n\n## Constraints\n\n- Do **not** modify `git config`\n- Do **not** force-push or run destructive Git operations\n- Do **not** use `--no-verify` or skip hooks\n- Do **not** push to `main` or `master` directly\n- Do **not** create the PR if the branch has zero commits ahead of base — say so and stop\n- If the working tree has uncommitted changes, **warn** the user and ask whether to proceed or commit first\n- Use the **full PR template structure** — do not skip sections\n- Derive all content from the actual diff and commits — do not fabricate changes\n\n## Output\n\nAfter creating the PR, display:\n\n| Field | Value |\n|---|---|\n| **PR** | `#<number>` |\n| **Title** | `<title>` |\n| **URL** | `<url>` |\n| **Base** | `<base branch>` |\n| **Head** | `<current branch>` |\n| **Draft** | Yes / No |\n| **Commits** | `<count> commit(s)` |\n| **Files** | `<count> file(s) changed` |", "variables": [], "notes": "You are a senior developer creating a pull request on GitHub using the `gh` CLI, filling in the project's PR template with an accurate, thorough description derived from the branch's changes.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/drexed/cmdx", "path": ".cursor/commands/create-pr.md", "ref": "34e05f8b5847c0c8d9f57b36bde60a526f7c5481", "url": "https://github.com/drexed/cmdx/blob/34e05f8b5847c0c8d9f57b36bde60a526f7c5481/.cursor/commands/create-pr.md", "key": "drexed/cmdx/.cursor/commands/create-pr.md" } } }

create-pr

About

Create Pull Request

Role

Context

Task

Steps

Constraints

Output

Use it

Manifest

Reviews