I built a graphical memory for all my projects

After years of accumulated projects, every new AI session often starts with the same task: browse the folders, open the important files, recover the architectural decisions and rebuild an understanding of the project. Graphify offers another approach: turn the files into a knowledge graph that can be queried.

The problem: a collection of projects is not memory yet

A folder contains files. A project contains relationships. One function calls another, a table feeds a service, a screen depends on a hook, an image documents an interface and a README explains why a decision was made.

A classic search finds words. It does not always understand the path between two elements. That is what I wanted to preserve: not only the files, but the connections that give the whole system meaning.

Graphify in a few words

Graphify is an open-source tool that turns a folder of code, documentation, PDFs or images into a queryable graph. Functions, classes, files and concepts become nodes. Calls, imports, references and semantic relationships become edges.

The important distinction is this:

• Code is analyzed locally with Tree-sitter: functions, classes, imports and calls are extracted structurally.
• Documents and images go through semantic analysis with the configured model.
• The graph is stored on disk in a JSON file that can be queried without rereading the entire corpus.
• Each relationship keeps a confidence label: EXTRACTED, INFERRED or AMBIGUOUS.

Graphify is not meant to replace full-text search or a vector database for every use case. Its strength is different: preserve structure and let an AI assistant follow paths between the parts of a system.

Graphify’s official website presents it as a multimodal knowledge graph for coding assistants.

The basic installation

The first step is to install the Python package and register the skill with the coding assistant:

uv tool install graphifyy
graphify install

The package is called graphifyy, while the installed command is graphify. In my environment, the CLI is available as version 0.8.49 and the Claude Code skill lives in ~/.claude/skills/graphify/.

For a single project, the command looks like this:

cd /path/to/my-project
graphify extract .

This produces a graph.json, a readable report and, depending on the selected options, an interactive visualization. Once the graph exists, it can be queried directly:

graphify query "What are the main parts of the authentication system?"
graphify explain "ServiceName"
graphify path "ServiceName" "DatabaseName"

Why I added Ollama

Code can be analyzed structurally without calling a model. Images have to be looked at. A filename such as screen_03.png says very little; a screenshot contains an interface, a workflow, states and sometimes useful clues about the project.

I therefore used Ollama as a local backend for semantic and vision processing. The idea is straightforward: run a multimodal model on my machine, send the images to it during extraction, and store the resulting descriptions and relationships in the graph.

A reproducible configuration looks like this:

uv tool install "graphifyy[ollama]"
ollama serve
ollama pull llama3.2-vision

export OLLAMA_BASE_URL=http://localhost:11434
export OLLAMA_MODEL=llama3.2-vision
export GRAPHIFY_OLLAMA_VISION=1

The vision model name can of course change. The important part is to choose a model that accepts images and explicitly enable Graphify’s vision mode. Ollama’s default text model is not enough for this step.

Graphify handles raster images as separate inputs. It can send their pixels to the vision backend within the model and API size limits. An image that is too large may remain a reference node without being interpreted, which is an important limitation to understand.

Building a global graph

One graph per project is already useful. But my work is spread across several applications, websites, courses and experiments. I therefore registered the project graphs in one global graph:

graphify global add /path/to/meetlux/graphify-out/graph.json --as meetlux
graphify global add /path/to/sillages/graphify-out/graph.json --as sillages
graphify global add /path/to/trajeo/graphify-out/graph.json --as trajeo

graphify global list
graphify global path

The shared file lives here:

~/.graphify/global-graph.json

A separate manifest keeps the registered projects, their source paths, the dates they were added and their node and edge counts. This makes it possible to rebuild or update one project without losing the global view.

What my graph contains

At the time of writing, my global graph contains:

The registered projects are meetlux, ucc-app, ucc-site, myrugby, sillages, weggup, oneeuropuzzle, techniques-graphiques, cours-2026-2027, trajeo, leago and dashboard.

The number that matters most to me is not the node count itself. It is the ability to ask a question across several projects and retrieve the relevant connections without starting from zero.

How Claude Code uses this memory

Installing the Graphify skill adds a simple rule to my workflow: when a question concerns architecture or relationships between files, the assistant should consult the graph before blindly scanning the whole repository.

I can also query the global graph directly:

graphify query "Which projects use Firebase and for what?" \
  --graph ~/.graphify/global-graph.json

graphify query "What connects my mobile apps to their backend services?" \
  --graph ~/.graphify/global-graph.json

In practice, this is not magic: the graph does not replace reading the code when a precise line must be changed. It acts as a context layer. It helps identify where to look, which components are related and which assumptions need to be checked.

What images really add

Images are not just side files. In my projects, they can be a mockup, an app screenshot, a logo, a course screen or a diagram. Putting them in the same graph as the code makes it possible to connect a visible interface to the structure that implements it.

This is especially useful for projects built with Figma, Claude Design or rapid prototyping workflows. A screenshot can become a reference point linked to the files that implement the corresponding screen.

There is an important caveat: a description generated by a vision model is an interpretation, not proof. That is why Graphify distinguishes extracted relationships from inferred ones. The graph is a navigation map, not an authority that removes the need for verification.

Privacy and limitations

• Structural code analysis runs locally.
• With Ollama, document and image analysis can remain on the machine.
• The global graph is a local file, not a hosted index.
• Performance depends heavily on the vision model, available memory and image size.
• The graph must be updated as projects evolve.

Privacy therefore depends on the chosen backend. Ollama reduces the amount of data that needs to leave the machine, but you still need to know which assistant or model is used at each stage. Local configuration is not an automatic guarantee; it is an architectural decision that must be checked.

The result

Graphify helped me move from a collection of projects to a structured memory. Ollama adds an interesting layer: images can be described and connected to the rest of the system without necessarily relying on a cloud service.

The result is not a magic button that makes AI omniscient. It is more useful than that: a persistent, queryable and inspectable context layer that can be updated as the work evolves.

For me, this is another piece of the way I work with AI. Context is no longer only a long instruction file or a past conversation. It becomes a navigable structure shared across projects and concrete enough to be checked against the real code.