Fast mode
For prototypes, finished work is committed and pushed straight to one branch, without a pull request or a review hold.
Fast mode is for prototypes and MVPs. When a ticket passes, its change is committed and pushed straight to one branch, without a pull request and without waiting for a person to review it. It is a setting of one project, and it is off until someone turns it on.
Fast mode is not "skip the checks". It removes two process steps and keeps everything that protects your machine, your keys and your history.
What Fast mode changes
- No pull request. The change is committed on the project's Fast mode branch and pushed. No pull request or merge request is opened.
- No review hold. A finished ticket is not parked in Needs review for approval. The project's approval rules do not hold Fast mode work.
- Your test, typecheck and lint checks follow your choice:
- Run, but don't block (the default): the checks run. A failure is recorded on the ticket and the change is still committed.
- Run and block: as without Fast mode, a failing check stops the commit.
- Skip: the checks do not run.
Everything else about a run stays the same: the agent works in its sandbox, every stage runs, the review still judges each acceptance criterion with evidence, and a ticket the review does not pass is not committed.
What Fast mode never switches off
- The secret scan. A change that contains a key, a token or a password is never committed, whatever the check setting says.
- The sandbox. The agent and every check run in the same confined sandbox as always.
- The other built-in checks (unfinished code, dependency policy, change size, protected paths and the rest) keep their own settings.
- The git rules. Nothing is ever force-pushed, no history is rewritten and protected branches stay protected.
Which branch it commits to
By default Fast mode commits to fast/<project>, for example fast/acme-shop. It is created from
the project's base branch the first time. You can name another branch, as long as it is not a
protected branch of the project.
The default branch needs a separate, explicit permission. Fast mode does not commit to the
project's default branch (for example main) unless you turn on Allow Fast mode on the default
branch and type the branch name to confirm. If the default branch later changes, the permission no
longer counts and you confirm again.
If your git host protects the branch, it refuses the push. Reqursor Development never forces it: the commit stays in the project's clone, the ticket shows the reason in plain words, and you can choose another branch or allow pushes on the host.
If a saved branch stops passing these rules, for example because it became protected, tickets go back to the normal flow with a pull request and a review, and the settings card says why.
Turn it on
- Open Settings → Projects & repository and pick the project.
- In the Fast mode card, turn on Turn on Fast mode.
- Optionally name the Branch, and choose how test, typecheck and lint checks are treated.
- Choose Save Fast Mode.
Owners, Admins and Developers can change Fast mode and revert its commits. Viewers see the setting and the banner. Autopilot and the other unattended features follow the project's setting: they use Fast mode only when it is on for the project.
Seeing and undoing Fast mode work
- A banner on the project's queue and on every ticket page says that Fast mode is on and where finished work is committed. The project list shows a bolt next to projects with Fast mode on.
- Every Fast mode commit is recorded on its ticket: who started the run, the branch, the commit, whether it was pushed, and the checks that failed without blocking. It is also in the ticket history and the audit log.
- One-click revert. On the ticket page, Revert adds a new commit that undoes the Fast mode commit, on the same branch, and pushes it, after you confirm. It never resets or rewrites history. The same branch rules apply: a revert on the default branch needs the default branch permission to still be on.
What it uses in model work
Fast mode adds no model work of its own. Every stage still runs and the review still judges the change. See also Branch strategy & Autopilot.