An AI CI-Gate Prompt That Blocks Risky Pull Requests

A merge gate that blocks everything is as useless as one that blocks nothing. The goal of an ai pr ci gate prompt is judgment: read the diff, classify the risk, and return a verdict your pipeline can act on. Auth changes and new dependencies get scrutiny. A README typo sails through.

The part most teams get wrong is coupling the gate to one CI vendor. They write a GitHub Actions snippet, then can't reuse it on GitLab. Keep the decision logic in a portable prompt with a blocking-verdict contract, and the gate outlives whatever pipeline you're on this year. The CI just enforces what the prompt decides.

The pages ranking for this query are GitHub Actions snippets and one-vendor integrations. None define the gate logic as a portable, vendor-independent contract. That's the opening.

What the gate decides

An AI PR CI-gate prompt is a reusable instruction that reads a diff and returns a structured pass/fail verdict with evidence. The verdict is the product. Where it runs is plumbing.

What it can catch on any PR:

• A diff that touches authentication or authorization logic
• A new or bumped dependency with supply-chain risk
• Changes to files outside the PR's stated scope
• A secret or credential accidentally committed
• A blast radius larger than the PR description implies

Each is a reason a human reviewer would slow down. Encoding them once means every PR gets the same scrutiny, not just the ones a tired reviewer happened to read carefully.

Anatomy: diff in, blocking verdict out

The prompt frames the model as a release gatekeeper, takes the diff in a variable, and locks the output to a tiered verdict.

Variables
  {{pr_diff}}        — the unified diff
  {{pr_description}} — the stated intent of the change
  {{policy}}         — forbidden files, dependency rules, secret patterns

Prompt
  Role: You are a CI gate deciding whether this PR can merge.
  Task: Classify {{pr_diff}} by risk. Check it against {{policy}}.
        Compare actual changes to {{pr_description}} for scope drift.

Output contract
  risk_level:   low | medium | high
  verdict:      APPROVE | BLOCK
  violations:   list of policy hits with file + line (or "none")
  scope_drift:  changes outside the stated task (or "none")
  rationale:    one paragraph

The scope_drift field is the one that earns its keep on AI-authored PRs. An agent asked to fix a bug often refactors three unrelated files on the way. The gate compares the diff to {{pr_description}} and flags the drift, so a reviewer sees facts instead of trusting the PR title.

Step-by-step: wiring the gate

1. Capture the diff and the description

Your CI already has both. Pass the unified diff to {{pr_diff}} and the PR body to {{pr_description}}.

2. Encode your policy

{{policy}} is where your team's rules live: forbidden paths, dependency allowlists, secret regexes. This is the part you tune over time.

3. Run and read the verdict

APPROVE or BLOCK, with risk_level and the reasons. The pipeline maps BLOCK to a failed required check.

4. Surface the rationale on the PR

Post violations and scope_drift as a PR comment. A blocked author who sees why fixes it faster than one staring at a red X.

5. Tune the threshold

If the gate blocks too aggressively, adjust where medium becomes BLOCK in the prompt. One edit, every pipeline updated.

Patterns that make the gate trustworthy

Tier the risk, don't binary it. A two-state gate either annoys everyone or catches nothing. Three tiers with a tunable blocking threshold lets you block high-risk diffs while waving through the trivial ones. Trust comes from the gate being right about what's risky.

Compare to stated intent. The scope-drift check is what makes this more than a linter. A linter doesn't know the PR claimed to be a one-line fix. The gate does, because you fed it {{pr_description}}.

Cite file and line on every violation. A verdict without locations is an accusation. With file + line, it's actionable. Force the evidence in the contract.

Variables you'll set

An opinion worth holding

A CI gate that lives entirely in your pipeline YAML is a gate you'll rewrite the next time you switch hosts. The decision logic belongs in a portable prompt; the pipeline should be a dumb executor that reads verdict and flips a check. Teams that bury the rules in vendor-specific workflow files end up with three slightly different gates and no single source of truth for what "risky" means. Don't. One prompt, many pipelines.

Getting started

1. Copy the anatomy into your model of choice.
2. Feed it a real PR diff and its description.
3. Encode two or three of your team's hard rules in {{policy}}.
4. Confirm a trivial PR returns APPROVE and a risky one returns BLOCK.
5. Wire the verdict field to a required CI check.
6. Tune the blocking threshold in the prompt, not the YAML.

For the full automated version, the AI PR CI-Gate Harness Agent Pack classifies risk, checks compliance, detects scope drift, and posts the approve/block decision to GitHub on its own.

For the human side of the same job, the Pull Request Review Workflow Pack turns a diff into a prioritized review covering architecture, defects, and security. See also how to choose a reusable AI prompt pack and the companion CI failure diagnosis prompt from pipeline logs.