Skip to Content
YOLO Assistant

YOLO Assistant

YOLO Assistant is YOLO Studio’s workspace-aware vibecode guide. It lives in the CommandBar and helps with three different kinds of work:

  • Guidance when you’re already building and get stuck
  • Launch flow when you have a broad goal or want help getting an app live
  • Board authoring when you have many pieces of work to track — turning intent into a Kanban backlog the Background Runner can drain.

The key distinction is that YOLO Assistant does not execute the work itself. It suggests, plans, and then hands work off to existing workspace primitives.

Octavius and Octavia

YOLO Assistant has a name — Octavius by default, or Octavia if you prefer the alternate voice. The persona is the same coach either way; the two names just track which voice you pick (see Voice mode). You can ask “who are you?” or “what can you do?” at any time and get a short, conversational answer rather than a feature dump. Throughout this page, “YOLO Assistant” and “Octavius/Octavia” refer to the same assistant.

Reasoning model

YOLO Assistant is LLM-driven guidance with guardrails.

That means:

  • prompts carry product guidance, preferences, and decision hints
  • workspace context gives the model grounded evidence
  • a small amount of policy stays explicit in code where safety or product integrity requires it

The goal is not to hard-code a fake assistant. The goal is to let the model reason well while keeping a few boundaries explicit:

  • safety limits
  • launch-package constraints
  • paid-action boundaries
  • relevance thresholds before showing curated recipes as meaningful matches
  • deterministic execution hooks where side effects must be controlled

Guidance and board authoring

Guidance and launch

YOLO Assistant handles:

  1. Workspace-aware guidance — grounded next-step help for stuck states, blank previews, failing commands, and broad “what should I do next?” prompts.
  2. Curated recipe suggestion — broad-goal requests can be mapped to a small curated recipe catalog.
  3. Apply-plan output — YOLO Assistant can return a plan with inputs, required capabilities, estimated steps, cost framing, and DNS/TLS notes.
  4. Existing-domain launch package — the launch package deploys the app and connects an existing custom hostname. The operator’s registrar and DNS ownership are preserved; apex domains are treated as a more complex path; subdomain CNAME is the default recommendation.
  5. Launch commit and status — the launch package can create a real agent and start an agent in it, and the CommandBar reads back launch status, current task, blockers, and DNS/TLS guidance.

Board authoring

YOLO Assistant recognizes backlog intent (“break this into tasks”, “make me a backlog”, “seed a board”, “work through these”, “run these in the background”) and loads the kanban-orchestration skill from the vibe-skills loader — a server-side skill registry. Each skill is a directory holding a SKILL.md (YAML frontmatter with name and description, plus the Markdown body) and any supporting files; YOLO Assistant’s reasoning model loads the matching skill, supporting files included, on demand.

The board is the intent; the Background Runner is the execution. The assistant’s job is the backlog — its shape, its ordering, and its acceptance criteria — not the running of it.

A board is not the default

A board earns its ceremony when the work is many independent pieces the operator wants to groom. For a single coherent build, exploratory work, or “help me with X”, one interactive agent tile is better: it is more steerable, and the operator can redirect it mid-flight. A board cannot be redirected mid-card.

Seeding a board is not enough to make it run

This is the step most often missed. Draining requires all of the following:

  1. Cards in the board’s Ready column — the assistant does this.
  2. The board connected as the Runner’s source, with its Ready, Doing and Done columns mapped. The assistant can connect a board it creates when you ask it to, or propose the mapping for an existing board, which applies once you confirm it. You can also connect the board from the Runner’s board picker.
  3. The Runner started — the assistant can do this, but only on explicit request, and only once you confirm.

The mapping is explicit: a column named “Ready” is not drained unless it is the mapped one. A backlog nobody drains looks exactly like a backlog being drained slowly — so when seeding finishes, YOLO Assistant tells you whether the board is connected and the Runner is on.

What the Runner actually picks up

A card is offered for dispatch when all of these hold:

  • it sits in the mapped Ready column,
  • it is not already claimed — neither in flight nor held by an operator (a settled Runner attempt is re-offered only if the workspace’s retry policy allows it),
  • it has not already run — a card with any recorded outcome is skipped unless the retry policy re-admits it,
  • every card it depends on has an accepted result: it succeeded and produced work (a commit or an artifact), any commit has landed on its target branch, and the result passed review where review applies. A dependency retired by a superseding card whose result was accepted also counts.

Two consequences worth internalising:

  • A dependency is satisfied by a successful result, not by column position. Dragging a blocker to Done does not satisfy anything on its own. “Done” is where a human puts a card; the gate reads what the work actually produced.
  • The Runner picks one card at a time, in board order. Each tick takes the first eligible card from the top of the Ready column, so a fan-in’s children start one by one as capacity allows, and its join card waits until every blocker’s result is accepted.

Voice mode

Voice mode lets you talk to YOLO Assistant and hear it talk back, instead of typing in the CommandBar. It’s optional and off by default — turn it on when you want it, leave it off and nothing changes.

When voice is on, YOLO Assistant narrates its replies aloud as Octavius or Octavia. The feel is conversational and two-turn: it acknowledges what you asked first — a quick spoken line so you’re not waiting on silence — and then does the work. So if you say “set up the dashboard preview,” you hear a short “Setting that up now” right away, and the action follows.

You can also ask it to remind you or check back later — “remind me in ten minutes to look at the build,” “let me know when the preview is ready.” YOLO Assistant holds the reminder and comes back to you in the CommandBar when the time comes or the thing happens, picking the conversation back up where it left off.

Turning it on

Voice settings live in Settings → CommandBar Voice:

  • Narrate replies aloud — the main on/off switch for voice mode.
  • Voice — choose Octavius (warm American baritone) or Octavia (warm, clear American voice). This is the same choice that sets which name YOLO Assistant answers to.
  • Opener delay (ms) — fine-tune how quickly the spoken acknowledgement plays.

Narration uses a low-latency server voice on paid plans; on the free plan, replies are read aloud with your browser’s built-in speech instead.

You can override these per workspace from the workspace settings menu — flip narration on or off or switch the voice just for that workspace, and choose Use global default to reset back to your global settings whenever you want.

Even with voice mode off, any individual reply in the CommandBar has a Read aloud control if you’d like to hear just that one.

Workspace memory

YOLO Assistant keeps durable context about each workspace — the kind of standing facts that would otherwise be lost between turns and sessions. Things like “the dev server runs on port 4242,” “this project prefers pnpm,” or a decision you made earlier in the day. These are remembered as workspace notes, separate from the back-and-forth of conversation: conversation history is what was said, the notes are what’s durably true about the workspace.

Because the notes persist, YOLO Assistant’s guidance stays grounded across turns and across sessions. Start a fresh conversation tomorrow and it still knows the workspace’s standing facts — you don’t have to re-explain your setup every time.

You can view and edit the notes yourself. From the workspace settings menu, open View & edit notes… to see the current notes, add or correct facts, and save. The notes are a curated summary, not a transcript — YOLO Assistant trims stale entries as it learns, and you can do the same. If you edit them, your changes ground the very next thing YOLO Assistant does.

What the assistant does not do

  • No domain search, quote, or purchase inside the launch package — domain registration is a separate flow (the domain.search, domain.quote, and domain.intent MCP tools) that is off by default and open only to an allow-listed account cohort; even there, an agent only raises a priced purchase intent and the owner confirms it
  • No registrar transfer
  • No paid action generation in the current launch package
  • No generic commit adapter for every recipe family
  • No open third-party recipe execution registry

If the operator asks YOLO Assistant to buy or register a domain, it explains that its launch package doesn’t cover that path and steers them toward the existing-domain flow.

Architecture

The implementation has three parts.

1. Service layer

A YOLO Assistant service in the YOLO Studio backend owns:

  • curated catalog entries
  • goal-to-recipe suggestion
  • apply-plan generation
  • plan token handling
  • workspace snapshot helpers for guidance and planning
  • the vibe-skills loader for board authoring and other on-demand skills

2. Adapter layer

Recipe-specific execution behavior lives in adapters. The one adapter is launch-package-cloudflare-custom-domain — it owns the commit behavior, launch-specific metadata, and status projection back into YOLO Assistant responses.

3. CommandBar surface

The workspace’s CommandBar is the primary entry point. It:

  • routes guidance-style questions into YOLO Assistant
  • requests recipe suggestions for broad goals
  • requests apply-plan output
  • confirms and commits the existing-domain launch package
  • shows launch-status follow-up after commit
  • speaks replies aloud when Voice mode is on, and keeps workspace memory current
Last updated on
ConceptsGoals