Commands

Grouped by when you'd reach for them. Arguments in brackets are optional.

Always

/vbw:vibe [what you want]

The next step, every time. This is the whole product.

Deciding

/vbw:approve

Approve the plan and its checks. Only you can.

/vbw:discuss/vbw:research

Think a decision through; get a sourced answer to a question.

/vbw:todo [idea]/vbw:list-todos

Park an idea; see the list. Where “we should really…” goes instead of dying in a terminal tab.

Checking

/vbw:status

Where the project stands.

/vbw:qa/vbw:verify

Run every check now; judge what only you can.

/vbw:debug [problem]/vbw:fix [what]

Root cause from three angles at once; a quick fix with every check re-run, for when you don't need seven agents to add a comma.

Existing code

/vbw:map/vbw:teach [convention]

Map the codebase; teach VBW your conventions.

/vbw:init/vbw:convert

Set up VBW (vibe does it too); bring in a project from an earlier VBW.

Session

/vbw:pause/vbw:resume

Stop safely; pick up where you left off.

/vbw-status/vbw-why/vbw-todo [idea]

Instant, even mid-run, no model turn: where things stand; who holds the run and why; park an idea.

/vbw:panel/vbw-panel/vbw-sound

Does the panel work here; open Mission Control; sound on or off.

Setup

/vbw:profile/vbw:config

How VBW works in one go; one setting at a time.

/vbw:skills/vbw:rtk/vbw:compress

Find the best tools for your project; compress command output; terser instruction files.

/vbw:help/vbw:doctor/vbw:report

List the commands; check the setup; prepare a bug report.

/vbw:update/vbw:whats-new/vbw:uninstall

Stay current, or remove VBW and go back to prompting manually like it's 2024.

Who works when

Every workflow is deterministic JavaScript. The model doesn't decide who shows up; the kernel does.

Workflow	Started by	Who runs
Planning	`/vbw:vibe` at the plan step	Architect (decisions) → Architect (scope) → Lead
Building	`/vbw:vibe` at the build step	A Dev per ready plan (Docs for documentation), in parallel
Fixing	`/vbw:vibe` when a check fails	A Dev per group of related fixes, in parallel
Verifying	`/vbw:vibe` after the checks pass	A QA agent per built phase, in parallel
Mapping	`/vbw:map`, or planning on existing code	A Scout per angle, then one merged map
Researching	`/vbw:research`	Four Scouts, then one sourced answer
Investigating	`/vbw:debug`	Three Debuggers (reproduce, trace, history), one diagnosis, then one fix
Recommending	`/vbw:vibe` after a ship, or on request	The Architect, once

Configuration

Three presets cover most people. /vbw:profile switches them; /vbw:config changes one setting at a time.

Careful

Models: quality: Opus for Architect, Lead, Dev and Debugger
Autonomy: guided: explains each step and waits for “go”
Good for: Learning, a first project, risky changes

Standard

default

Models: balanced: Opus for the Architect and the Lead, Sonnet for the rest
Autonomy: balanced: keeps going, stops for decisions, approval, checking and shipping
Good for: Most work

Fast

Models: budget: Haiku for Scout, Sonnet for the rest
Autonomy: hands-off: takes its own recommendations and lists them for you
Good for: Small changes, once you trust it

Approval, checking and shipping always stop for you, whatever the preset. Autonomy controls friction, not safety.

Setting	Values	What it does
`profile`	`quality` / `balanced` / `budget`	Which models the agents run on
`model.<role>`	`opus` / `sonnet` / `haiku` / a model id / `default`	Override one agent. QA never runs on Haiku: whatever judges your work doesn't get the cheap seat
`autonomy`	`guided` / `balanced` / `hands-off`	How much `/vbw:vibe` does on its own
`autonomy_cap`	a number	Steps one autonomous run takes before stopping
`rigor`	`auto` / `express` / `standard` / `deep`	How thorough each phase is: sized to the work (`auto`, the default) or forced
`check_jobs`	`1` to `64`	How many checks run at once. Default: about three quarters of the processor cores
`command_timeout`	`1` to `86400` seconds	How long the project's own commands may run in a proof. Default: 3600
status line	`vbw statusline on` / `off`	The status line

Project structure

Everything VBW knows lives in your repository, not in a chat window.

your-project/.vbw/
  spec.md        What you want, in plain words. You own this file
  record.json    The plan of record: phases, plans, checks, results. Only the kernel writes it
  map.md         The map of your codebase, when there is existing code

plugin/
  bin/vbw        The kernel: decides the next step, runs the checks, keeps the record
  lib/           Kernel libraries (bash, jq, git)
  workflows/     Planning, building, fixing, verifying, mapping, researching, investigating
  agents/        Architect, Lead, Dev, QA, Scout, Debugger, Docs
  skills/        /vbw:vibe and every other command
  hooks/         The guards
  scripts/       The status line

Your AI-managed project now has more structure than most startups that raised a Series A.

Requirements

macOS and Linux. On Windows, run Claude Code inside WSL. /vbw:doctor checks all of it.

You need	Why
Claude Code 2.1.286+	Dynamic workflows and the hooks VBW runs on (2.1.287+ for the panel)
A Sonnet, Opus or Fable session	Auto mode; workflow agents may also use Haiku
`jq` and `git`	The kernel. `brew install jq` (macOS) or `apt install jq` (Linux)
A git repository, new or existing	Everything VBW does is committed
The willingness to let an AI build your software and a program check its homework	This is the real barrier to entry

You need one command.

Commands

Always

Deciding

Checking

Existing code

Session

Setup

Who works when

Configuration

Careful

Standard

Fast

Project structure

Requirements

Enough reading.
Press the button.

You need one command.

Commands

Always

Deciding

Checking

Existing code

Session

Setup

Who works when

Configuration

Careful

Standard

Fast

Project structure

Requirements

Enough reading.Press the button.

Enough reading.
Press the button.