| name | pull-request |
| description | Create a GitHub pull request (PR) with proper formatting and content guidelines. Use when creating or updating pull requests/PRs (or GitLab merge requests/MRs, Gerrit change requests/CRs). |
| allowed-tools | Bash(gh:*), mcp__github |
Pull Request
Use these guidelines when creating or updating pull requests (PRs), merge requests (MRs), or change requests (CRs):
Title
- Use
$subject: $summaryformat (e.g.,fix: add timeout to request) - Keep under 50 characters, max 100
- Use imperative mood, lowercase except proper nouns
Body
Use strategy in
context.mdto obtain context about the change if the conversation does not provide enough information.Start with 1-3 sentences summarizing the change. Go straight into the description, without a preceding header.
Use
##sections for larger changes. Include one or more of the following sections as appropriate. Sections can have multiple subsections if subgroups are present.## Issue: Root cause analysis, link existing issues. Use this for bug fixes, which should include a related issue.## Changes: High-level bulleted description of changes made.- Emphasize API and interface changes first.
- Example: Adds
POST /usersendpoint to create users - Example: Updates
User.createto acceptemailparameter. - Example: Handles
404errors inGET /users/{id}.
- Example: Adds
- Do not list modified files by path, line number, etc. Summarize the user impact of changes, do not narrate the code.
- Include refactoring or cleanup changes as separate bullet points.
- Example: Refactors
UserServiceto use dependency injection. - Example: Extracts repeated user getter logic into
UserRepository.
- Example: Refactors
- Emphasize API and interface changes first.
## Testing: Only include if tests were added/modified or if we discussed manual testing steps. Do not repeat obvious statements (❌ "existing tests pass" ❌) or meta-information (❌ "3 unit tests" ❌). Do include, where applicable:- High level summary of any tests added or modified.
- Nw testing patterns or significant coverage changes.
- Checklist of manual test steps as
###.
## References: ONLY include if there are relevant links or related issues.- Bulleted list of links or related issues and code reviews
- Use
Closes #<issue>if the change closes an issue
Workflow
See workflow.md for instructions on how to create a new pull request.