Building with mini, Part 6/9: Autonomous mode — auto and stop

After Parts 4 and 5, pycalc can compute and has two human checkpoints around the loop. But every phase costs you the same ritual: run next, approve, plan, approve, do, wait, done, verify. Fine for one phase a day. A chore for "knock out three small phases this evening" — you sit there clicking through it.

mini auto chains that ritual: next → plan → do → done, phase after phase, on its own. But not blindly — and that "not blindly" is the whole point of the command.

What auto does — and where it stops

You run /mini:auto (optionally --max-phases 3) and Claude drives the loop for you. After each phase it proposes the next one and keeps going until it hits a boundary. There are four boundaries, and they're worth knowing because they define what auto is not:

1. next — it always asks. Autonomous mode does not invent phases. At the start of each phase it stops and takes an idea from you (or lets you pick from the backlog). This isn't a weakness, it's a safeguard: you keep hold of the project's direction.
2. verify — it stops at user-facing output. When a phase has visible output that only a human can judge (a CLI, a screen, messages), auto lets you do the review and does not bypass it. If problems turn up, it goes back to do, not forward to done.
3. A blocker — when it hits something it can't get around on its own, it stops and hands over control.
4. --max-phases / end of project — it runs the given number of phases, or stops when next concludes the project is finished.

In between it runs itself: plan breaks the phase down, do writes it and ticks off the steps, done closes it with a commit. When do doesn't finish a phase (runs out of steps, hits a wall), auto retries it — up to three times — then gives up and calls a human.

This is not "yolo, let it run overnight". auto is a semi-automatic: it removes the clicking where it's mechanical, and leaves you the decisions where they matter. Anyone expecting a fully unattended mode will be disappointed — and that's a good thing.

pycalc: one phase that auto carried

Backlog item [3] from Part 3 was waiting: --help support. The verify step in Part 5 had itself flagged it as "looks like a bug" (pycalc --help failed with error: invalid character 'h'). I started autonomous mode, and the first stop comes immediately — next asks for an idea. I gave it the backlog item. And here's the thing: it didn't just agree.

The non-goal in project.md says literally "Do not add colors or extra CLI flags." --help is a CLI flag. This isn't cosmetics — you're breaking your own written rule. The intent of that non-goal was probably "no feature flags" (--precision, --base), and --help is more of a universal convention than a feature. But text is text.

Slippery slope: once you allow --help, you weaken the defense against -v/--version, --precision. "No flags" is a clean line; "no flags except help" is harder to defend.

Honest verdict: a legitimate small UX fix, but it's your deliberate decision to break a non-goal, not an automatic one.

It proposed a narrow phase (--help/-h only as the sole exact argument, and part of the phase is amending that non-goal so the code and project.md don't contradict each other), and only after my approval did it save it — with --from-todo 3, so the backlog item ticked itself off:

Ideas & changes
  1. [ ] Power ** and modulo % …
  2. [ ] Read the expression from stdin …
  3. [x] Support --help / -h …
  2 open / 3 total

That's an arc across three episodes: the idea was born in verify (Part 5), parked in todo (Part 3), and now auto pulled it out, weighed it against the project's rules, and closed it. From there it ran on its own — plan split the phase into six steps, do wrote HELP_TEXT + the handling in main() + a regression test that -5+3 stays a valid expression, and done closed it with the commit Phase 4: Help flag support. 17 tests green.

Phases:
  [done]       3. CLI layer and formatting
  [done]       4. Help flag support (took 1m 24s)

stop — how to halt it politely

You don't interrupt an autonomous run by typing "stop" into the session — Claude is working and won't read your message. So stop is a cooperative signal through a file, not through the chat. From a second terminal:

mini stop

[ok] Stop signal created (.mini/STOP).
  The autonomous /mini:auto will finish the current step and exit cleanly.
  Remove it with `mini stop --clear`.

It creates .mini/STOP. The autonomous run reads it at its checkpoints — between steps and after each finished step in do — and when it finds it, it finishes the step in progress, writes the report, and exits cleanly. No phase is left half-done. When you want to continue:

mini stop --clear

[ok] Stop signal removed — the autonomous /mini:auto will run again.

Both are idempotent (repeated calls break nothing). Two things to remember: the signal is cooperative — it takes effect at the next checkpoint, not instantly. And when you need to cut hard mid-step, that's still Esc/Ctrl+C — but unlike stop, that leaves the phase half-done.

The switches that tune how autonomous it is

auto takes a few inputs that move where it stops:

• --max-phases <n> — how many phases in a row (otherwise it runs to the end of the project).
• --verify — forces verify on every phase, even purely internal ones (otherwise auto runs it only for UI phases).
• --discuss — forces discuss on every phase (otherwise only for ambiguous ones).
• --bump patch|minor|major + --push — version and push when closing phases (default: nothing, just a local commit — no surprises on the remote).
• --yolo — stops pestering you to confirm bash commands. Catch: it only works in a session running in acceptEdits (--permission-mode acceptEdits); --yolo alone doesn't turn off confirmation.

Trade-offs, on the table

• It's not unattended. auto stops — at next, at verify, at a blocker. Start it and walk away for an hour? You'll likely find it standing at a question. That's by design, not a bug, but don't sell it to yourself as "it builds the project on its own".
• Retry caps at 3. When do doesn't finish a phase three times, auto gives up and leaves you a half-done report. Better than an infinite loop, but it means auto can't handle big phases — keep them small, as next enforces anyway.
• Every phase is still a commit. auto doesn't merge the work into one bundle — four phases, four commits. Good for review, but after an autonomous run do actually go through those diffs; "green tests" doesn't mean "good design", and with auto you didn't watch the in-between.
• --yolo + acceptEdits is a loaded gun. You turn off confirmation and let the agent touch files without asking. Fine on a throwaway project; on a real repo, consider what it can do in acceptEdits.

Next time

The project is rolling, phases are piling up — and sometimes you just need to see where you are, or step back. Next time we look at the state commands: status (the overview), undo (one step back), and model (which Claude mini drives each step with, and what it costs you).

---

mini is open source: npm install -g mini-orchestrator, then mini install-commands in your project. Source and docs on GitHub.