---
title: "Issue to pull request AI agent: tested draft pull requests"
description: "PRbot is an issue to pull request AI agent. Each run ends in a tested draft, at about $2 on Claude Haiku and sample repositories."
canonical: "https://laboetie.io/products/prbot"
language: en
---
# PRbot: issue to pull request AI agent

PRbot is an AI agent that turns an issue from GitHub or GitLab into a reviewed, tested draft pull request. The agent runs without a human operator. Each run works in its own sandbox, and the host checks the work before it opens the request. A run on Claude Haiku costs about $2 on sample repositories.

Status: Live. Access: By request. About $2 per run on sample repositories; default budget cap of $25.

## Capabilities

- The host checks the gates across the twelve phases of each run.
- You select issues from GitHub and GitLab, or set a label rule to pull them in.
- The agent harness is your choice of Claude, Codex, opencode or Hermes.
- Every run gets one sandbox holding the real stack and a real browser.
- Credentials stay outside the sandbox. Token use is metered per run.

## How an issue becomes a draft pull request

An issue becomes a draft pull request through twelve gated phases, from understanding the issue to tests and a final review. The host checks the work before it commits, pushes and opens the request. Its body lists the goals with their evidence, the screenshots, the model and the cost.

## Supported issue trackers and repositories

PRbot reads issues from GitHub and GitLab and opens its requests on both forges. You tick issues in the console or set a trigger label such as agent:run. A webhook fires within seconds of the label. Without a webhook, polling runs every 120 seconds. The Odoo source has unit tests and no live run yet. Jira and Linear are on the roadmap.

## Cost per run and budget cap

A run on Claude Haiku costs about $2, and a dozen runs on sample repositories ranged from $1.55 to $3.60. The same work on Claude Opus costs about ten times more. Each run carries a default budget cap of $25, and the harness stops the run when it reaches the cap. The cost appears in the console, in the issue comment and in the request body. Runs on large repositories may differ.

## Sandbox and credential isolation

The agent works in an isolated sandbox on your own machine, with your repository, your databases and a real browser. It holds no forge token and no model key. Network access is restricted.

## Code review before a person merges

A separate agent reviews each change with none of the author context, and the author must answer every finding. Each end to end step needs a real screenshot. A failed check appears in the request body. A person then reads the draft, marks it ready and merges it.

## How to get PRbot

PRbot is available by request, and no self serve signup exists. An operator provisions each tenant with its own Unix user, data directory and site. To start, send a brief that names your repository, your issue tracker and the model you want to use.


## What an issue to pull request agent is

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.

## How a run works, from issue to draft

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.

## Checks a run must pass

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.

| What is checked | What it protects you from |
|---|---|
| The plan exists before any code | An agent that starts coding with no understanding of the issue |
| Each goal has evidence | A claim of success with nothing behind it |
| Protected paths stayed untouched | Changes to CI, infrastructure or dependencies |
| Review findings were answered | Criticism that was ignored |
| Screenshots are real | Placeholder proof |
| The end to end scenario passed | A `done` status over a broken flow |

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`.

## What the final status means

| Status | Meaning |
|---|---|
| `done` | The whole process completed and every check passed |
| `partial` | The run ended with something red. A draft usually still exists |
| `blocked` | Phase 0 found a hard blocker and no code was written |
| `failed` | An error the run could not settle, such as an account out of usage |
| `interrupted` | The service restarted under the run. A rerun returns to the same branch |

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.

## What your reviewer sees

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

| Item | Source |
|---|---|
| Run id, harness and model | Host |
| Verdict and any red gates | Host, from validated files |
| Screenshot count | Host |
| Cost and token counts | Host, from the gateway |
| Link that closes the issue on merge | Host |
| Goals, each with met, unmet or unverified and its evidence | Verdict file |
| Description of the change | Agent |

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.

## Testing against your real application

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.

| You declare | What happens |
|---|---|
| Databases | One PostgreSQL, MongoDB or Redis per run, on the loopback |
| Seed commands | Schema, then fixtures, run before the stack starts |
| Start commands and ready URLs | The dev stack comes up and must answer |
| Environment variables | Each is classified as local, safe for dev or external secret |

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.

## What you connect

| Axis | Options |
|---|---|
| Issue source | GitHub issues, GitLab issues, Odoo project |
| Repository | GitHub or GitLab, through a token or a GitHub App |
| Model provider | Anthropic, OpenAI, DeepSeek, OpenRouter, or any compatible endpoint |
| Harness | Claude, Codex, opencode, Hermes |
| Run profile | `advancedpr` for the twelve phases, `onboard` for setup |

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.

## How issues get picked

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.

```text
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.

## Security model

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.

| Risk | What PRbot does |
|---|---|
| An agent reads other projects | Each stage runs isolated on your machine |
| An agent sends data away | Network access is restricted |
| An agent steals the model key | The key stays on the host |
| An agent pushes bad code | It holds no forge credential, and the host decides |
| A secret lands in a commit | The host refuses the change |
| Credentials at rest | Encrypted, and no API call returns one |

## Why branch protection is required

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.

## What a run costs

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

| Run | Cost |
|---|---|
| Claude Haiku, twelve phases | About $2, from $1.55 to $3.60 across a dozen runs |
| Claude Opus, same work | About ten times more |
| Onboarding run, three phases, no draft | About $0.22 |

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.

## Adding a repository

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.

## Which issues suit an agent

| Good fit | Poor fit |
|---|---|
| A clear bug with steps to reproduce | A vague request with no acceptance criteria |
| A small feature in existing patterns | A new architecture |
| A change you can check in a browser | A change that needs production data |
| Copy, validation and form changes | Changes to CI or infrastructure on denied paths |

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.

## Coding assistant, hosted agent or PRbot

| Question | Assistant in an editor | Hosted coding agent | PRbot |
|---|---|---|---|
| Who drives it? | A developer | Nobody, after assignment | Nobody, after assignment |
| Where does the code run? | The developer's machine | The vendor's cloud | Your machine |
| Who chooses the model? | Depends on the tool | Usually the vendor | You, per tenant |
| Who checks the result? | The developer | The agent and your CI | Host gates, then your reviewer |
| Runs your stack with a browser? | Only if a developer sets it up | Varies by product | Yes, on every run |

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.

## Next step

[Send a brief](https://laboetie.io/brief) with your forge, your stack and a few typical issues, and the studio will reply with a setup. PRbot shares its gateway core with [GateLLM](https://laboetie.io/products/gatellm) and runs on the same engine as [Agent Runtime](https://laboetie.io/products/agent-runtime).


## Frequently asked questions

### Can an AI agent turn a GitHub issue into a pull request?

Yes. PRbot takes an issue from GitHub or GitLab and returns a draft pull request. The agent edits files inside its sandbox and holds no forge token. The host checks what the agent left on disk, then commits and pushes the work and opens the request. PRbot posts a comment on the issue with a link to the request, the goals, the screenshot count and the cost.

### How much does a PRbot run cost?

A dozen runs on Claude Haiku on sample repositories ranged from $1.55 to $3.60, which gives about $2 per run. Those runs covered twelve phases and about ten screenshots. Claude Opus costs about ten times more for the same work. An onboarding run of three phases costs around $0.22. These figures count model tokens. Runs on large repositories may differ.

### Which coding agents and models does PRbot support?

PRbot runs four harnesses: Claude, Codex, opencode and Hermes. The confirmation dialog lets you choose the harness, the provider and the model before a run starts. Live proofs cover Claude Haiku on GitHub and GitLab, Codex on GitHub, and opencode and Hermes on GLM 5.3 Flash on GitHub. A model missing from the pricing table shows token counts with no cost.

### Does PRbot have automatic merge?

No. PRbot opens a draft, and a person reviews it, marks it ready and merges it. Every ten minutes the API reads back the requests a run left open. When one is merged, PRbot records the commit, the time and the person, then comments on the issue and closes it. Each write back step can be switched on or off per source.

### Does PRbot work with Jira or Linear?

Jira and Linear are on the roadmap. GitHub and GitLab have live runs behind them. The Odoo source is implemented and unit tested, and it has not run live. If your team uses another tracker, name it in your brief so the studio can tell you what intake exists.

### What does a repository need before PRbot can test it?

A repository needs a seed that fills a development database and lets the application boot with no live third party key. Keys of outside integrations stay empty in the sandbox, so payment, mail and partner calls need a stub or a feature flag. PRbot cannot test a repository whose seed needs a live key. Screenshots in the request show the fake seed data.

### What happens when a PRbot run fails?

The run tries again with the failure in view. If the failure stays, the run ends as partial and the request body names it. A hard blocker stops the run before any code is written.