Tag
A clear PR description saves everyone review time. These prompts help you summarize a change, explain the reasoning, and flag what reviewers should look at closely.
8 prompts
Paste a diff or code block and get a senior-engineer-style first pass before it reaches a human reviewer. - Flags bugs, security risks, performance issues, and maintainability problems - Rates each finding Critical, High, Medium, or Low with line references and a fix - Add project conventions (e.g. "no nested ifs") for sharper, more relevant results - Run it on every PR so reviewers only spend time on what's left after the obvious stuff is caught
Give it the PR's stated goal and your repo's architecture and conventions to get a review that avoids both rubber-stamping and nitpicking. It checks correctness, readability, maintainability, test coverage, and backward compatibility in one pass, then sorts findings into Confirmed Issues, Possible Risks, and Nice-to-Haves, closing with three ready-to-paste GitHub review comments.
Describe the issue you've spotted in plain English along with the specific lines and fuller details, and get back a ready-to-paste GitHub review comment instead of staring at a blank comment box. The output is specific, explains why the issue matters, includes a concrete suggested fix, and skips filler openers like "Great work, but..." — also useful as a template for junior reviewers learning to write good comments.
Takes review notes you've already worked out — the issues, not the raw diff — and turns them into 5 polished GitHub PR comments ready to post. Each one stays direct without being harsh, names the specific issue, explains its impact, and suggests a fix, capped at 80 words so reviewers actually read it. Useful when you already know what's wrong and just want the wording tightened before publishing.
Built for the PR that looks trivial in the diff but quietly changes an assumption something downstream relies on. - Flags changed assumptions, edge cases, and null/empty handling - Checks off-by-one logic, state transitions, and API contract drift - For each issue: what changed, what it could break, and the smallest test that would have caught it
Reviews a pasted diff the way a security-focused application engineer would, prioritizing auth and authorization checks, input validation, secret handling, injection risks, unsafe defaults, and data exposure over general code quality. Every finding is labeled a confirmed vulnerability, a plausible risk, or something needing manual verification, and it won't speculate beyond what the code shows. Reach for it on changes touching permissions, secrets, or user input.
Summarizes a pasted diff in exactly three bullets for a reviewer who has never seen this codebase: what changed, why it changed, and what could go wrong. It's built to name real classes, functions, and file paths rather than describe changes abstractly, and it doubles as a scope check — if the diff can't be summarized in three concrete bullets, the PR is probably too big.
Turns a raw diff and a short context note into a PR description reviewers can actually use, grounded in the real file and function names pulled from the diff rather than generic phrasing. Outputs a three-bullet what/why/risk summary, testing notes, the files that most deserve attention, migration or compatibility concerns, and a suggested PR title — and says so if the diff is too large to summarize well.