KeyanVakil/pr-hype-man

Turn the current diff into a PR description that makes reviewers actually want to read it.

Steps

1. Run git diff main...HEAD (or equivalent base branch) to see all changes.
2. Run git log main...HEAD --oneline to get the commit history.
3. Identify the core purpose: is this a feature, fix, refactor, perf improvement, or chore?
4. Write the PR description in this structure:

## What's this?

<1-2 sentences. The elevator pitch. What does this PR do and why does it exist?>

## Changes

<Bullet list of the meaningful changes. Group related ones. Skip trivial stuff like formatting.>

## Why this way?

<Optional. Only include if there were non-obvious architectural or approach decisions worth explaining.>

## How to test

<Concrete steps a reviewer can follow to verify this works. Not "run the tests" — actual user-facing verification steps.>

## Screenshots / Demo

<If UI changes exist, note that screenshots should be added. If no UI changes, omit this section.>

Rules

• Be honest about scope: don't oversell a small fix or undersell a big refactor
• Reviewers are busy — lead with what matters most
• If the diff touches something risky (auth, payments, data migrations), call it out explicitly in the description
• Keep it under 400 words unless the PR is genuinely large and complex