---
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

1. **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`.

2. **Read all commits on this branch** that diverge from the base:
   ```
   git log --oneline origin/main..HEAD
   ```

3. **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
   ```

4. **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.