VibeVM

vibe · spec-driven development, packaged

Discipline you can install.

A coding agent starts every session knowing nothing about your project. VibeVM fixes that the way a package manager fixed missing libraries: your project declares the rule sets it follows, and vibe resolves them, pins them, and computes the exact text an agent reads first. When a discipline improves, you update it like any other dependency.

The problem

The copy-paste era of agent context

Instruction files became load-bearing: CLAUDE.md, AGENTS.md, and their cousins now decide how agents behave in your repositories. But that text is still managed like a wiki — copied by hand between projects, edited in place, never versioned as the dependency it actually is.

  • The same convention lives in nine repos, in nine slowly diverging copies.
  • A fix to your process ships to exactly one project — the one you happened to be in.
  • Nothing pins what an agent read yesterday, so nothing can reproduce it today.

The model

Two trees, one computed lane

vibe holds a hard line between what you write and what it materialises. Your specifications live in vibevm/vibespecs; installed packages are copied byte-exact into vibevm/vibedeps — committed, so a fresh clone reads without a network, without a tool, without knowing vibe exists. Installing a package never edits your text. Removing one never leaves a trace in it.

The reading order is derived, not declared: foundation, then the project, then dependencies in topological order, then your overrides. Nobody numbers a snippet, and no package can fight another for position.

Attention economics

Every word in the lane is paid for on every session start

So the lane holds instructions, not explanations. Reference depth stays in the packages, loaded when a question actually arises. And because a byte-identical lane is shared, the provider cache one agent warms serves the boss and every worker — which is why nothing per-session, no names, ids, or timestamps, may enter it.

Text costs tokens. vibe is built around that cost.

Capabilities

What the machinery buys you

Reproduce

The lock diff is the changelog of what your agent reads

vibe.lock records the whole resolved graph — version, registry, and a fingerprint of every file. A fresh clone installs the identical graph, and a pull request that changes the lock shows precisely what your agent will now read.

Refuse

Integrity that stops before writing

If a source serves different bytes under a known version — a force-pushed tag, a compromised mirror — vibe refuses before writing anything, naming the fingerprint it expected. Offline mode never touches the network, and a miss is a hard, named error, never a silent partial install.

Address

Corrections in twenty tokens

Specs are cited as spec:// addresses with immutable anchors. “Fix spec://…#RETRY-COUNT” lands on one line; errors name the violated rule as an address, and vibe explain prints it. Renames leave tombstones, so an address you cited keeps resolving.

Trust

No model inside

Every subsystem has a complete algorithmic mode: vibe check is a deterministic linter, and resolution is pure computation. When an operation needs reasoning, vibe parks an instruction in a relay mailbox for your agent to drain. Holding an API key activates nothing.

How it works

Five commands to a booted agent

  1. $curl -fsSL https://vibevm.org/install.sh | bash

    One command installs vibe, vibe-index, and the matching source tree. On Windows: irm https://vibevm.org/install.ps1 | iex.

  2. $vibe init hello-vibe

    An idempotent scaffold: manifest, lock, boot files, and managed blocks in CLAUDE.md, AGENTS.md, GEMINI.md — vibe only ever writes between its own markers.

  3. $vibe install org.vibevm.world/redbook --path hello-vibe

    Resolves the discipline and its dependencies, shows the plan — which packages, which files — and writes nothing until you confirm.

  4. $vibe tree --plain --path hello-vibe

    Prints the computed reading list: exactly what an agent will read at session start, package by package. vibe check verifies the project deterministically.

  5. $claude

    Or codex, opencode, cursor — any agent that can read a file boots from the same lane. The agent never runs vibe to start.

Fit

Where it fits — and where it does not

Reach for VibeVM when

  • the same process discipline should hold across many repositories, and drift is already costing you reviews;
  • several agents — or agents plus humans — work one codebase and need one boot context, byte-identical for each of them;
  • you want your agent corrected by address, not by paraphrase, and your context changes reviewed like code.

It is not

  • an agent — there is no model inside, and nothing activates because a key exists;
  • a replacement for npm or cargo — it manages specs and process discipline, not runtime dependencies;
  • a wiki — the lane is deliberately short, because text costs tokens on every session start;
  • a hosted service — everything runs locally, and a registry is just a git hosting organization.
Status, plainly

The current release is 1.0.0 — a closed alpha, not a compatibility promise: it will break while public = false, and the recovery path is re-init and re-fetch rather than migrations. Open source under UPL-1.0.

Start

Install it, then install a discipline

Linux · macOS · WSL
$curl -fsSL https://vibevm.org/install.sh | bash
Windows PowerShell
PS>irm https://vibevm.org/install.ps1 | iex
Then, in a project:
$vibe install org.vibevm.world/redbook
Then meet Zap

The first product of the VibeVM family: projects, agent conversations, durable questions, and Git worktrees — on one local map.

Why Zap →

In one paragraph

VibeVM treats the context coding agents boot from as a dependency: process disciplines, specs, and skills installed as versioned packages, pinned by content fingerprint, materialised into a committed tree, and compiled into a boot lane any agent consumes by pure file reading. Closed alpha, open source under UPL-1.0: curl -fsSL https://vibevm.org/install.sh | bash.