Supervisor
The setting that decides how closely Vibestrate watches a run, and records every call it makes.
A supervisor (its config calls it a persona) is the attitude Vibestrate brings to a run: how closely it should watch the work, and how strict it should be before calling the work done. It does no work itself. It sets the level of scrutiny and leaves a paper trail.
Think of a building inspector. They don’t pour the concrete or hang the drywall. They decide how hard to look, send the risky parts back for a second opinion, and write down every call they make so you can trust the sign-off. The supervisor plays that role for a run.
It is not a rubber stamp. This is what makes the AI’s work trustworthy instead of a yes-man. The supervisor questions the result, tightens scrutiny on the risky changes, tells you honestly whether the review was truly independent, and records every decision it makes so you can check its reasoning later.
What it decides
More care for risky work.
Each supervisor knows which changes deserve extra caution. The built-in staff-engineer watches for things like logins, payments, database migrations, and concurrency. When a task matches, the run is automatically upgraded to a more thorough Flow, such as a multi-reviewer panel, and the exact words that triggered it get recorded. Upgrades only ever add care, never remove it.
An honest label on the review.
If the same AI that wrote the code also reviewed it, the run is marked single-profile. That is a self-check, and a self-check can only lower confidence, not raise it. If a genuinely different AI did the review, it’s marked cross-model.
What the reviewers look for.
A supervisor’s review lenses aim the reviewers at specific things. The security supervisor points them at authorization, secrets, and injection; the default staff-engineer points them at correctness, tests, and security risk. Switching supervisor genuinely changes what the reviewers scrutinise on the same diff, and which lenses ran is recorded. Lenses come from a fixed vocabulary, so a project can’t smuggle free-form instructions into a reviewer’s prompt.
A posture nudge for risky work.
A supervisor can suggest a heavier execution posture for risk-tagged tasks - the security supervisor suggests sandbox-suggested. By default it is advisory: a suggestion surfaced to you, never a gate, and never a downgrade. If you opt in, a suggestion can also apply automatically: posture.autoApplySandbox runs the task OS-sandboxed and posture.autoApplyApproval makes each change wait for approval. Both default off, an explicit --permission-mode always wins, the approval gate is suppressed for --unattended runs, and a provider that can’t sandbox degrades honestly. The default supervisor stays posture-neutral.
A lens on the spec-up phase.
When a run goes through Spec-up, a supervisor can aim the planning agents that scope the work, write the spec, and design the architecture. The security supervisor brings an authorization / secrets / attack-surface lens to that planning; the default stays neutral, so plain spec-up runs are unchanged.
The supervisor enforces the project’s policies.
Project rules - “use a hyphen, not an em-dash”, “no eyebrow labels” - now live at the project level, not on a supervisor (a project-wide rule must hold under whichever supervisor reviews). The active supervisor carries those rules into the review: it injects the advise policies for the model reviewer to check, and the project’s deterministic block policies cap the merge regardless of which supervisor is active. The supervisor can also propose a rule from a consult (“stop using em-dashes”), which lands pending until you confirm it - so a model can never quietly add a rule it enforces. See Policies for the full surface (tiers, capture, and how the soft rules stay distinct from the hard security gates). Earlier versions scoped these to the supervisor as preferences; run vibe policies migrate to move an older config.
These two labels tell you how much the sign-off is worth at a glance:
Picking who reviews
A supervisor can hand all the review work to a different AI with reviewerProfile. Use a cheaper model for routine reviews, or a different vendor when you want a truly independent second pair of eyes. In the config below, the staff-engineer supervisor sends every review seat to a cheap-reviewer Profile, which here runs Claude Haiku:
personas:
staff-engineer:
label: Staff engineer
reviewerProfile: cheap-reviewer # review seats run this Profile
profiles:
cheap-reviewer:
provider: claude
model: claude-haiku-4-5-20251001Anything you choose by hand wins over the supervisor. A per-step profile override, or a run-wide --profile, beats reviewerProfile.
Where you see it
The run screen opens with the Supervisor panel. It shows the active supervisor, a one-line story of why the Flow was chosen (“upgraded to panel-review - matched ‘auth’, ‘token’”), and a live feed of every call it makes: selections, review decisions, denied actions, fallbacks, and budget events. If the Flow ran an arbitration step (a final call that weighs the reviewers’ findings) you see that verdict too, and anything waiting on you to approve or reject sits right there.
Pick the supervisor for a run with the composer’s Supervisor selector or vibe run --supervisor <id>. See what’s available with vibe supervisor list.
