PR Description Guidelines

The work is done. Now, create a new PR for the current changes. If you're not on a new branch yet, create one first. Then, create the PR. Treat the changes as a real deliverable. The description is the first thing anyone reading this work will see, and most readers will not read the diff line by line.

Audience

Write for someone who:

• Is a developer on this team
• Already knows this repository and its existing architecture
• Has not seen this work before

You don't need to explain the codebase, the framework, or how things generally work in this system. You do need to explain everything new that this PR introduces — concepts, entities, flows, behaviors — clearly enough that the reader understands the change without opening the diff.

Cover only what's in this PR. If it's part of a larger effort (MVP, migration, refactor), one short line of framing is enough. Don't restate the whole project.

Title

The title is a one-line summary of the change. Specific, declarative, imperative mood.