Hesham Salman
75 lines
3.6 KiB
Markdown
75 lines
3.6 KiB
Markdown
# Vibe mode
|
|
|
|
Vibe mode turns the session into a **director** that drives persistent background
|
|
worker sessions instead of editing code itself. In vibe mode your own toolset is
|
|
stripped down to `read`, optional parent-owned `todo`, plus five worker-control
|
|
tools; the workers do the grepping, editing, running, and building, and you
|
|
verify their work by reading the files they touch. When available, `todo` is
|
|
only the director's parent-session bookkeeping tool; workers do not own it.
|
|
|
|
## Enabling and disabling
|
|
|
|
Toggle it with the `/vibe` slash command:
|
|
|
|
```text
|
|
/vibe # enter vibe mode
|
|
/vibe fix the flaky test in packages/tui # enter and submit a first directive
|
|
/vibe # run again to exit
|
|
```
|
|
|
|
- Entering installs the vibe tools, reduces the active toolset to `read`,
|
|
optional parent-owned `todo`, and the vibe tools, and injects the director
|
|
instructions for the turn.
|
|
- An inline prompt (`/vibe <prompt>`) enters the mode and submits that prompt as
|
|
the first directive.
|
|
- Exiting restores the previous toolset and **kills every worker session** — a
|
|
worker never outlives the mode that directs it.
|
|
- Vibe mode is mutually exclusive with plan mode and goal mode; exit those
|
|
first. The status line shows a `Vibe` indicator while it is on.
|
|
|
|
## The two worker tiers
|
|
|
|
Every worker is a full coding agent with the normal tool surface. You choose a
|
|
tier when you spawn one:
|
|
|
|
| Tier | Backing agent | Model role | Use for |
|
|
|--------|---------------|------------|---------|
|
|
| `fast` | `sonic` | `@smol` (low-latency role) | Mechanical execution, drafts, high-volume work |
|
|
| `good` | `task` | `@task` (the session's strong model) | Design, judgment calls, reviewing `fast` output |
|
|
|
|
Model resolution follows the same path as a `task` spawn, so
|
|
`task.agentModelOverrides` and your model-role settings apply.
|
|
|
|
## Worker-control tools
|
|
|
|
| Tool | Purpose |
|
|
|------|---------|
|
|
| `vibe_spawn` | Start a worker (`fast` or `good`) with a complete, self-contained brief. Workers start blank — they never see the director's conversation. |
|
|
| `vibe_send` | Send a follow-up turn to a worker: a correction, the next step, or a review request. |
|
|
| `vibe_wait` | Block until a worker settles its next turn. Sends and spawns return immediately; results arrive on their own, so call `vibe_wait` only when you cannot proceed without one. |
|
|
| `vibe_kill` | Tear down a worker that is stuck or whose workstream is done. |
|
|
| `vibe_list` | List the active worker roster when you lose track of it. |
|
|
|
|
A spawn or send returns immediately; the worker's turn result is delivered back
|
|
into the director's conversation on its own, exactly like an async `task`
|
|
result. Running one `fast` and one `good` worker on different workstreams
|
|
concurrently is the normal shape.
|
|
|
|
## Workflow
|
|
|
|
1. Split the request into independent workstreams — one worker session per
|
|
workstream so each builds useful local context.
|
|
2. `vibe_spawn` with a self-contained brief: files, constraints, acceptance
|
|
criteria.
|
|
3. Keep directing other workers while turns are in flight; `vibe_wait` only when
|
|
blocked.
|
|
4. When a turn result arrives, `read` the touched files to verify claims before
|
|
building on them. When the optional parent-owned `todo` tool is available,
|
|
reconcile verified work through it, then `vibe_send` the next step.
|
|
5. Route by difficulty: draft with `fast`, escalate to `good` when `fast` stalls
|
|
or the problem needs judgment.
|
|
6. `vibe_kill` finished or stuck workers; `vibe_list` to recover the roster.
|
|
|
|
You stay responsible for the final outcome — verify with `read`, never take a
|
|
worker's word for it.
|