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.

Write for someone who:

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.

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

If the repo uses a prefix convention (, , scoping like ), match it.

Every PR description, regardless of size, has to answer:

Beyond those two, include whatever else the reader needs to actually understand the change:

If something is only interesting at the code level — naming, file moves, mechanical refactors — leave it in the diff.

Don't follow a fixed template. The right structure depends entirely on what this PR contains.

Decide the structure by asking: what does the reader need to know, and in what order? Then group that information into coherent sections with headers that describe their actual content. A small bug fix might be three sentences with no headers at all. A PR introducing a new subsystem might have five sections. Both are correct when they match the change.

Order matters: start with whatever orients the reader fastest (usually a summary), put context next, push edge cases, caveats, and follow-ups toward the end.

If related issues or PRs exist, link them. Use GitHub's keyword syntax (, ) where appropriate.

The description should read like a senior engineer wrote it for a colleague — direct, specific, no filler. The following phrasings mark text as AI-generated and must be avoided:

Write declaratively. "Adds X. X is created when Y happens." Not "This PR aims to introduce X, which would help with Y."

Use prose where bullets would fragment a thought. Use bullets where prose would become a wall. Don't enumerate every file changed.

Use lowercase headings unless the repo's existing PRs use a different convention.

Return the title and description as raw markdown in separate code blocks I can paste into GitHub directly. No preamble, no commentary after the blocks.

If this PR includes noticeable UI work — new views, new sections, visual changes — remind me at the end to attach screenshots or a short screen recording to the PR for reviewer context.