Graphify Ships v0.8.41: A Knowledge Graph Skill for 20+ AI Coding Assistants

Most AI assistants answer codebase questions by reading files one at a time. That burns through the context window fast and misses the relationships between files entirely. A function that calls three services, a schema that three different modules depend on, a config file that quietly governs half the app: none of that shows up in a file-by-file read.

Graphify takes a different approach. Type /graphify . and it maps your entire project into a knowledge graph your assistant can query instead of grep. It works across Claude Code, Codex, Cursor, Gemini CLI, and more than 16 other tools. The project just hit 68.9K GitHub stars and is backed by YC S26.

What Happened

Graphify is a Python package (graphifyy on PyPI, double-y) that installs a /graphify skill into your AI coding assistant. Run it once, and it produces three files in graphify-out/: an interactive graph.html, a GRAPH_REPORT.md summary, and a graph.json you can query any time without re-reading source files.

The project now has 68.9K stars, 98 contributors, and 136 releases. Code is parsed locally with tree-sitter across 36 grammars and never leaves your machine. Docs, PDFs, images, and videos go through your AI assistant's model API.

Worth noting: both @claude and @cursoragent appear in the contributor list alongside 96 human contributors, a sign of how much of this codebase is being built with the tools it targets.

Key Features

• Local code extraction with no API calls: Tree-sitter handles 36 grammars, including Python, TypeScript, Go, Rust, Java, and SQL. A code-only project runs fully offline with no API key required.
• Query commands over grep: graphify query "what connects auth to the database?", graphify path "UserService" "DatabasePool", and graphify explain "RateLimiter" traverse the graph rather than scanning files.
• Confidence tags on every edge: Inferred relationships are marked EXTRACTED, INFERRED, or AMBIGUOUS, so you know what was found versus guessed.
• Multi-source graphs: App code, SQL schemas, Terraform, PDFs, images, and YouTube transcripts all end up in a single graph. Live PostgreSQL introspection works via --postgres DSN.
• MCP server for shared access: python -m graphify.serve exposes tools like query_graph, get_node, and shortest_path. The HTTP transport lets a single process serve an entire team behind an API key.
• Git-friendly team workflow: graphify-out/ commits to git, and graphify hook install sets up a merge driver so graph.json union-merges automatically instead of leaving conflict markers when two people commit at once.

Why It Matters

Most AI assistants rebuild context from scratch on every session. They grep files, read them one by one, and hope the relevant connections show up in the window. Graphify builds a structural map first, then points the assistant at scoped graph queries instead.

Three things stand out:

• The team angle is the practical hook: One person runs /graphify ., commits the output, and everyone who pulls gets the same map. No one rebuilds context from scratch. On Claude Code and Gemini CLI, a PreToolUse hook fires before search-style calls, steering the assistant toward the graph. On Codex, Cursor, and others, persistent instruction files (AGENTS.md, .cursor/rules/, and so on) do the same job.
• The confidence tags make inferences auditable: Built-in retrieval in most assistants is a black box. Graphify's EXTRACTED, INFERRED, and AMBIGUOUS labels tell you how much to trust a connection.
• Offline extraction matters for codebases with data-residency requirements: Code stays on your machine. Only docs, PDFs, and images call a model API; you can route them through Ollama or Bedrock if needed.

Example Use Case

Say you maintain a Python and TypeScript monorepo with a PostgreSQL backend. Run /graphify . to build the initial graph, then add the live schema with graphify extract --postgres "postgresql://user:pass@host/db". Now app code and database schema sit in one graph.

A new engineer asks: "what connects auth to the database?" Instead of opening a dozen files, they run graphify query "what connects auth to the database?" and get a scoped subgraph showing the path from auth handlers through services to the relevant tables. To check a refactor, graphify path "UserService" "DatabasePool" returns the exact chain between two nodes. The GRAPH_REPORT.md flags "god nodes" (the most-connected concepts) and unexpected cross-module links the engineer wouldn't have found by reading.

This is the workflow I'd show a tech lead who's watching their assistant grep the same files on every session.

Competitive Context

Graphify is not a competitor to Claude Code, Cursor, or Codex. It is a skill that runs inside them, which is the point.

Each of those tools ships its own codebase search. Cursor indexes your repo for retrieval; Claude Code reads and greps files during a session. Graphify adds a persistent, queryable structure on top of whichever assistant you use, and it works across all of them rather than tying you to one. Where a single tool's built-in search is a black box, Graphify's output is open: an HTML graph, a markdown report, and a JSON file you can diff and commit. The confidence tags make the assistant's inferences inspectable in a way built-in retrieval usually isn't.

The gap it fills: a shared, version-controlled map of a codebase that any agent can query, rather than each assistant rebuilding context from scratch every session.

My Take

Graphify solves a real problem. Reading files one at a time is a poor way to understand a codebase, and the graph approach scales better as projects get larger and more polyglot. The offline extraction, confidence tagging, and multi-assistant support are all well thought through.

What I want to see tested in practice: whether the shared team graph actually changes how developers coordinate, or whether it mostly reduces the "re-explain the codebase to the assistant" tax. Those are related but different wins. The first would be a meaningful change in how teams use AI coding tools; the second would be a quality-of-life improvement for individuals.

I'm also watching how the MCP server story develops. A single shared graph.json served over HTTP to a whole team is an interesting infrastructure primitive, and I'm curious whether teams end up treating it like a service they maintain or a build artifact they regenerate.