Use cases
What you can actually run with it
FragonForge exists so you spend less of your life in front of a laptop. That is the actual reason it was built, and every workflow below is a version of the same move: hand the mechanical part to the loop, keep the judgment, and go do something else.
No invented customers on this page, just seven workflows the mechanics genuinely support, each with its honest requirements. Everything here composes from documented pieces: the label trigger, the orchestrator, the quality gate, and opt-in autonomous merge.
01
Three projects advance while you are not at the laptop
3 goals -> 3 pipelines -> green steps merge -> you review the rest
Give the orchestrator a goal in each of your repositories and walk away. Discovery scans each repo, you approve each architecture, and the pipelines work through their steps in parallel. With autonomous merge enabled, steps whose quality gate is explicitly green land on their own; everything else waits in reviewable merge requests.
You come back in the evening, walk through what merged, review what did not, and fix what the agent got wrong. The boilerplate is done; your time goes into the ten percent that needed you.
What it takes: the Team plan (3 concurrent runs, 10 repositories; Solo is capped at 1 repository and 1 concurrent run), and autonomous merge enabled per repository - a paid-plan opt-in for private repositories that never touches CI config, auth, secrets, or dependency manifests.
02
A fix, filed from wherever you are
issue from the forge app -> label -> MR waits for you
You are out, and you remember the bug. Open your forge's mobile app, write the issue the way you would for a colleague, add the trigger label, put the phone away. The run starts without you: sandbox, tests, merge request.
The review happens when you are next at a machine, on your schedule. The point of FragonForge was never more screen time; it was less. The mechanical part should not require you to be in the chair.
What it takes: any plan, and the discipline to write a real bug report from your phone (reproduction, expected behavior). The label trigger does not care where the issue came from.
03
A production error becomes a fix attempt overnight
error -> labeled issue -> sandbox run -> MR awaiting your review
Anything that can create a labeled issue on your forge can start a run: that is the whole point of the label trigger. Wire your error tracker or monitoring to file an issue with the stack trace and the trigger label, and FragonForge picks it up, reproduces what it can in the sandbox, runs your tests, and opens a merge request.
The next morning there is either a fix attempt waiting for review, or a failed run whose log tells you what the agent could not do. Both beat an unread alert.
What it takes: your own wiring from tracker to forge issue - FragonForge ships no error-tracker integration, it reacts to labeled issues and API calls. Every attempt is a run against your quota, so give the label only to errors worth an attempt, and write the issue like a bug report (reproduction, expected behavior): well-specified issues convert best.
04
The backlog issues that never get scheduled, finally done
label 5 issues on Friday -> 5 MRs on Monday
Every backlog has them: the small, well-understood issues that lose the prioritization fight every sprint. Label a handful before you leave, and they run while nobody is waiting on them. On Monday you review five merge requests instead of re-reading five stale tickets.
This is the lowest-risk way to start: pick issues a colleague could fix from the description alone, because that is exactly the information the agent gets.
What it takes: any plan, including Free (1 repository, 100 runs per month, hard stop). Acceptance criteria in the issue do more for the outcome than any setting.
05
The dependency upgrade train nobody wants to drive
goal: upgrade -> one step per package -> tests gate each -> retry from failure
Framework upgrades and deprecation sweeps are the least loved work in engineering, and the easiest to hand over: give the orchestrator the upgrade as a goal, and it becomes a dependency-ordered pipeline with one step per package or module, your test suite gating every single one.
A step that breaks retries from the earliest failed point, not from scratch, and everything that passes arrives as its own reviewable merge request instead of one thousand-line big bang.
What it takes: a real test suite, because the tests are the gate. Every step is a run, and big upgrades can hit the per-run wall-clock limit (15 to 120 minutes by plan); the decomposition into small steps is what keeps each one inside it.
06
A neglected repository climbs from D to B
analysis scan -> auto-fix MRs converge -> A-F rating climbs
Start an analysis scan from the dashboard on the repository everyone avoids. The 33 orchestrated analyzers produce a findings baseline, and from there you let the auto-fix merge requests work through it, with convergence detection so the same finding is not chased twice.
The A to F rating turns the cleanup into something you can watch move. What used to be a quarter of nagging becomes a week of reviewing focused fix MRs.
What it takes: the scans themselves do not consume runs, but each auto-fix merge request is a run against your quota. And an honest boundary: auto-fix repairs what the analyzers find; there is no triage workflow to wave findings through, so what the tools flag either gets fixed or gets configured away.
07
A team feature, driven by a spec instead of a standup
spec file in the repo -> spec-driven mode -> two human gates -> reviewed MRs
The lead writes the specification as a file in the repository, where discovery reads it directly instead of squeezing it through a prompt. Spec-driven mode then works the feature with two human gates built in, so the team reviews at the decision points, not in every diff.
The spec stays in the repo as the source of truth, versioned with the code it produced.
What it takes: a spec someone actually wrote; its quality decides the outcome. The gates are review work that stays with your team, and concurrency is per plan (Team runs 3 pipeline steps at once, Business 5).
Bigger than any of these? A goal can also be a whole application built from an empty repository; how that works, including its economics, is on the how-it-works page.