---
name: create-pr
description: Generate a pull request title and description from the current branch's commits. Writes a warm, personality-driven summary paragraph and detailed technical bullets.
---

# Create PR Description

Generate a pull request title and description with personality — the kind that makes someone smile while learning exactly what changed.

## Instructions

### 1. Gather context (do ALL of these)

Run these commands to build a complete picture before writing anything:

```bash
# Commit overview
git log main..HEAD --oneline --stat

# Full diff stat for file-level scope
git diff main..HEAD --stat

# Actual code changes — read the diff, don't just skim filenames
git diff main..HEAD
```

If the full diff is too large, diff individual areas (backend routes, frontend, storage, etc.) in batches. You must understand **what the code actually does**, not just which files were touched.

### 2. Write `pr.md`

Write a `pr.md` file at the repository root with this structure:

```markdown
# <Title>

## Summary

<A single flowing paragraph — warm, conversational, technically precise. Tell the story of what this PR does and why it matters. Weave in the key changes naturally. Think "engineer telling a friend about their week" not "changelog". Name actual classes, functions, and patterns but keep it readable as prose.>

## Technical details

- Detail 1
- Detail 2
- ...
```

### Style Rules

#### Title
- Imperative mood, start with a verb (Add, Fix, Refactor, etc.)
- Summarize the entire PR scope — not just one commit

#### Summary paragraph
- **One flowing paragraph**, not bullets. This is a narrative.
- **Start with personality.** Open with something that makes the reader smile — a cheerful greeting, a silly observation, a lighthearted joke, a warm "hope your day is going well" vibe. Not forced, just human. Examples of the energy (don't copy these literally, make up your own each time):
  - "This one's mostly about cleaning house."
  - "Turns out the type checker was right to complain."
  - A playful metaphor about what the code was doing wrong
  - A wry observation about the state of things before this PR
- **Stay technically precise inside the warmth.** Name the actual things — "`get_or_create_chat` had a race condition", not "fixed some database stuff". The personality is in *how* you describe the real changes, not in being vague.
- **Cover all major change areas** in the paragraph — security, architecture, bug fixes, refactors, new features. Weave them into the story naturally.
- **Keep it engaging end-to-end.** Don't front-load all the fun and then go dry. Sprinkle personality throughout — a vivid verb here, a dry quip there, an analogy that makes a complex change click.

#### Technical details
- One bullet per discrete change. Be specific — name files, classes, functions, patterns.
- Format: `backtick code references` for identifiers, plain text for descriptions
- Every meaningful change in the diff must have a bullet. If a change touches security (CORS, auth, SQL injection), error handling, accessibility, or concurrency, it gets its own bullet — do not bury these.
- Bullets should describe the mechanism, not just the intent. "Race condition in `get_or_create_chat` fixed by moving creation inside the lookup session" is good. "Fix database issues" is not.
- Order: roughly group related changes together (all typing fixes, all security hardening, all API changes, etc.)

#### General
- **No test plan section.** Do not include "Test plan" or "Testing".
- **No mention of tests.** Do not reference test files, test results, or testing.
- **No emoji.**
- **No "Generated by" footer.**
