---
description: Write a pull request description from the commits and diff on this branch
argument-hint: [base-branch]
allowed-tools:
  - Bash(git diff *)
  - Bash(git log *)
  - Bash(git merge-base *)
  - Bash(git branch *)
  - Bash(git rev-parse *)
  - Read
  - Grep
  - Glob
---

Base branch: use `$ARGUMENTS` if given, otherwise `origin/main`, falling back to `main`, `origin/master`, `master`.

## Steps

1. Run `git merge-base HEAD <base>` and use the result as `BASE`.
2. Collect:
   - `git log --format='%h %s%n%b' BASE..HEAD`
   - `git diff --stat BASE...HEAD`
   - `git diff BASE...HEAD`
   - `git branch --show-current`
3. If there are no commits beyond the base, say so and stop.
4. Read changed files in full where the diff alone does not explain the purpose.
5. If `.github/pull_request_template.md` (or `.github/PULL_REQUEST_TEMPLATE.md`, or `docs/pull_request_template.md`) exists, use its headings and fill them in. Otherwise use the layout below.

## Default layout

```
## Summary
<1-3 sentences: what this PR does, from the user's or system's point of view>

## Why
<the problem or goal. Use commit bodies and code comments as sources. If the reason is not in the branch, write "Context: <ask the author>" instead of guessing.>

## Changes
- <area>: <what changed> (`path`)
Start review with: `<the 1-3 files that carry the core logic>`

## Needs attention
<only items that apply>
- Database migrations: <file, what it does>
- New or changed environment variables / config keys
- Feature flags
- Dependency additions or major upgrades
- Breaking changes to APIs, events, CLI or file formats
- Security-relevant changes (auth, permissions, input handling, secrets)

## How to test
1. <concrete steps or commands, e.g. `npm test -- billing`, or a manual flow>

## Risk and rollback
<what could go wrong, blast radius, and how to roll back (revert safe? migration reversible?)>

## Screenshots
<only if UI files changed: "Add before/after screenshots">
```

## Rules

- Do not invent issue or ticket numbers. Reference one only if it appears in the branch name or commit messages.
- Do not claim tests pass unless you ran them in this session.
- Plain language. No filler. Omit empty sections.
- Output the description in one fenced `markdown` block.
- If the user then asks to create or update the PR, write the body to a temporary file and use `gh pr create --base <base> --title "<title>" --body-file <file>` or `gh pr edit --body-file <file>`. Ask before running it.