Turns raw git diff output into a structured PR description covering summary, files changed, significant code, reasoning, project impact, a test plan and reviewer notes.
Version 1 · 3 variables · 2 required
Fill in the values below — the customized prompt updates as you type. marks a required value.
The branch you are diffing against and will merge into. Default: main
The bug report, ticket text or one-line reason for the change. Supplies the 'why' that a diff cannot show.
Paste the output of git --no-pager diff <base branch>. Scope it with pathspecs if the branch is large.
Fill in git diff output to copy the customized prompt.
Copy the prompt and open a model site to paste it. PromptByte never sends your prompt anywhere — providers do not accept pre-filled prompts through a link.
Showing all 1 public result on version 1.
Contributor notes: Illustrative example — not an actual model run. Written to show the shape of a good answer so the prompt can be judged before you spend a call on it. Attribution: adapted from https://github.com/danielmiessler/fabric by danielmiessler, licensed MIT. Source file: https://github.com/danielmiessler/fabric/blob/main/data/patterns/write_pull-request/system.md
1 public result from 1 model
Reports go to moderators and are never shown publicly.
Turns a project idea into a complete scaffold: a summary, build steps, directory structure, the purpose of each file, commented source for every file, a setup script and a README.
fix(auth)!: reject refresh tokens issued before a password change Refresh tokens were validated only against their signature and expiry, so a token minted before a password reset stayed usable for its full thirty-day lifetime. Anyone holding a captured token kept access after the account owner rotated their credentials, which is precisely the scenario a password reset is meant to close. The user row now carries credentials_changed_at, and verifyRefreshToken compares the token's iat claim again
Generates a Conventional Commits message from a diff or a plain description, picking the right type and scope, using imperative mood, and flagging breaking changes correctly.
### Overall Assessment The function's intent is immediately obvious, which is a real strength — nobody will misread what it returns. Its two weaknesses are both structural rather than cosmetic: it issues one database round trip per user, and it raises an unhandled exception the first time an id has no matching row. ### Prioritized Recommendations 1. Replace the per-id query with a single `IN` query to eliminate the N+1 pattern. 2. Decide explicitly what should happen when a user id has no row
Reviews a snippet or diff across correctness, security, performance, readability, idiom and error handling, then returns prioritized fixes with before/after code and a rationale for each.
Oldest first · one level of replies
Sign in to join the discussion. Share what you learned or made with this prompt.
No comments yet
Be the first to share how this prompt worked for you.