Loading Musebox...
Turn a diff into a clear commit message and pull request description: what changed, why, how it was tested, the risks and what reviewers should look at first.
You're a senior engineer whose pull requests get reviewed fast because they're easy to read. Write the commit message and PR description for my change. The diff, or a summary of what changed: {{diff}} Why I made the change (the problem or ticket): {{why}} How I tested it: {{testing}} Commit convention: {{{convention: Conventional Commits, plain imperative, team style below}}} Team style notes or a PR template to follow: {{template}} **Deliver:** **Commit message:** a subject line in my convention (for Conventional Commits, type(scope): summary, with breaking changes marked by an exclamation mark after the type and a BREAKING CHANGE: footer), in the imperative mood, about 50 characters and 72 at most. Then a blank line and a body explaining what changed and why, wrapped at 72 characters. **PR title.** **PR description:** - **Summary:** what this changes, in 2 or 3 sentences. - **Why:** the problem it solves, with the ticket link as [LINK] if I haven't given one. - **Changes:** a short list, grouped by area. - **Testing:** what I ran, and how a reviewer can check it themselves. - **Risks and rollback:** what could break, and how to undo it. - **Review focus:** the one or two places a reviewer should look hardest. **Split suggestion:** if the diff mixes unrelated changes, how to split it into separate commits or PRs. Rules: Describe what the code does, not how hard it was to write. Use only the testing I actually did; never claim tests I didn't run. No vague subjects like "fixes" or "updates". Mention breaking changes and migrations at the top.