| name | suggest-pr |
| description | Suggest a pull request title and description for the current branch. Use when the user wants to open a PR, wants a PR description, or asks what to write for a pull request. |
| disable-model-invocation | true |
| allowed-tools | Bash(git fetch *) Bash(git log *) Bash(git diff *) Bash(git branch *) Bash(git rev-parse *) |
Suggest PR Title and Description
Steps
-
Identify the current branch and refresh the base by running:
git fetch origin
git rev-parse --abbrev-ref HEAD
The base is origin/main (substitute your project's trunk branch if different). Use the remote base so the diff isn't computed against a stale local main.
-
Read all commits on this branch that diverge from the base:
git log --oneline origin/main..HEAD
-
Read the full diff summary against the base:
git diff origin/main...HEAD --stat
And the full diff for more detail:
git diff origin/main...HEAD
-
Suggest a PR title and description following the format below.
Output format
Output everything as rendered markdown directly in the conversation — do not create any files. Use real markdown syntax: ## for section headers, backticks around all file names, function names, and technical identifiers.
**Title:** <type(scope): concise description all lowercase>
## Description
<two or three sentences in natural language explaining the overall goal of this PR and why the changes were made>
## Changelist
- <bullet: what changed and why, in natural language>
- <bullet: what changed and why, in natural language>
- <add more as needed>
Guidelines
- Title: conventional commit format, all lowercase, no period, under 70 characters. Use the appropriate prefix (
feat, fix, refactor, chore, etc.) and include a scope in parentheses matching the area affected (e.g. feat(auth):, fix(api):, refactor(db):). Example: feat(auth): store session tokens in the database.
- Description: high-level context for a reviewer — what problem this solves and why now. Natural language, full sentences.
- Changelist: one bullet per logical change. Keep each bullet short and punchy — one clause, no padding words like "in order to" or "so that". Use backticks around file names and technical identifiers. Do not explain the motivation or downstream effects; just state what changed.
- Honor your project's PR conventions — e.g. whether to include co-author lines. Keep implementation details that belong in inline comments out of the description.
