What this prompt does
This prompt sets up an automated GitHub Copilot pull-request review workflow for your [language]/[framework] project. It configures Copilot review to run on every PR targeting [protected_branches] and defines review criteria via [review_criteria] so every review checks the same things instead of depending on which human happens to open the PR first.
The structure works because it makes review consistent and context-aware rather than ad hoc. It adds custom review prompts focused on [domain_specific] concerns unique to your application, defines severity levels that separate merge-blockers from suggestions, and writes per-type review templates for [pr_types] since a migration needs different scrutiny than a dependency bump. It also cross-references changes against [architecture_docs] to catch architectural violations a line-by-line read tends to miss, generates a review-summary format covering risk assessment, test coverage delta, performance impact, and action items, and integrates with [ci_tool] so Copilot's review combines with your automated test results. Wiring automated review into CI means obvious issues get flagged before a human ever opens the PR, which is where it earns its keep.
When to use it
- You want obvious issues flagged before a human opens the PR.
- You need reviews to consistently check the same criteria on every change.
- You want different review focus for features, bug fixes, dependency bumps, and migrations.
- You want architectural violations caught by cross-referencing your own docs.
- You need a standard review summary covering risk, coverage, and performance.
- You want Copilot review results combined with your CI test results in one place.
Example output
Expect a configuration plan plus supporting artifacts. You get settings to trigger Copilot review on your [protected_branches], a defined list of review criteria, custom review prompts for your domain concerns, a severity scheme marking blockers versus suggestions, review-prompt templates per PR type, instructions to cross-reference [architecture_docs], a summary format with risk assessment and coverage delta, and notes on wiring it into [ci_tool]. The result is a reusable workflow definition you adapt to your pipeline, rather than a single one-off review.
Pro tips
- List the criteria you actually care about in
[review_criteria], since a vague list produces vague, low-signal reviews. - Make
[domain_specific]concrete, such as financial calculation precision, so Copilot catches the issues unique to your application. - Keep severity levels honest — if everything is a blocker, nothing is, and people quietly stop reading the reviews.
- Point
[architecture_docs]at docs that are current, because cross-referencing stale docs flags false violations and misses real ones. - Tailor each
[pr_types]template, since reviewing a database migration differs sharply from reviewing a dependency bump. - Treat Copilot review as a first pass that frees humans for judgment calls, not as a replacement for human review entirely.
