When you run vb commit, the CLI does everything git commit does — and then captures the context that produced the change. That context is serialized into a vibe object and stored next to your commit, addressable by the same SHA.
The four parts
Every vibe object has four sections. None of them is optional, because a vibe with a missing part is a vibe you cannot replay.
- spec.md — the human-readable intent, written before or alongside the work.
- transcript.jsonl — the full agent conversation, tool calls included.
- diff.patch — a standard unified diff, identical to what git stores.
- eval.yaml — the checks that prove the diff satisfies the spec.
Content-addressed, like git
Each section is hashed and stored content-addressed, so identical prompts across two vibes are de-duplicated automatically. A vibe object is just a manifest pointing at those hashes plus the config that ties them together.
vb show 4f3a9c
spec spec.md 1.2 KB
prompts transcript.jsonl 18.4 KB (42 messages)
diff diff.patch 6.1 KB (3 files)
eval eval.yaml 0.4 KB (5 checks, all green)
model claude-opus-4-7 temp 0.2 seed 7It rides alongside git, it does not replace it
This is the part teams care about most: vb is a superset of git, not a fork of it. Your remote, your branches, your CI all keep working. The vibe object lives in a parallel ref namespace, so a teammate without vb installed still sees a perfectly normal repository.
Adopt it one commit at a time. The first time you run vb replay on a six-week-old change and watch it rebuild itself, you will stop thinking of the vibe as metadata and start thinking of it as the real source.
