Open-source taught us to fork code. But when software is generated, forking the code traps you at the output layer — you inherit someone's decisions frozen into syntax, with no way back to the intent that shaped them.
Fork the intent, not just the output
vb fork clones the whole vibe. You get the spec and the prompts that produced the project, so you can edit the intent — "make it Postgres instead of SQLite," "add multi-tenancy" — and regenerate, rather than hand-patching generated code you did not write.
vb fork vibehub.co/ada/realtime-chat
cd realtime-chat
vb edit spec.md # change "single room" to "workspaces"
vb replay # regenerate against your new specAttribution that survives the remix
Because every vibe is content-addressed, a fork keeps a verifiable lineage back to its source. The original author is credited automatically, and anyone can trace your remix back through every vibe it descends from.
“A fork used to be a snapshot. Now it is a starting point you can re-derive from scratch.”
Why this matters for teams
Internally, forking a vibe is how a prototype graduates to production. The exploration vibe carries its own prompts and evals, so the team that hardens it is not reverse-engineering a black box — they are extending a documented, replayable starting point.
