What this prompt does
This prompt builds a GitHub pull-request review bot on [model_provider] that automatically reviews code changes. It triggers on PR open and push events, fetches the diff and changed-file context, and runs a review prompt checking for [review_criteria]. Comments land inline on specific lines with a severity tag — critical, warning, suggestion, or nitpick.
The structure works because an AI reviewer is only useful if the team does not mute it. Incremental review (only re-reviewing new changes on later pushes), respecting a .codereviewignore file, and loading custom rules from [config_file] keep the noise down. Token-budget management batches large PRs and skips generated files, while the false-positive tracking in the stats dashboard is what keeps the reviewer accurate over time instead of annoying after a week.
The summary comment ties the review together. Alongside inline notes, the bot posts an overall assessment with an approve or request-changes recommendation, so a reviewer can read the headline before diving into individual lines. Severity tagging across [review_criteria] means genuine bugs and security issues stand out from style nitpicks, which is exactly the signal-to-noise balance that determines whether developers act on the bot's feedback or scroll past it.
When to use it
- You want an automated first pass on every PR before human reviewers spend time.
- You need inline, line-level comments with severity rather than one vague summary.
- You want custom per-repo rules loaded from
[config_file]so the reviewer matches your standards. - You need incremental review so re-pushes do not re-flag the same lines.
- You want to exclude generated or vendored paths from review.
- You want stats on issues found and false-positive rate to tune the reviewer.
Example output
Expect a deployable review bot as a [deployment_type]: webhook or Action trigger logic, diff-fetching code, a tuned review prompt covering [review_criteria], inline comment posting with severity levels, a summary comment with an approve or request-changes recommendation, [config_file] parsing, and a stats dashboard. It usually includes the prompt-engineering notes for accurate, non-annoying reviews.
Pro tips
- Scope
[review_criteria]to what matters most for your team; reviewing everything at once produces noisy, low-signal comments. - Lean on incremental review so contributors are not re-pinged about lines they already saw on the previous push.
- Use
[config_file]to encode repo-specific rules — naming conventions, banned patterns — so the bot reflects your standards, not generic defaults. - Keep generated and vendored files out via
.codereviewignore; reviewing them wastes tokens and floods the PR. - Track false-positive rate from day one. A reviewer that cries wolf gets muted, and then it reviews nothing.
- Tune severity thresholds so nitpicks stay low-priority and criticals are genuinely worth blocking on.
- Lean on the summary comment to give a clear approve or request-changes signal, so reviewers get the headline at a glance.
- Batch large diffs within the token budget so big PRs still get reviewed instead of silently skipped.
