Documentation

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.

Quickstart

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 --version

2. 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/ directory

4. 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 GitHub
Concepts

Five 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.

CLI

The vb CLI commands.

vb is a git superset — anything git can do, vb can do plus capture the vibe.

vb init

Register the current git repo as a VibeHub project. Writes .vb/project.json.

vb login / logout / whoami

Save, clear, or show the API URL and vbh_ bearer token.

vb status

Local 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 capture

Re-capture the latest transcript slice and attach it to HEAD. Used by the post-commit hook.

vb push

git push to origin, then mirror to the linked GitHub remote (--no-mirror to skip).

vb log

Recent 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 buy

Check 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>.

Workflows

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 & replay

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_vibe tool that copies the spec and config into a new draft.
  • APIGET /api/vibes/:id returns 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.

Mirroring

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

  1. Open Dashboard → Projects, click the cog on your project (or open it → Settings).
  2. Fill in Owner, Repo, and Default branch.
  3. Paste a fine-grained PAT from github.com/settings/personal-access-tokens with contents: read & write on the target repo.
  4. 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-mirror

Mirrors 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.

Collections

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_collection and add_to_collection tools manage them conversationally.
  • APIPOST /api/collections, then POST /api/collections/:id/vibes.
  • SHAREPublic collections get a permalink — drop it in Discord, Twitter, or a docs page.
Evals

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.

Agent

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.

API tokens

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>.
Data model

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.