Everything you need to vibe.
A guided tour through the vb CLI, the vibe object, and the hub — plus how to fork, replay, mirror, and ship.
Ship your first vibe in under a minute.
Install vb, point it at a repo, and commit. The first commit captures the prompts and config that produced it.
1. Install the vb CLI
One command on macOS or Linux — Node 18+ is the only requirement. Working from a checkout of the VibeHub repo instead? npm install && npm link puts the same vb bin on your PATH.
curl -fsSL https://vibehub.co/install.sh | sh
vb --version2. Authenticate
Open the dashboard, generate a token, and paste it once.
vb login
# opens browser → paste vbh_… token
vb whoami
# → API https://vibehub.co · token vbh_3f9c…3. Create a project
Either click + New project in Dashboard → Projects, or wrap an existing git repo from the CLI.
cd my-project
vb init
# wraps the repo with a .vb/ directory4. Commit the vibe
Same shape as git commit. vb captures the open agent session and bundles it in.
vb commit -m "feat: add waitlist"
# commits + uploads the diff and LLM transcript
vb push
# git push to origin + mirror to GitHubFive things to know.
The whole platform rotates around five primitives. Once these click, the rest of the docs are mostly reference.
Project
A git repo registered with VibeHub. Has an owner, a slug, and a visibility (public / private). Create one from Dashboard → Projects or by running vb init in any git repo — never a migration.
Vibe object
A content-addressed bundle of spec, prompts, transcript, model config, diff, eval, and artifact. The unit of work on VibeHub — what gets pushed, forked, and replayed.
Session
An open agent conversation. Starts open, accumulates messages, becomes attached once linked to a commit, and is otherwise cleaned up as orphaned.
Commit
A git commit captured into VibeHub. Carries the diff, file stats, and the session that produced it. Attaching a session to a commit is the moment a vibe is born.
Workflow
A named automation with a trigger (on_commit, on_publish, on_fork, schedule) and an action, triggered from the dashboard or the API. Each trigger creates a run with status and metrics.
Collection
A curated list of vibes — your own or anyone's. Use them to organise the gallery, build playlists, or share a starter pack with your team.
The vb CLI commands.
vb is a git superset — anything git can do, vb can do plus capture the vibe.
vb initRegister the current git repo as a VibeHub project. Writes .vb/project.json.
vb login / logout / whoamiSave, clear, or show the API URL and vbh_ bearer token.
vb statusLocal git status plus transcript capture info (source, pending bytes).
vb commit -m <msg>Stage, commit, and capture the LLM transcript (--amend, --source, --attach-session).
vb captureRe-capture the latest transcript slice and attach it to HEAD. Used by the post-commit hook.
vb pushgit push to origin, then mirror to the linked GitHub remote (--no-mirror to skip).
vb logRecent commits with conversation message counts.
vb show <sha>A commit's message, diffstat, and conversation transcript.
vb diff <sha> [path]Files touched by a commit, or the per-file diff. Reads server-stored diffs.
vb blame <path>Approximate line attribution, replayed from stored vb diffs.
vb branch <list|create|switch|delete|sync>Manage branches; sync reconciles local git branches with the server.
vb checkout <sha>Restore the working tree to a recorded commit (--hard, --branch).
vb mirror <show|set|remove|push|webhook>Configure the GitHub mirror and inbound webhook for two-way sync.
vb remote <install|remove|show>Experimental: wire a vibehub git remote that backs up refs + packs (push-only — clone from your GitHub mirror or origin).
vb sessions <list|show|close>Manage live SDK / MCP sessions.
vb tokens <list|create|revoke>Manage API tokens for the logged-in user.
vb balance / vb buyCheck your credit balance; open a hosted checkout for a credit pack (--list for tiers).
vb hook <install|uninstall|status>Manage vb's git hooks (post-commit, post-merge, post-rewrite, prepare-commit-msg, pre-push).
vb open [<sha>]Open the dashboard for this project (or a commit) in your browser.
vb ai "<intent>"Translate a natural-language intent into vb steps via Claude, confirm, then run.
Any other command falls through to plain git. See the full reference with flags and examples by running vb help <command>.
Save an automation, then trigger it.
A workflow is a named automation with a trigger (on_commit, on_publish, on_fork, or schedule) and an action. Every execution becomes a run with status, metrics, and logs.
Define
In the dashboard at Workflows → New — pick a name, a trigger, and an action. Workflows can be active, paused, or draft; only active ones can be triggered.
You can also ask the in-dashboard agent to create one for you — it has a create_workflow tool.
Trigger
From the dashboard, or POST /api/workflows/:id/trigger (dashboard session auth).
POST /api/workflows/<id>/trigger
# → { "workflow": { …, "status": "active",
# "runsCount": 4 } }Runs surface in the dashboard with status, duration, token usage, and cost. Defining workflows as .vb/workflows/*.yml files in the repo is on the roadmap.
Fork the whole vibe, not just the code.
A fork copies a vibe — spec, prompts, and model config included — into your own workspace, and is tracked back to its source.
- DASHFork any vibe from its page in the gallery or dashboard. Fork counts and lineage show up on the source vibe.
- AGENTAsk the in-dashboard agent — it has a
fork_vibetool that copies the spec and config into a new draft. - API
GET /api/vibes/:idreturns the vibe with its evals and forks, so you can walk the lineage programmatically.
CLI forking and deterministic replay (vb fork / vb replay) are on the roadmap — today forking lives in the dashboard and the agent.
Keep GitHub in the loop.
Every vb push mirrors plain-git commits to a linked remote so your existing CI, code review, and tooling stay exactly where they are.
From the dashboard
- Open Dashboard → Projects, click the cog on your project (or open it → Settings).
- Fill in Owner, Repo, and Default branch.
- Paste a fine-grained PAT from github.com/settings/personal-access-tokens with
contents: read & writeon the target repo. - Save. The token is encrypted at rest; only the prefix is visible afterwards.
From the CLI
# link once
vb mirror set --repo owner/repo --token ghp_…
# from now on every push mirrors
vb push # pushes to origin + mirrors to GitHub
# explicit re-mirror without re-pushing
vb mirror push
# inspect the current config + last status
vb mirror show
# skip the mirror on a single push
vb push --no-mirrorMirrors are one-way by default. The project's commits page surfaces last-pushed sha, last-pushed time, and any push errors. Two-way sync is on the roadmap for Team plans.
Curate, organise, share.
Collections are lightweight playlists of vibes. Use them for landing pages of starter templates, team-internal recipes, or a personal “best of”.
- DASHCreate from the dashboard at Collections → New and drag vibes in.
- AGENTAsk the in-dashboard agent —
create_collectionandadd_to_collectiontools manage them conversationally. - API
POST /api/collections, thenPOST /api/collections/:id/vibes. - SHAREPublic collections get a permalink — drop it in Discord, Twitter, or a docs page.
Score every vibe, not just the code.
Run an eval against any vibe you own and the result — status, score, and duration — is stored alongside it. Scores show up in the hub, on vibe pages, and on dashboards.
# trigger an eval (dashboard session auth)
POST /api/evals
{ "vibeId": "vib_…", "name": "landing-page" }
# → 201 { "eval": { "status": "running", … } }
# poll results for a vibe
GET /api/evals?vibeId=vib_…
# → { "evals": [ { "status": "pass",
# "score": "92.4", "durationMs": 3000 } ] }An eval walks running → pass / fail and records a numeric score. Today execution is a managed placeholder while the real runner is built out — declarative checks (Lighthouse, visual snapshots, prompt-faithfulness judges) defined in an eval.yml are the roadmap shape, not yet live.
An agent that lives in your dashboard.
Every account has an in-app agent that can answer questions about your vibes, kick off workflows, and stage commits — backed by the same data model the rest of the platform uses.
In the dashboard
Open the agent panel from any page. It has a ~35-tool toolkit over your workspace: listing and inspecting vibes, commits, diffs, blame, branches, and analytics, plus write actions — creating and updating vibes, forking, running, managing collections and workflows, and following builders. Destructive tools (delete) require an explicit confirmation turn. Each assistant turn costs 1 credit.
In your IDE
Claude Code gets a full plugin — auto transcript capture plus a /vibehub:capture skill. Everything else speaks MCP: Cursor, Claude Desktop, Windsurf, Zed, JetBrains, Visual Studio, Continue.dev. See the MCP reference and Dashboard → Integrations for one-line installs.
One token for CLI, SDK, and MCP.
Tokens are created in the dashboard at Settings → API tokens. They start with vbh_, are passed as a bearer header, and only the sha-256 hash is ever stored server-side.
- SCOPETokens inherit your account's full permissions. Per-token scopes are on the roadmap.
- DISPLAYOnly the prefix and a label are stored — the plaintext is shown once at creation.
- USEPass as
Authorization: Bearer vbh_…on every API call. - REVOKEFrom the dashboard, or with
vb tokens revoke <id>.
How the pieces fit together.
A rough mental model — useful when you're writing API calls or thinking about what gets versioned.
User
└─ Project (1:N)
├─ Commit (1:N) ← real git commits, captured
│ └─ Vibe (1:1) ← content-addressed bundle
│ ├─ spec / prompts
│ ├─ session ← agent transcript
│ ├─ diff / artifact
│ └─ eval (0:N)
├─ Workflow (1:N)
│ └─ Run (1:N) ← live logs, output vibe
├─ Mirror (0:N) ← github remote
└─ Collection (M:N)Want to query this directly? Head over to the API reference — every entity here has a REST endpoint and an SDK method.