Graphify Turns Your Codebase Into a Knowledge Graph You Can Actually Query

I've watched an agent burn through half its context window just figuring out how three files relate to each other. Grep finds the string, but it doesn't tell you why that function matters or what else breaks if you change it. That's the gap Graphify is trying to close.

Instead of having your assistant read files in sequence to reconstruct your architecture every single session, Graphify builds a graph once and lets the assistant query it like a map, rather than re-deriving it from scratch every time.

What Happened

The safishamsi/graphify repository ships an AI coding assistant skill that turns a folder into a queryable knowledge graph. The latest release is v0.9.2, out this week, with the PyPI package published as graphifyy (double-y) while the CLI command itself stays graphify.

Installation is two steps: uv tool install graphifyy, then graphify install to register the skill with whichever assistant you're using. After that, /graphify . builds the graph. Code parses locally through tree-sitter AST extraction with zero API calls. Docs, PDFs, images, and video route through your IDE session's model instead, so a code-only corpus needs no API key at all.

The graph isn't limited to source code. App code, SQL schemas, infrastructure files, and design docs all land in the same graph, which is what sets it apart from a typical code-search tool.

Key Features

• 36 tree-sitter grammars parse code locally: Python, TypeScript, Go, Rust, Java, Swift, Ruby, C and C++, and more, with CUDA and Metal reusing the C++ grammar rather than needing their own.
• Confidence tags on every relationship: Each inferred connection is marked EXTRACTED, INFERRED, or AMBIGUOUS, so you always know what the graph actually found versus what it guessed.
• Query commands from the terminal or inside your assistant: graphify query for open questions, graphify path between two symbols, graphify explain for a single node's role in the system.
• MCP server exposes structured tools via stdio or HTTP: query_graph, get_node, shortest_path, and get_pr_impact let an agent traverse the graph directly rather than asking you to describe it.
• PR dashboard ranks your review queue: Maps worktrees to branches, flags PRs that share graph communities as merge-order risks before you find out the hard way in a merge conflict.
• Git hook rebuilds the graph on every commit: AST extraction only, no API cost, with a union merge on graph.json so two developers committing at once never end up with conflict markers.

Why It Matters

Most AI assistants answer codebase questions by reading files in sequence or running searches, and both burn context and time on every single question. Graphify writes a small config file that tells your assistant to check the graph first, favoring scoped queries over grepping through raw files. On Claude Code and Gemini CLI, a hook fires before search-style tool calls and automatically nudges the assistant toward the graph path. On Cursor, a rules file with alwaysApply: true does the same job without needing a hook at all.

For teams, the important point is that graphify-out/ is meant to be committed to git. One person builds the graph, everyone else just pulls it, and their assistant has the map on the very first checkout. That removes the cold-start tax every new developer or every new agent session normally pays when it has to reconstruct your architecture from scratch.

Example Use Case

Say you inherit a Django service backed by Postgres with a pile of Terraform sitting next to it. Run uv tool install "graphifyy[terraform]" for the HCL extractor, then /graphify . to build the graph. Now ask /graphify query "what connects auth to the database?" and the assistant traverses the graph instead of opening every model and view file by hand.

For a live schema, graphify extract --postgres "postgresql://user:pass@host/db" introspects the database directly and folds the tables into the same graph as your application code. The result is app code, schema, and infrastructure in one queryable map, so a question about a foreign key links straight to the service that actually writes to it.

Competitive Context

Cursor and Claude Code both read files and run searches on demand, and Graphify works alongside both rather than replacing either. Cursor uses its own codebase indexing for context retrieval. Graphify adds an explicit, committable graph that the whole team shares, rather than each developer's local index drifting independently. Claude Code defaults to file reads and grep; Graphify's hook redirects those calls toward graph queries instead.

The actual differentiator is portability and scope. The graph is a single JSON file that you commit, query offline, or serve over HTTP to a whole team. It also covers more than code: SQL schemas, PDFs, papers, and transcribed video land in the same graph, which is territory neither Cursor's index nor Claude Code's file reads touch. Graphify supports both as install targets alongside Codex, OpenCode, Gemini CLI, and Aider, so the real choice isn't Cursor versus Claude Code. It's the assistant who points at the same shared graph.

My Take

74.8k stars for a tool that's fundamentally about indexing is a strong signal that context efficiency has become a real pain point, not a nice-to-have. Watching an agent spend its budget re-deriving architecture it already encountered last week is the kind of friction that adds up fast across a team.

What I'd actually want to test before betting on this for a large repo: how the graph holds up after months of heavy refactoring, since stale or duplicated nodes are exactly the kind of thing that erodes trust in a tool like this over time. The ghost-duplicate merge fix in the changelog suggests the maintainers are already finding and fixing that class of problem, which is a good sign, but it's worth watching as the project matures.