Add an agent code review to every pull request

name: Plori review
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  review:
    permissions:
      contents: read
      id-token: write
      pull-requests: write
    uses: plori-ai/agent-action/.github/workflows/review.yml@v1

The file calls the review workflow of plori-ai/agent-action at the tag v1. That workflow has two jobs:

• The agent job has contents: read and the permission to request a GitHub OIDC token. It exchanges the token for one Plori run on the repository's agent. In the recorded run, the agent cloned the public repository over HTTPS.
• The comment job has pull-requests: write. It has no OIDC permission and no connection to the agent. It posts one comment with a marker, and it edits the same comment when a later commit gets a review.

The agent cannot push, approve, merge or post a comment. The only write to GitHub is the comment from the comment job.

The default prompt tells the agent to fetch the exact base and head commits and to read the callers and contracts of the changed code. It also tells the agent to run the smallest checks that apply. The agent reports a finding only when it has evidence that the change causes a failure or breaks a contract. For a sound change, it writes No actionable findings.

To add your own instructions, add a with block under uses:

    with:
      prompt: Focus on migration rollback safety and API compatibility.

Plori adds this text after the default prompt, and the default prompt stays in place. This guide has no run with a custom prompt.

Where does the review run, and what needs approval?

The review runs in a Plori Workspace that belongs to the repository. The agent, its files and its conversation stay with that repository, so each later review goes to the same agent. Reviews of one repository run one at a time.

Nothing needs approval. Each review is a batch run: the agent does not stop for a question or an approval. If the agent cannot finish, the agent job fails.

What did the real run prove?

On 18 October 2026, the workflow file above ran on a new public repository. The repository had a small JavaScript module, src/paginate.js, a README that shows the output of paginate(items, page, pageSize), and tests that run with node --test.

Pull request 1 had a bug that we put in on purpose. It added a parsePage function with its tests. It also changed the hasNext check in paginate from page < totalPages to end <= items.length. With this change, a full last page returns hasNext: true. The README says that the last page always returns hasNext: false, also when it is full. The existing tests still passed, because they use 10 items with a page size of 3.

The review comment named src/paginate.js:25. This excerpt keeps the evidence and the fix, and [...] marks the text that it leaves out:

`hasNext: end <= items.length` reports a next page that does not exist whenever the
list length is an exact multiple of `pageSize`: the final page starts exactly at
`items.length`, so `end` equals `items.length` and the flag stays `true`. Confirmed by
running the README's own second example, `paginate(["a","b","c","d","e","f"], 2, 3)`,
which now returns `{"items":["d","e","f"],"page":2,"totalPages":2,"hasNext":true}`,
contradicting the output documented at README.md:17 (`hasNext: false`) and the contract
at README.md:20-21 [...]. The existing suite misses it because `test/paginate.test.js`
only exercises 10 items with `pageSize` 3, which is not exactly divisible; the new
`test/parse-page.test.js` does not touch `paginate`. [...] Fix: change the comparison
to `hasNext: end < items.length`, and add an exactly-divisible case to
`test/paginate.test.js` so the change is pinned.

Pull request 2 changed no behavior. It renamed a local variable from start to firstIndex and added a code comment. The agent cloned the repository, checked out the exact head commit, and read the diff against the base commit. It searched for other uses of the name, compared the base and head code, and ran node --test test/paginate.test.js, where 4 tests passed. Then it posted this review:

## Plori agent review

No actionable findings.

The two reviews in numbers:

Measure	Pull request 1 (bug)	Pull request 2 (rename)
Result	Found the bug, with a reproduction	No actionable findings.
agent job in GitHub Actions	72 seconds	20 seconds
comment job in GitHub Actions	4 seconds	4 seconds
Plori run	67.5 seconds	13.2 seconds
Model calls	13	6
Shell tool calls	11	4
Cost	$0 (free run)	$0 (free run)

Both reviews ran in the same agent conversation, because the repository keeps one agent. Each agent job printed a link to the agent session on plori.ai.

The first attempt to review pull request 1 ran on 17 October 2026. It failed with HTTP 403 because of a Plori defect, which is now fixed. We reran the workflow on 18 October. The failed attempt also counted as a free run. After the two reviews, the count for the repository was 3 of 3 free runs. The count for the GitHub owner was 3 of 10 for the month.

The run shows that the workflow file works on a public repository with no Plori key or secret in it. The agent found one bug that the tests missed, and it reported no finding for a change with no behavior change. Each case has one sample, so this is not a detection rate.

How do you check it safely?

This test writes one comment on each of two pull requests. The agent writes nothing to the repository.

1. Create a new public repository on github.com.
2. Add a small function, a README that shows the output of the function, and a test.
3. Add the workflow file above as .github/workflows/plori-review.yml. Commit it to the default branch.
4. Create a branch. In the branch, change the function so that its output is different from the README. Make sure that the existing test still passes.
5. Open a pull request from the branch.
6. Open the Actions tab. Make sure that the review / agent job and the review / comment job are complete.
7. Read the comment on the pull request. Record if the comment finds the changed output and gives evidence.
8. Create a second branch from the default branch. In this branch, rename a local variable and add a code comment. Do not change the behavior of the code.
9. Open a pull request from the second branch.
10. Read the comment on the second pull request. Record if the comment says No actionable findings.

This test uses 2 of the 3 free runs of the repository. It also uses 2 of the 10 free runs of the GitHub owner for the month. Each new commit on an open pull request and each rerun of the workflow starts one more review.

What are the limits?

• A review is one agent that reads one change. It can miss a defect, and it can report a finding that is wrong. This guide has one sample for each case. It is not a detection rate.
• The free runs are 3 for each repository and 10 for each GitHub owner in a UTC month. In this run, an attempt that failed also counted. After the free runs, the Action returns a setup link instead of a review. To continue, a repository admin stores a Plori API key as the repository secret PLORI_API_KEY. The admin then passes the secret to the workflow. The next run connects the repository to that Plori account. The account needs credits. This guide has no run of this step.
• A private repository gets a setup link instead of a review until a repository admin connects it with an API key. This guide has no run on a private repository.
• The agent reads the repository content as untrusted input. Never give the PLORI_API_KEY secret to pull requests from untrusted forks.
• The review does not approve or block a pull request. In this run, both jobs completed successfully when the review had a finding. A required status check on them shows only that a review ran.
• The OIDC path works only on github.com. GitHub Enterprise Server needs an agent id and a PLORI_API_KEY secret. This guide has no run on GitHub Enterprise Server.
• For a pull request from a fork, GitHub can reduce the permissions of the job token, and the comment can fail. The review stays in the summary of the agent job. Do not change the trigger to pull_request_target. This guide has no run with a fork.
• Each review is a batch run. The agent asks no question, and a reply to the comment does not start it again. For a new review, push a commit or rerun the workflow. The agent job waits up to 2,100 seconds by default, and Plori stops a review run after 30 minutes.
• The workflow works only for repositories on github.com. It does not work on GitLab or Bitbucket, and it is not for a review that needs a conversation.
• The evidence of each review is on GitHub: the comment, the Actions run, and the link to the agent session.
• Each pull request in this run had one commit, so the run did not show the edit of the comment after a later commit.
• This guide has no run of a review from the Plori web app, where the agent clones the repository and writes the review to a file. This guide does not describe that path.

Common questions about agent code review on pull requests

Can an AI agent review every pull request in my GitHub repository? Yes. Plori runs AI agents that collaborate on one product in the cloud. With this workflow file, a Plori agent reviews each pull request in a repository on github.com, and a separate job posts one comment.

Do I need a Plori account or an API key? A public repository on github.com needs neither within the free-run limits above. GitHub OIDC identifies the repository. To connect a private repository or continue after the free runs, a repository admin stores a Plori API key as a repository secret.

How much does a review cost? Reviews within the free-run limits cost $0. After you connect the repository to a Plori account, reviews charge model usage and run time to that account's balance. This guide has no measurement of a paid review. Check the current pricing.

Can the agent change my code? No. The agent has read access to the repository. It cannot push, approve or merge, and a separate job posts the comment.

Does the agent run my tests? The default prompt tells the agent to run the smallest checks that apply. In the review of pull request 2, it ran the repository's tests with node --test.

Can I tell the agent what to look at? Yes. Add a prompt input under with. Plori adds your text after the default prompt.

What happens when I push another commit? The workflow starts a new review of the new head commit. The comment job edits the same comment. This run had no second commit.

Related

• plori-ai/agent-action, for the Action README, the API key path and the outputs
• API documentation, for the OIDC exchange and the setup link
• Workspaces, for the Workspace that keeps the agent's files
• Pricing, for the cost of a review after the free runs