PRbot: issue to pull request AI agent

An issue to pull request agent is software that reads a ticket from your tracker, changes the code in a copy of your repository and proposes the result as a pull request. Your team reviews that proposal the way it reviews a colleague's work. GitLab calls the same object a merge request.

Most coding assistants need a person at the keyboard to approve each step. An issue to pull request agent runs from a ticket to a finished proposal with nobody driving it. That raises one hard question: how do you trust what comes back?

PRbot uses a fixed process to answer it. Each run moves through twelve phases, and checks on the host machine must pass before a draft opens. The agent cannot mark its own homework, and it holds no credential that could write to your repository.

1. A person ticks an issue in the console, or adds a trigger label to it.
2. The host clones the repository and prepares a sandbox with your databases, your seed data and a real browser.
3. A planning pass reads the code and writes the scope, the analysis, the plan and the goals.
4. A session pass writes the code and tests it against the running application.
5. A separate agent with no shared context reviews the change.
6. A final pass runs the end to end scenario, captures one screenshot per step and records the outcome in a file.
7. The host checks what is on disk, commits, pushes and opens a draft.
8. A person reads the draft, marks it ready and merges it.

The security of the system depends on step 7. The agent edits files in its sandbox. The host, and only the host, talks to your forge. A forge is the service that hosts your code, such as GitHub or GitLab.

A run has to prove its work before a draft opens. The host machine runs these checks itself, on the files the agent left behind, and the agent takes no part in them.

A failed check sends the work back. If it keeps failing, the failure appears in the merge request and the run cannot end as done.

A hard blocker has two possible causes: the change needs files outside the allowance, or the issue contradicts a stated constraint of the repository. An ambiguous ticket does not stop a run. The agent writes its assumptions into the scope file, where a reviewer can read them.

The draft opens with a block written by the host, and the agent's own description follows it.

The issue receives a comment when the run starts. A second comment at the end gives the link, the outcome and a table of goals. After a person merges, PRbot notices on its next check, every ten minutes by default, and records the commit, the time and the person.

Many agents stop at unit tests, which miss a broken screen. PRbot starts your stack inside the sandbox and drives it with a real browser.

Keys for outside services stay empty in the sandbox, so the seed must leave your application able to boot without them. A payment or mail integration needs a stub or a feature flag. The seed uses no production data, so screenshots in the draft show fake records.

A harness is the program that drives the model. Changing one is a setting, so you can try two on the same issue and compare the drafts and the costs.

There are two ways in. In the console, you tick one issue or several and press run. You can also set a label rule, and the convention looks like this.

agent:run      a person adds this label to start a run
agent:mr       applied when the draft opens
agent:merged   replaces it after the merge

A webhook starts a GitHub or GitLab run within seconds of the label. Without a webhook, and always for Odoo, the service polls every 120 seconds by default.

One issue has one active run. A second request returns the run already in progress. A rerun reuses the branch, so it updates the same draft and leaves no duplicate behind.

An agent that reads tickets is exposed to whatever a ticket says. A malicious issue could tell it to send your secrets somewhere. PRbot limits what any instruction can reach.

PRbot refuses a repository whose base branch accepts a direct push, and it proves the rule by testing it during setup. Your forge enforces branch protection, so that rule holds even if every layer above it failed. The rule needs one required review on the base branch. On GitLab, the equivalent is a protected branch with push access set to no one.

A person takes the last step, since PRbot has no merge function.

The figures below come from live runs on sample repositories. Each run took about ten screenshots. Your code will differ.

You pay your model provider directly with your own keys. Each run has a cap, 25 dollars by default, and you can set a lower one per tenant. The harness receives the cap and stops when it reaches it. Tokens are counted at the gateway, so all four harnesses report through one meter. A model missing from the price table shows tokens and no cost, since PRbot does not estimate a rate it lacks.

Setup happens in the console, in five steps. PRbot first proves the credential works, then reads the repository and prefills the commands, databases and environment list. It installs the toolchain, runs the stack once to confirm that everything starts, and offers fixes when something fails. A person approves each proposal.

Writing the ticket well matters more than choosing the model. State what should happen, where, and how to see it working. The first runs should use small issues and a cheap model, so you learn how the agent reads your repository.

An assistant suits work a developer wants to steer. PRbot suits a team with a backlog of well described tickets that wants its code to stay on its own hardware.