48be4674e9
/vibe (a full director/worker orchestration mode) had no user-facing documentation, and /fresh appeared only as a matrix row in the session-operations doc whose title already promised a "fresh" section. Neither was mentioned in the README. - Add docs/vibe-mode.md: enable/disable, fast/good worker tiers, the five vibe_* control tools, and the director workflow. - Add a "## Fresh" section to the session-operations doc describing the provider-stream/session-state reset and its contrast with /new and /drop. - Add a "Session controls" subsection to the README linking both docs. Fixes #6440
72 lines
3.3 KiB
Markdown
72 lines
3.3 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` 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.
|
|
|
|
## 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` + 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, 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.
|