How it works
From a ticket to a reviewed pull request
A concrete look at what actually happens between connecting a repository and an engineer merging a change.
- 1
Connect your repository or org
You connect a GitHub repository or organization. Jira sync is optional: connect it if that's where your team already tracks backlog work.
- 2
A ticket enters the queue
Work comes in either as a ticket created directly in RepoFixer, or as a synced Jira ticket. Ambiguous tickets can be clarified before a run starts.
- 3
Research and planning
The ticket is researched against the connected repository and scoped into a plan a coding agent can actually execute, not just a restated ticket description.
- 4
Agent execution, isolated
A coding agent (Cursor and/or Claude, depending on what's enabled) executes the plan on an isolated server. The worker authenticates with its own bearer token and only talks to RepoFixer's Worker API, never directly to shared databases.
- 5
Build, test, change
The change runs through the project's own build/test process before it's considered ready, at a level appropriate to the ticket.
- 6
A small pull request opens
The result lands as a scoped pull request on your repository, on a branch prefixed repofixer/.
- 7
Human review
An engineer on your team reviews the PR exactly like any other. RepoFixer does not merge it.
- 8
Merge responsibility stays with you
Merging (and everything that implies about your team's standards) is a decision your engineers make, not RepoFixer.
- 9
Provisioning & deployment, where it applies
For project-lifecycle work (not just backlog maintenance on an existing repo), a server is provisioned (managed by RepoFixer or bring-your-own-server) and the project is deployed once that's in place.
- 10
Realtime status and usage recording
Agent runs and deployments report status in realtime. Token usage and cost are recorded per run; completed records aren't rewritten retroactively.
What RepoFixer does not do
Does not merge pull requests autonomously: a human always reviews first.
Does not give any worker a credential capable of reaching another customer's data.
Does not let a worker access MongoDB or Redis directly; only the Worker API.
Does not claim BYOS has the same execution guarantees as managed servers until it actually does.
Got backlog work piling up? Tell us about your stack and we'll help you get a first run going.
support@repofixer.com