Skip to main content
Get a PRFlow review without anyone typing a comment, by letting your own CI request it once it goes green. A fresh installation does not review pull requests automatically. The supported way to make review hands-free is a small workflow you add to your repository. When your CI succeeds on a pull request, that workflow posts a /prflow:review comment on it, and the PRFlow workflow you already installed handles the rest.

Before You Start

This workflow is safe only under the pull_request event. Never move it to pull_request_target.pull_request_target makes your repository secrets available to runs started by pull requests from forks. Under that trigger, the same-repository check inside the workflow would be the only thing stopping a fork from minting your GitHub App token. Under pull_request, GitHub withholds secrets from fork runs no matter what, so the same-repository check is a second line of defense rather than the only one.
Three preconditions must be true before the workflow can request anything:
The workflow mints a downscoped token from the App you configured as DEVFLOW_APP_ID and DEVFLOW_APP_PRIVATE_KEY. Without those, the job’s own condition is false and nothing is requested. See Cloud Setup.
The comment is posted by your App, so PRFlow sees a bot as the requester. Add that App’s bot login, such as your-app[bot], to prflow.allowed_bots in .prflow/config.json. The shipped default is claude,dependabot, which names no App, so a fresh install does not authorize yours.Merge the allowed_bots change first. PRFlow reads that setting from your default branch at the moment a comment arrives. Adding your App’s login in the same pull request that adds this workflow has no effect on that pull request.
The helper this workflow calls first ships in prflow_version 2.30.18. Pin at or above it. Below that version the workflow warns and requests no review rather than failing.

Add the Workflow

1

Create the File

Add a new file at .github/workflows/prflow-auto-review.yml in your repository. Do not put this content into an existing PRFlow workflow file, because the installer manages those.
2

Paste the Workflow

Copy the file below exactly as it is.
3

Name Your Own CI Job

Change needs: [ci] to the name of the job, or jobs, that must pass first. This is the only line you are expected to edit.
4

Commit and Open a Pull Request

Commit the file, then open a pull request and let your CI run.

What You Should See

Once your CI job finishes successfully on the pull request, the PRFlow auto-review request workflow runs. It posts a /prflow:review comment on the pull request, authored by your GitHub App. That comment then starts a normal PRFlow review, exactly as if a collaborator had typed it, and the review posts its progress comment on the same pull request. Three outcomes tell you something went wrong instead:
  • The job was skipped. One of the five conditions was false: the pull request is a draft, it comes from a fork, its author is dependabot[bot], DEVFLOW_APP_ID is not set or your CI job did not succeed.
  • The step logged a warning about a missing helper. Your installed prflow_version is below 2.30.18. Update the installation. See Cloud Updates.
  • The comment was posted but no review started. The App’s bot login is not in prflow.allowed_bots on your default branch. See Cloud Triggers.
One outcome is intentional, not a failure:
  • The pull request has GitHub auto-merge enabled, and no review was requested. Auto-merge merges a pull request the instant its required checks pass — the same instant this trigger fires — so an armed pull request is about to merge and a review requested now would run against an already-merged target that nobody can act on. The helper detects the armed pull request and skips, logging a warning that names enabled auto-merge as the reason. If your repository also requires an approving review, an armed pull request does not merge at CI-green, so if you still want a review there, comment /prflow:review by hand — the manual path is unchanged.

Where This Does Not Reach

This mechanism can only wait on GitHub Actions jobs in the same workflow run. It does not reach CI that reports from outside Actions, such as CircleCI, Buildkite or a classic Jenkins commit status. A needs: entry cannot name those.
If your CI runs outside GitHub Actions, keep the manual path: a repository collaborator comments /prflow:review on the pull request.

Two Refinements You May Want

PRFlow’s own repository runs a slightly richer version of this job. Both additions are optional, and neither is in the file above:
  • Serialize concurrent runs at the same commit, so two green CI runs on one head cannot request two reviews.
  • Supersede stale CI runs, by adding a workflow-level concurrency: key to your own CI so an older run for a superseded head stops.
Add either one to your own workflow if you want it.

Cloud Setup

Configure the GitHub App this workflow mints its token from.

Cloud Triggers

The comment format and authorization rules the posted comment must satisfy.

Review System

What the review itself does once it starts.

Security

The wider trust boundaries around cloud runs.