|
| 1 | +--- |
| 2 | +name: create-pull-request |
| 3 | +description: "Create a GitHub Pull Request from the current or specified branch. Use when: opening a PR, submitting code for review, creating a draft PR, publishing a branch as a pull request, proposing changes to a repository." |
| 4 | +argument-hint: "Optionally specify a title, base branch, or whether to create as a draft" |
| 5 | +--- |
| 6 | + |
| 7 | +# Create a GitHub Pull Request |
| 8 | + |
| 9 | +Gather the necessary information, prepare a clear title and description, then call the tool to open the pull request. |
| 10 | + |
| 11 | +## When to Use |
| 12 | + |
| 13 | +- The user wants to open a PR for their current or a specified branch |
| 14 | +- The user has finished a feature or fix and wants to submit it for review |
| 15 | +- The user wants to create a draft PR to share work in progress |
| 16 | +- The user asks to "open a PR", "create a pull request", or "submit for review" |
| 17 | + |
| 18 | +## Procedure |
| 19 | + |
| 20 | +### 1. Gather Information |
| 21 | + |
| 22 | +Determine the required parameters before calling the tool: |
| 23 | + |
| 24 | +- **Head branch**: If the user has not specified a branch, use workspace or git context to find the current branch name. Do not use `owner:branch` format - pass just the branch name (e.g. `my-feature`). |
| 25 | +- **Base branch**: If the user has not specified a base branch, omit it and let the tool use the repository's default branch. |
| 26 | +- **Title**: If the user has not provided a title, derive one from the branch name, recent commits, or the user's description of their work (see Best Practices below). |
| 27 | +- **Body**: If the user has not provided a description, prepare a concise summary of what changed and why (see Best Practices below). |
| 28 | +- **Draft**: Ask or infer whether the PR should be a draft. Default to non-draft unless the user indicates the work is not ready for review. |
| 29 | + |
| 30 | +### 2. Check for Uncommitted or Unpushed Changes |
| 31 | + |
| 32 | +Before creating the PR, inspect the working tree state. If you need to run git commands, give an explanation for why the command needs to be run. |
| 33 | + |
| 34 | +1. **Check for uncommitted changes**: Use the git tool or VS Code SCM context to determine whether there are staged or unstaged file changes. If yes: |
| 35 | + - Ask the user if they want to commit these changes before opening the PR. |
| 36 | + - If they do, help them write a commit message and commit the changes (`git add -A && git commit -m "<message>"`). |
| 37 | + - If they decline, proceed only if there are already commits on the branch that are ahead of the base - otherwise there is nothing to put in the PR. |
| 38 | + |
| 39 | +2. **Check for unpushed commits**: Determine whether the local branch has commits that have not been pushed to the remote (i.e. the branch is ahead of its upstream). If yes: |
| 40 | + - Ask the user if they want to push before opening the PR, or let them know the tool will attempt to push automatically if needed. |
| 41 | + - If pushing manually is preferred, run `git push` (or `git push --set-upstream origin <branch>` if no upstream is set yet) before calling the tool. |
| 42 | + |
| 43 | +3. **Confirm the branch is on the remote**: The `create_pull_request` tool requires the head branch to be present on the remote. If it is not, push it first. |
| 44 | + |
| 45 | +If all changes are already committed and pushed, proceed directly to the next step. |
| 46 | + |
| 47 | +### 3. Prepare PR Details |
| 48 | + |
| 49 | +Write a good title and description if the user has not provided them: |
| 50 | + |
| 51 | +**Title**: Use imperative mood, keep it under 72 characters, and describe *what* the PR does (e.g. `Add retry logic for failed API requests`). |
| 52 | + |
| 53 | +**Body**: Include: |
| 54 | +- A short summary of what changed and why |
| 55 | +- Any relevant issue references (e.g. `Fixes #123`) |
| 56 | +- Notable implementation decisions, if useful for the reviewer |
| 57 | + |
| 58 | +### 4. Call the Tool |
| 59 | + |
| 60 | +Use the `github-pull-request_create_pull_request` tool with the gathered parameters: |
| 61 | + |
| 62 | +``` |
| 63 | +github-pull-request_create_pull_request({ |
| 64 | + title: '<descriptive title>', |
| 65 | + head: '<branch-name>', // branch name only, not owner:branch |
| 66 | + body: '<description>', // optional but recommended |
| 67 | + base: '<base-branch>', // optional; omit to use repo default |
| 68 | + draft: false, // set true for work-in-progress |
| 69 | + headOwner: '<owner>', // optional; omit if same as repo owner |
| 70 | + repo: { owner: '<owner>', name: '<repo>' } // optional |
| 71 | +}) |
| 72 | +``` |
| 73 | + |
| 74 | +### 5. Confirm Result |
| 75 | + |
| 76 | +After the tool returns successfully: |
| 77 | + |
| 78 | +- Report the PR number and URL to the user as a markdown link. The link should be a VS Code URI like `vscode-insiders://github.vscode-pull-request-github/open-pull-request-webview?uri=https://github.com/microsoft/vscode-css-languageservice/pull/460` or `vscode://github.vscode-pull-request-github/open-pull-request-webview?uri=https://github.com/microsoft/vscode-css-languageservice/pull/460`. |
| 79 | +- Mention the base branch the PR targets. |
| 80 | +- If the PR was created as a draft, remind the user to mark it ready for review when appropriate. |
| 81 | + |
| 82 | +## Best Practices |
| 83 | + |
| 84 | +### Titles |
| 85 | +- Use the imperative mood: `Fix`, `Add`, `Update`, `Remove`, `Refactor` - not `Fixed`, `Adding`, etc. |
| 86 | +- Be specific: `Fix null pointer in user login flow` beats `Fix bug`. |
| 87 | +- Keep it under 72 characters so it displays cleanly in GitHub and email notifications. |
| 88 | + |
| 89 | +### Descriptions |
| 90 | +- Start with a one-sentence summary. |
| 91 | +- Explain *why* the change is needed, not just *what* it does - reviewers benefit from context. |
| 92 | +- Reference related issues with `Fixes #<number>` or `Closes #<number>` to auto-close them on merge. |
| 93 | +- If the change is large, add a brief list of the main files or components touched. |
| 94 | + |
| 95 | +### Draft PRs |
| 96 | +- Use `draft: true` when the code is not yet ready for formal review (e.g. work in progress, awaiting feedback on approach, CI not yet passing). |
| 97 | +- Draft PRs are visible to collaborators but will not show as review-requested until marked ready. |
| 98 | +- Suggest using a draft when the user mentions they are still working on it or just want early feedback. |
0 commit comments