Quick mode

baro is built around a multi-agent pipeline: an Architect decides cross-cutting design points, a Planner decomposes the goal into a DAG of parallel stories, a Critic watches each turn against the acceptance criteria, and a Surgeon replans when stories fail terminally. That ceremony pays off on real features. It is overhead when the goal is "fix the typo on line 42."

--quick is the manual escape hatch for those cases.

What --quick does

baro --quick "fix the typo on line 42 of README.md"

When you pass --quick, baro:

• Skips the Architect phase entirely. No design document is produced — there are no cross-cutting decisions to align in a single-agent run.
• Hard-overrides the Planner to emit exactly one story. The planner is still allowed to write the acceptance criterion, but it cannot decompose.
• Disables the Critic. The per-turn evaluator is designed for multi-story runs where parallel agents can drift; a single tight story doesn't need it.
• Disables the Surgeon. The replanner exists to recover from terminal failures in multi-story DAGs. With one story, "the run failed" already means the obvious thing.
• Leaves Librarian and Sentry on. They're cheap, harmless, and still useful even on a single story.

The planning screen shows a quick mode — single story, no architect/critic/surgeon indicator so you can confirm the run will be surgical.

When to use it

Reach for --quick when the goal:

• Names a single concept (one bug, one rename, one typo, one small addition).
• Could plausibly be done by hand in a few minutes.
• Doesn't introduce a new feature surface, schema, or API contract.
• Doesn't pull in new dependencies.

Good --quick goals:

• baro --quick "fix the typo in README footer"
• baro --quick "rename getUser to fetchUser across the auth module"
• baro --quick "bump axios to 1.7.x"
• baro --quick "add a created_at index on the orders table"
• baro --quick "fix the off-by-one in pagination.ts"

When NOT to use it

Don't use --quick when the goal:

• Introduces a feature surface (new endpoint, new page, new module).
• Touches multiple modules with cross-cutting decisions (file paths, schema names, API shapes).
• Could reasonably be done as 3–5 parallel stories.

If you pass --quick on a non-trivial goal, the planner will obey and emit one story anyway, but the story will be too big for one agent turn and will likely fail or produce inconsistent code. The error mode is loud; rerun without --quick.

Quick mode and scope discipline

Even outside --quick, every story baro generates now ends with a scope discipline block that tells the agent to do only what the story's acceptance criteria require — no adjacent refactors, no "while we're here" cleanups, no extra tests. Out-of-scope observations are written into the commit message under Noted (out of scope): so you can file them as follow-ups.

That discipline is on by default. --quick adds the architectural overhead reductions on top.

Triage outside --quick

baro's Planner and Architect both now triage the goal before doing heavy work:

• The Architect emits a 2-line "no cross-cutting decisions needed" document for trivial goals instead of a 500-line design spec.
• The Planner emits exactly one story for trivial goals instead of artificially splitting them.

In practice this means most "fix something" prompts behave reasonably without you having to type --quick. The flag is the explicit user opt-in for when you already know the task is trivial and want the fastest possible path with no Architect call.

Cost and time

A normal baro run on a feature spends roughly 30–90 seconds in the Architect phase before any story starts. --quick skips that entirely — the first story spawns within seconds of you hitting enter. On trivial goals this is the difference between a minute-and-change and three to five minutes.