vikix
A self-hosted code knowledge engine. Point it at a repository and it builds a wiki with a live dependency graph, mines the decisions behind the code, scores its health, and hands a fresh agent session one briefing it can start working from.
- Self-hosted
- One public port
- Zero API keys
- ~30 languages
- 22 MCP tools
- Docker
Every coding agent starts cold. It opens files at random, rebuilds a mental model that was already built yesterday, and has no way to know why a thing was done the way it was. vikix is the attempt to fix that with a real artefact rather than a longer prompt: a durable, queryable model of the codebase that both a person and an agent read from.
docker compose up -d gives you the dashboard, the REST API and an MCP server on a single
port, with no API keys and no external calls. The heavy optional pieces, a Memgraph backbone and a
local model, run as internal services behind that same port when you want them.
01
The dependency graph
Every symbol and every call, coloured by Louvain community. This project is 2,077 nodes and 7,011 edges, laid out from the real graph rather than drawn by hand.
02
The cold-start briefing
One grounded page assembled from the graph: the largest modules, the entry points and their call paths, the risk read, the house style, and why the code is the way it is. Regenerated on every sync.
03
The wiki
Skeleton pages for every module and symbol, each with an architecture diagram compiled from the graph. An agent fills in the prose; the structure and the numbers come from the engine.
04
Health, dead code and flows
A 16-biomarker score per file with repo-level totals, plus dead code and execution flows. Deterministic, with no model in the loop, and the same data agents receive over MCP.
What makes it different
Deterministic first
tree-sitter AST extraction across about thirty languages, a real dependency graph, Louvain communities, MinHash dedup, architecture diagrams compiled from the graph, and skeleton wiki pages. All of it runs with no LLM at all, so the structure of the wiki is never something a model imagined.
The why, not just the what
Architectural decisions are mined verbatim from ADRs, decision-bearing commits, changelogs and inline WHY and DECISION markers, then ranked by provenance and surfaced inline in the wiki. The reasoning behind a piece of code is usually the part that never makes it into documentation.
Built for agents, usable by people
The engine exposes 22 MCP tools, so Claude Code or Codex can ask for a briefing, walk a call chain, or polish a page. The dashboard is the human view of exactly the same data, and an optional local model can answer questions itself for headless setups.
Truly incremental
Content-hash diffing re-extracts only changed files and marks only the affected pages stale, and every MCP response is token-budgeted. A sync after a day of work costs a fraction of the first ingest.
How a sync runs
Three stages, one of them optionalCLI · on your machine
Detect files, hash them, plan the diff, then run tree-sitter over only what changed. Extractions, blobs, git commits and any coverage report are pushed to the engine.
Engine · free of models
Build the graph, resolve symbols, find communities, lay it out, compile diagrams, mine decisions, derive conventions and the briefing, score health, find dead code and flows, and index it all for search.
Agent · optional
A coding agent picks up the skeleton pages through the skill and writes grounded prose, page bundle by page bundle. Nothing about the structure depends on it running.
VDOC, the architecture book
The wiki mirrors the code, one page per module and symbol. VDOC is the other half: a curated hierarchy of conceptual sections and modules, each with its own sub-architecture diagram grounded in the real graph, and deep prose that cites the source it came from.
One command creates it, and every run after that updates only what changed since the last sync. The engine grounds the diagrams and the citations; the agent writes the narrative.