vibeX

Your architecture diagram is a lie.

vibeX reads the thing that can't lie — your Prisma schema, your OpenAPI document, your GraphQL SDL, or the source itself — and renders the diagram that's actually true. Then it documents the system in claims that fail CI when the code moves underneath them.

One standalone HTML file. No server. Nothing leaves your network.

---

The diagram you have right now

• a whiteboard photo in a Slack thread
• a Confluence page last touched in 2023
• a Miro board nobody can find
• a Mermaid block that stopped rendering
• the one guy who knows

→ one command, run against the schema that actually ships.

npx skills add Raja0sama/vibex -g -a claude-code -a codex -y   # Claude Code + Codex, then just ask
npx @vibex/vibex demo out                                      # or look first: installs nothing

Watch the demo

Why "vibeX"

vibe — how code gets written now. Fast, AI-assisted, more of it than anyone can hold in their head. X — the crossings. Which table joins which. Which service calls which. What happens after approval.

You vibed it into existence. vibeX shows you what you actually built.

The mark is the same idea: two edges crossing. Everything interesting in a system is a line between two things, not the things themselves.

Five diagrams. One source of truth.

	Type	What it draws	Import from
🔵	erd	tables, columns, PK/FK badges, crow's-foot cardinality that knows nullable from not, bounded contexts as groups	Prisma, GraphQL SDL (--erd)
🟣	c4	persons, systems, containers, components, databases, queues, each with its own fill, inside tinted nested boundaries	hand-authored
🟢	endpoints	REST routes, GraphQL operations, published events — grouped by resource, with method badges, auth, params, status codes	OpenAPI 2/3, GraphQL SDL
🟡	lifecycle	every state a thing can reach and every legal move between them, with actor, event, guard and side effect on each arrow	hand-authored
🔷	links	the System view: every call between services, pinned to the client that makes it and the handler that serves it, across repositories	hand-authored from clients and handlers

Each is a validated JSON spec plus a rendered viewer. The spec is the artifact you keep; the HTML is disposable. Documentation and changes are two more views over the same specs, all in one dashboard file. Every diagram also exports as Mermaid (vibex mermaid <spec>, or the button in the viewer) for Markdown that renders it.

Which service calls which. A *.links.json records each call once, anchored on both ends. vibex links checks it against the code:

vibex links system.links.json docs --repo bff=../bff --repo orders=../orders --check

It fails when a client or handler moved, an endpoint it names is gone, or a C4 arrow has no call behind it. It also lists endpoints nothing calls. In a monorepo, pass --repo ..

Three commands. No config file.

# 1. import — your schema becomes a draft spec
vibex import prisma  prisma/schema.prisma  docs/db.erd.json
vibex import openapi openapi.yaml          docs/api.endpoints.json
vibex import graphql schema.graphql        docs/api.endpoints.json

# 2. validate — dangling refs and unreachable states are errors that name the field
vibex validate docs/db.erd.json