graphify
essentialLocal deterministic AST parsing produces a queryable knowledge graph that no vanilla agent can replicate — eliminates LLM hallucination and token waste in code
What it is
A CLI tool that parses your project's code (via tree-sitter AST), docs, and media into a local queryable knowledge graph stored as graph.json/graph.html. You query it via `/graphify` commands in your AI assistant instead of reading files. No embeddings, no vector store, code analysis is fully offline and deterministic.
How it differs from vanilla Claude
Vanilla Claude can read files and answer questions about them, but has no persistent structural memory: each session starts from scratch, it cannot trace cross-file AST edges deterministically, it hallucinates connections, and it wastes tokens re-reading files. Graphify gives Claude a pre-built, verifiable, queryable graph of the entire project that it can traverse without touching the files again.
Skill, plugin, or workflow shift?
Skill integration: it plugs into 15+ AI assistants via a configuration file (SKILL.md) that registers the `/graphify` command. This is not a plugin with its own UI; it augments the assistant's context and toolset. The depth is in the local deterministic graph building that the skill references.
Devil's advocate — is this just complexity?
This is a classic 'prompt in a trench coat' trap: the README praises itself for not using LLM for code, but the semantic pass over docs/media still requires an API key, so 'local-first' is not 'local-only'. More critically: Claude can already reason about codebases conversationally — why add a 100MB AST parser and graph file when you can just ask it 'what calls what' and have it read the files? Graphify's edge confidence tags (EXTRACTED/INFERRED) sound like rigor but in practice most connections are straightforward imports and method calls that any decent LLM gets right. The benchmark claims 45.3% QA accuracy vs supermemory's 49.7% — meaning graphify loses on pure Q&A despite all the infrastructure. And what happens when AI assistants build this capability natively (e.g., Claude's upcoming 'project context' features)? Then graphify is a proof-of-concept that becomes legacy. The complexity of installing tree-sitter grammars, managing uv/pipx environments, and maintaining skill files for 15 platforms is significant for a feature that a mid-level engineer can approximate with five well-crafted grep commands.
What would make it better
Make the 'semantic pass' over docs/media work fully offline/local via a small model (e.g., onnx-phi3) instead of requiring an API key. Expose a Python library API so developers can query the graph programmatically in CI/CD pipelines (e.g., 'fail if this PR introduces a circular dependency'). Add a daemon mode that watches files and updates the graph incrementally without re-scanning the whole project. Publish reproducible benchmarks at monorepo scale (100k+ files) to prove performance. Reduce the install footprint: bundle tree-sitter grammars as a single binary instead of downloading per-language.
The honest case for it
Graphify gives you something no vanilla agent can: a deterministic, queryable, always-up-to-date structural map of your entire codebase that is immune to hallucination. For debugging complex cross-file bugs, onboarding new team members, or understanding a large monorepo, it replaces hours of grep-ing and file-hopping with a single path query. The 94k stars and YC backing indicate real traction. If you work on a codebase >50k lines across multiple languages, graphify pays for itself in a week.
Who it's for
Audience fit
Depth and leverage for a technical engineer who wants to understand it and level up their workflow — not just offload work.
Value for someone who wants a more capable tool without the technical depth — accessible, does-it-for-you.
Deep structural understanding of codebases via local deterministic AST parsing gives engineers precise queryable graphs no LLM can match. Vibe coders benefit from the UI and guided questions but the real power is for those who debug complex cross-file dependencies.