Per-project, so the skill is checked in beside the code it documents:

cd my-project && npx skills add Raja0sama/vibex

Pinned to a published version, if you would rather have a release than a clone of main. SKILL.md ships inside the npm package, so a global install plus one symlink does it:

npm i -g @vibex/vibex
ln -s "$(npm root -g)/@vibex/vibex" ~/.claude/skills/vibex

Under nvm, npm root -g is scoped to the Node version you are on (~/.nvm/versions/node/v22.18.0/...). Install a new Node and both the vibex binary and this symlink stop resolving, silently. skills add has no such problem.

From source, if you are changing vibeX itself — the symlink tracks your working copy, so edits apply the moment you save:

git clone https://github.com/Raja0sama/vibex && cd vibex
ln -s "$(pwd)" ~/.claude/skills/vibex

skills add clones the repository rather than the npm package, and it has no node_modules — run npm install inside the skill folder if you need YAML OpenAPI. The npm paths above already have it.

Confidence is computed, never written. A claim cannot declare how trustworthy it is. The build assigns one of five states from the evidence and the clock, and the validator rejects any claim that tries to rate itself:

verified · stated · needs re-reading · out of date · unverifiable

vibex docs system.docs.json specs/ --repo . --reanchor   # re-pin hashes after a deliberate edit
vibex docs system.docs.json specs/ --repo . --md doc.md  # portable Markdown, zero raw HTML

Incremental, keyed on git. docs.lock.json records the commit each claim last verified at, so a rebuild re-reads only what git says moved — and every uncertainty resolves toward reading more, never less. CI passes --no-lock: a lock file arrives from a contributor's machine asserting that claims were verified, and CI re-reads every anchor rather than taking that on trust.

It tells you what it doesn't cover. Every document renders three lists: what was read, what is deliberately out of scope and why, and what the build noticed but could not account for. A document that implies completeness gets believed exactly where it is wrong.

One artefact, two readers. People read the dashboard panel; agents read docs.json — every fact once, addressable, with resolved edges, so "what breaks if I change this" is a single lookup rather than a search. Narrative sections carry Markdown that cites claims inline with [[claim-id]], rendering each citation as a coloured pip showing that claim's confidence, so a reader sees which words are load-bearing.

One document per question. auth.docs.json, payments.docs.json — each becomes its own dashboard entry. Not one document trying to be the whole system.

Pass --repo to dashboard or every anchored claim renders as unverifiable.

Every claim and node carries a report link. It opens an issue with a fenced vibex block naming exactly what the reader was looking at, so the request arrives with its coordinates attached instead of "the auth docs seem wrong".

reader → pre-addressed issue → triage → agent writes a PR → a person merges

• It answers either way. Actionable or not, the issue gets a reply and a label (ready or needs-info). An intake queue that answers nothing is worse than none.
• It cannot assert its way out. The agent follows the same SKILL.md you do. What it could not establish from the code goes in coverage.out_of_scope, not into a claim under somebody's name.
• It opens, it never merges. The change arrives as a pull request that has already run validate and docs --check. A human still reviews it.
• No API key? Triage still runs, still answers on the issue, still labels it. It just doesn't write anything.

Builds the release list from commit history — and with --specs, what each commit did to the documented system. It becomes a Changes panel in the dashboard, beside the diagrams those commits moved.

vibex changelog HEAD --specs docs/ -o changelog.json --md CHANGES.md
vibex dashboard docs/index.html docs --changelog changelog.json

If the history doesn't use conventional-commit prefixes, sections are inferred from the files each commit touched — and the output says so, in the document: "treat the grouping as a rough sort, not as the author's intent."

• No fetch, XMLHttpRequest or WebSocket, anywhere in the viewer runtime
• No CDN, no web fonts, no analytics, no telemetry — the system font stack and nothing else
• PNG export renders through an in-memory blob; it never touches the network
• Pull the cable out of the wall and it still pans, zooms, searches and exports

Put it on S3 behind SSO, internal nginx, a private Pages site, a Confluence attachment, committed next to the code, or file://. No account to view it. No seats. No expiry. Hand it to a contractor, an auditor, or the new hire on their first morning. It's a file.

A PNG of a 40-table schema is a wall. This one you can interrogate:

/ search · t theme · 0 fit · +/- zoom · r reset layout · Esc clear

Drag any box to move it and its lines re-route to follow. The layout is yours until you reload the page, which puts everything back where it was generated.

Click any node for its columns, fields, params and relationships. #node=<id> deep-links to one specific table in one specific diagram — so you can send someone the thing, not "it's in the doc somewhere." SVG and PNG export produce standalone files in the current theme.

Set meta.repository and sources: [{path, line}] and every node links back to the exact line on GitHub or GitLab.

bin/vibex.mjs            CLI: validate, render, import, dashboard, docs, changelog, demo, types
schemas/                 JSON Schema per type (the authoring contract)
examples/                one example spec per type
renderers/<type>/        JSON -> SVG body
renderers/docs/          claim graph, anchors, markdown export
renderers/shared/        validate, layout (grid, orthogonal routing, edge lanes), svg styles, template, dashboard
importers/               openapi, graphql (own SDL parser), prisma
assets/template.html     single-diagram shell; slots are <!-- VIBEX:* --> comments
assets/dashboard.html    multi-diagram shell: sidebar, overview, cross-links
assets/viewer.js|css     shared viewer runtime, inlined into both shells
assets/icon.svg          the mark (monochrome, currentColor)
test/                    node:test suite + fixtures
SKILL.md                 agent instructions (Claude Code / Cursor skill)

A new diagram type is a schema, a validator function, a renderer that emits data-node-id / data-edge-from|to, and a line in renderers/shared/render.mjs.

• Request workflows — follow one request across service boundaries: the call in, the services it touches, the events it publishes, the tables it writes. C4 shows what could talk to what; this shows what actually happens when somebody presses buy.
• Monorepo support — one repository, many packages, one dashboard. Specs beside the package they describe, anchors that resolve inside it, and a root view that stitches them together without anyone maintaining a list by hand.
• One logical system — thirty services in thirty repositories, rendered as one map: which service owns which table, which one calls which, and where the boundaries actually sit.
• A GitHub Action that runs in your CI, regenerates on every pull request, and comments what moved — "2 tables, 3 endpoints." Still no server.
• A hosted tier, for teams who would rather buy the outcome than own the pipeline. The self-hosted path stays free and stays supported.

These are being designed, not finished. If one of them is the reason you'd adopt this, say so — that is the fastest way to influence it.