Modes

Modes that match the risk.

Modes tune scope, review depth, verification, and recovery behavior so Codex work matches the actual risk of the project.

Compare modes See topologies

Each mode changes how much work Codex should take on.

The best mode is not the strictest one. It is the one that makes the next slice small enough to prove and large enough to matter.

Safe MVP

Ship the thinnest real product slice.

Best when the team needs momentum now, but still wants a real vertical slice that can survive review.

Default topology

Solo Factory or Principal + Builder

Verification

Focused tests, build/typecheck where relevant, and targeted browser QA.

Exit criteria

The core flow works, proof exists, and remaining work is explicitly deferred.

Starter promptUse Safe MVP mode. Ship the thinnest real vertical slice and record a hardening backlog.

Common mistakes

Building a polished shell without real behavior.
Letting backlog items sneak into the accepted slice.

Velocity

Move larger slices through review.

Best when the direction is clear and the repo can absorb faster coordinated implementation.

Default topology

Principal + Builder + Reviewer

Verification

Focused checks per slice, with build gates at meaningful checkpoints.

Exit criteria

The larger slice is accepted with reviewer disposition and check evidence.

Starter promptUse Velocity mode. Move a larger product slice through review with periodic build gates.

Common mistakes

Scaling concurrency before ownership is clear.
Skipping reviewer readback because the build passed.

Strict

Add gates for high-risk work.

Best when the cost of a wrong change is higher than the cost of moving carefully.

Default topology

Strict Review Gate

Verification

Full relevant gate, reviewer findings, diff hygiene, and residual-risk notes.

Exit criteria

High-risk behavior is verified, reviewed, and accepted with remaining risk visible.

Starter promptUse Strict mode. Keep slices small, preserve validation, and require review before acceptance.

Common mistakes

Weakening schema or validation to silence failures.
Treating generated output as safe because it parses.

Release

Prepare the repo to ship.

Best when the question is no longer what to build, but whether the work is ready to declare done.

Default topology

Release Readiness

Verification

Build, audit, browser QA, deployment target checks, and release packet.

Exit criteria

The release packet is complete and the owner can commit, deploy, or hold intentionally.

Starter promptUse Release mode. Freeze scope and verify static export, audit, browser QA, and deployment readiness.

Common mistakes

Adding scope during the release gate.
Shipping without deployment-specific evidence.

Recovery

Reconcile messy state safely.

Best when the project needs control restored before another agent starts editing.

Default topology

Recovery Control

Verification

State inspection, targeted checks, and a precise resume or stop packet.

Exit criteria

State is reconciled, ownership is clear, and the next safe action is explicit.

Starter promptUse Recovery mode. Inspect first, preserve useful work, then reassign ownership before editing.

Common mistakes

Resetting unknown changes before reading them.
Letting stale owners keep editing after recovery begins.

Raise the gate when mistakes are expensive.

Strict and Release modes slow the work down on purpose. They are for shared contracts, deploy readiness, external effects, and irreversible decisions.

Lower the gate when learning is the product.

Safe MVP and Velocity keep momentum high by making the slice real, bounded, and easy to inspect before the next step.