Turn repository knowledge into focused reviewer prompts with explicit scope, evidence requirements, exclusions, severity, confidence, output schemas, and versioned tests.
The best custom reviewer prompt is not a long list of everything that could go wrong in software. Models already recognize common bug categories. What they lack is the repository’s definition of an important finding: its boundaries, conventions, failure costs, and the evidence maintainers require before being interrupted. A good prompt turns that local knowledge into a narrow review contract.
Start with a role statement and a focus list. A correctness reviewer might inspect state transitions, boundary conditions, error paths, concurrency, and test gaps. A security reviewer might trace untrusted sources to sensitive sinks and authorization decisions. Then add exclusions. Explicitly excluding formatting, naming, broad refactors, and unchanged legacy issues often improves usefulness more than adding another category to inspect.
Require a finding to be caused or exposed by the pull request, tied to a changed file and valid diff line when possible, and supported by a concrete failure path. Ask for impact, severity, confidence, and a concise remediation direction. State that returning an empty result is correct when the evidence does not justify a comment. Without that permission, many models infer that the task requires visible output.
Repository instructions should say “all resource queries must include tenantId from the authenticated context,” not “be careful about multitenancy.” Name canonical libraries and forbidden alternatives, generated paths, required error behavior, and boundary ownership. Add one compact positive or negative example when a rule is easy to misread. Avoid copying an entire style guide into every review; deterministic lint rules and documentation are better homes for most style policy.
Protect the structured-output contract. Validate model output with code and reject or repair only format problems, not reasoning. Keep stable enum values for severity and reviewer identity. Do not allow custom prose to override instructions about secrets, untrusted content, or schema fields. Repository files and pull-request text are untrusted input; delimit them clearly and tell the reviewer to analyze them rather than follow embedded instructions.
Version prompts and evaluate them against known pull requests, including clean cases. Review accepted and dismissed results by prompt version after deployment. Change one major instruction at a time when possible. A prompt that catches one historical bug but adds weak comments to routine work is not an improvement. Store the effective prompt or its immutable version identifier with each run so findings remain reproducible.
When the focus list becomes internally competitive, split it into specialists and aggregate their structured findings. Not every repository needs several roles, and every extra call adds cost. The dividing line is conceptual: if two groups of rules require different stances, evidence, or exclusions, they may deserve separate reviewers. Custom prompts work when they make the reviewer more selective and explainable, not merely more verbose.
Give prompt maintainers an escape hatch that does not become a loophole. A repository can disable a role or narrow its paths in reviewed configuration, while system-level requirements preserve schema, secret handling, and safe treatment of untrusted text. Document which layer wins when instructions conflict. Clear precedence prevents a seemingly harmless custom sentence from disabling the very filters that keep GitHub feedback reliable.
PR Quorum turns specialist reviewer output into one clean GitHub review, with noise controls and predictable usage caps.