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

Published to npm. Node 18+ is the only requirement.

npm i -g @vibehub/cli

# or with pnpm / bun
pnpm add -g @vibehub/cli
bun add -g @vibehub/cli

2. Authenticate

Open the dashboard, generate a token, and paste it once.

vb login
# opens browser → paste vbh_… token

vb whoami
# → you@example.com

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"
# captures code + prompts + model config

vb push
# uploads to VibeHub, mirrors 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 saved, parameterised sequence of vb steps that can be triggered manually or on a schedule. Each trigger creates a run with full logs and an output artifact.

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

Wrap the current git repo as a VibeHub project. Creates .vb/.

vb login

Authenticate with a vbh_ token from the dashboard.

vb status

Show the open session, staged files, and what would be captured.

vb commit -m <msg>

Create a vibe commit. Bundles code, prompts, and model config.

vb push

Upload vibes to VibeHub. Mirrors to your linked GitHub remote.

vb pull

Fetch new vibes from the hub for collaborators or forks.

vb log

List the project's vibe history with prompts and eval scores inline.

vb fork <vibe>

Clone a vibe — code, prompts, specs, and config — into a new project.

vb replay <vibe>

Re-run the exact prompts + model that produced a commit, deterministically.

vb token list / new / revoke

Manage API tokens locally and on the server.

vb mirror set --repo owner/repo --token ghp_…

Link a GitHub remote so vb push mirrors plain-git commits too.

vb mirror push

Re-run the mirror push without touching origin.

vb mirror show

Show the current mirror config and last-push status.

See the full reference with flags and examples by running vb help <command>.

Workflows

Save a vibe sequence, then trigger it.

Workflows are saved vb sequences with typed inputs. Trigger them from the dashboard, the CLI, or the API, and every execution becomes a run with logs and an artifact.

Define

In the dashboard at Workflows → New, or by pushing a .vb/workflows/*.yml file.

yamlname: ship-landing
description: Rebuild the landing page from a prompt diff
inputs:
  - name: headline
    type: string
    required: true
steps:
  - vb replay :prompt_template:
  - vb commit -m "feat: $headline"
  - vb push

Trigger

From the CLI, the dashboard, or POST /api/workflows/:id/trigger.

# from the CLI
vb workflow run ship-landing \
  --input headline="The vibe is the new commit"

# from the API
curl -X POST \
  https://vibehub.co/api/workflows/wf_… \
  -H "Authorization: Bearer vbh_…" \
  -d '{"inputs":{"headline":"…"}}'

Runs surface in the dashboard with live logs, the diff they produced, and a re-run button. Every successful run pushes a fresh vibe.

Fork & replay

Fork the whole vibe, not just the code.

vb fork brings the prompts, specs, model config, and eval baseline along with the source. vb replay re-runs that exact bundle.

# clone the vibe locally
vb fork levelsio/one-pager

cd one-pager
vb log
# v0.3 — "feat: hero copy"   (prompt: "make it bolder")
# v0.2 — "feat: pricing"     (prompt: "3 tiers, indie-friendly")

# replay v0.2 against a different model
vb replay v0.2 --model claude-opus-4-7
# deterministic when seed is preserved

Replays are deterministic when the original seed and model are available; otherwise vb records a drift report so reviewers can see what changed.

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.
  • CLIvb collection add <name> <vibe> pins a vibe to a collection.
  • 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.

Attach an eval.yml to a project and every commit gets graded automatically. Scores show up in the hub, on diffs, and on dashboards.

yaml# .vb/evals/landing.yml
name: landing-page
on: ["commit", "replay"]
checks:
  - id: lighthouse
    target: dist/index.html
    threshold: { perf: 90, a11y: 95 }
  - id: visual-snapshot
    baseline: snapshots/hero.png
    diff_threshold: 0.02
  - id: prompt-faithfulness
    spec: prompts/landing.md
    judge: claude-opus-4-7

Pulled eval results live alongside the vibe so reviewers can see what got better, not just what changed.

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 can summarise activity, suggest workflows, and call any read tool on your behalf.

In your IDE

The MCP server lets Cursor, Claude Desktop, Windsurf, Continue.dev, and Zed talk to VibeHub directly. See the MCP reference.

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 token revoke <prefix>.
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.