description: Generate a GitHub PR title and summary from all branch changes, including Linear issue and Figma links when available.
description: Generate a GitHub PR title and summary from all branch changes, including Linear issue and Figma links when available. When targeting staging, generates a release changelog instead.
If it doesn't exist, ask the user which branch to diff against.
### Step 1.5: Detect Changelog Mode
Switch to **Changelog Mode** (skip to the Changelog Mode section below) if ANY of these are true:
- The base branch argument is or contains `staging` (e.g., `staging`, `release/staging-2026-04-09`)
- The **current branch** name contains `staging` or matches `release/staging-*`
- The user explicitly asks for a changelog or release notes
When changelog mode activates and no explicit base branch was provided, auto-detect the base by diffing against `dev`. If the current branch *is*`dev`, diff against `main`.
Otherwise, continue with the normal PR summary workflow.
### Step 2: Gather All Branch Changes
Run these commands to understand the FULL scope of changes on this branch (not just the latest commit):
@@ -222,3 +236,130 @@ In both cases, if there were uncommitted changes found in Step 2, warn the user
- Keep the summary concise. The diff is available in the PR; the summary should help reviewers understand intent and scope quickly.
- Always ask before creating or updating a PR. Never run `gh pr create` or `gh pr edit` without user confirmation.
- Never run `git push`. The user handles pushing themselves. If the branch is not pushed, remind them to push first.
---
## Changelog Mode
This mode activates when the base branch is `staging`. It generates user-facing release notes from PRs merged into the current branch since it diverged from staging, focused on mobile app changes.
### Changelog Step 1: Determine the Range
Determine the comparison base. The goal is to find what's new on the staging/release branch:
1. If a specific base branch was provided and exists, use it.
2. If the current branch is a staging/release branch (e.g., `release/staging-*`), diff against `dev`.
3. If the current branch is `dev`, diff against `main`.
- **Removed** — removed features or deprecated functionality
- **Internal** — refactors, renames, dependency updates (collapse into a single bullet or omit if no user-facing impact)
Use the PR titles, Linear issue titles, and the actual diff to write entries. Each entry should be:
- Written for a non-technical audience (app users / stakeholders)
- One line, focused on the user-visible outcome
- Free of implementation details (no file paths, function names, or technical jargon)
### Changelog Step 6: Generate the Changelog
Output using this format:
```markdown
## What's New — [version or date range]
### New
- [feature description]
### Improved
- [improvement description]
### Fixed
- [fix description]
### Removed
- [removal description]
---
<details>
<summary>Internal changes</summary>
- [internal change]
</details>
### Linear Issues
- [SELF-XXXX](url) — [title]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
```
Omit any category that has no entries. The "Internal changes" section is collapsed by default.
If no version tag is available, use the date range of the merged PRs (e.g., "Mar 28 – Apr 9, 2026").
### Changelog Step 7: Check for Existing PR
Same as Step 8 in the normal flow — check for an existing PR, show the generated changelog, and ask the user before creating or updating. Use the changelog as the PR body instead of the normal summary format.
For the PR title in changelog mode, use: `Release: [version or date range summary]` (e.g., `Release: account recovery, nav fixes, platform renaming`).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Justin Hernandez