Supervised Build
Let one agent guide another through VibeKit while you stay focused on product decisions.
A supervised build uses two agents.
The supervisor coordinates the work and reviews the result. The builder owns the actual implementation.
VibeKit has a dedicated $supervised-build skill for the supervisor. It starts the builder with a direct $vibekit-deploy handoff. The builder workflow then routes local setup, product decisions, provider setup, focused implementation and verification through the matching skills only when needed.
This keeps the roles clean. The supervisor does not accidentally become the builder just because an implementation skill is needed.
What the supervisor does
- Reads
AGENTS.md, your brief and confirmed product decisions. - Starts a fresh builder in the correct workspace.
- Lets the builder own implementation, local setup, fixes and verification.
- Answers routine repository questions from VibeKit instead of sending them back to you.
- Steps in only for a real blocker, missed VibeKit contract or approval boundary.
- Reviews the evidence and reports what works, what remains and any important workflow friction.
The builder still follows VibeKit's normal process. $vibekit-deploy can route it to local-environment-setup, resolve-product-decisions, full-stack-feature-lifecycle, provider skills and verify-changes without loading everything up front.
Supervisor prompt
Copy this into the agent that will supervise the build:
Use $supervised-build to supervise another coding agent through this VibeKit product build.
You are the supervisor, not the primary builder. Start a fresh builder and let it own implementation, local setup, fixes and verification. Use VibeKit itself to answer routine repository questions. Ask me only for real product decisions or approval boundaries that cannot be discovered or are not already authorized.
Do not purchase services, change DNS, mutate production secrets or data, publish a release or deploy unless I explicitly authorize that action.
Product brief:
[PASTE PRODUCT BRIEF HERE]The second agent does not need a specific model or harness.
Optional tooling note
Pi is one optional agent harness. Its RPC mode exposes JSON responses and event frames over stdin and stdout. A supervisor integration can use that stream to observe the builder session and tool activity directly. Pi is not required for this workflow.