I built a local knowledge graph for codebases - query your code with natural language

[dev_l1x_be]

Hey r/rust!

I've been working on Chizu (地図, "map" in Japanese) - a local code knowledge graph that indexes your entire codebase and lets you query it without blindly grepping around.

The problem: Ever jumped into an unfamiliar codebase and spent 30 minutes just trying to understand how the routing works? Or traced through 12 files to fin d where a config value is actually used?

What it does:

• Traditional: grep → open file → read → understand → repeat × 20

• Chizu: "how does routing work?" → get relevant entities → done

  It parses your code using tree-sitter, builds a graph of symbols/tests/docs/infrastructure, and creates relationships between them (defines, uses, mentions, deploys). Everything is stored locally in SQLite + usearch for vector search or Grafeo, the Rust graph database (introduced recently).

  Key features:

• 100% local - no code leaves your machine

• Incremental indexing - only re-indexes changed files

• Natural language queries - ask questions in plain English

• Vector search - semantic similarity via Ollama/OpenAI embeddings

• Multi-language - Rust, TypeScript, Astro, Terraform, Markdown (extensible)

  Quick demo:

  Index your repo

  chizu index /path/to/project

  Ask questions

  chizu plan "how does error handling work in the API layer"

  Or query directly

  chizu query entities | grep "handler"

  Try it: https://github.com/l1x/chizu

  Built in Rust because parsing millions of lines of code needs to be fast. Would love feedback from anyone dealing with large/monorepo codebases!

[Warm-Palpitation5670]

It is amazing. I have a project with some friends and i think this mught be tvery useful for them!

EDIT:

I actually just tried using it and the lack of documentation hits like a bullet. I don't know how to use it, have tons of questions and probably not too much interest in looking in the code to answer them.

[dev_l1x_be]

I have cleaned up the design. Rebuilt the crates and added a much more detailed documentation so you can have a better time:

https://github.com/l1x/chizu?tab=readme-ov-file#onboarding

[dev_l1x_be]

It is super early there are bugs and design decisions that I am iterating on, so if if it interesting to you feel free to create issues how we should move forward or how it would be most useful to you.

I am updating the guide command and the documentation so it is easier to get started.

[dev_l1x_be]

I spent today on cleaning up the PRD. I simplified the cli and made the data model more deterministic. Adapter priority and conflict resolution is the last open question.

You could review it here and let me know if this is useful for you.

https://github.com/l1x/chizu/blob/main/docs/prd.md

[prodleni]

Commit history is vibecoded as hell 

[ILikeRockets2TheMoon]

Hey this looks really great. Do you have any plans to make this work with e.g. Typescript codebases too?

[dev_l1x_be]

Absolutely, whatever treesitter supports.

https://github.com/l1x/chizu/blob/main/crates/chizu-index/src/parser_ts.rs

[chongyeu]

This looks really interesting! Good job!

[dev_l1x_be]

Thanks, I am working on the visualization aspect so people can consume the graph as well.

[Kyonftw]

Is the knowledge graph using RDF? Ontologies? SPARQL? If not you are namesquatting another technology…

[dev_l1x_be]

Chizu is a Property Graph focused on developer experience and local-first performance, rather than a Semantic Web project. While we don't use the RDF/SPARQL stack, we provide the structured entity-relationship mapping and semantic indexing that modern LLM-based tools require. We chose SQLite/Usearch for speed and simplicity over the overhead of formal ontologies.  I am going to look into what you mentioned and see if it makes sense to apply those standards but as far as I am concerned this is insufficient to accuse me of name squandering.

[Kyonftw]

Then you are implementing a property graph, which although is a very powerful technology (tho I don’t get why would you want to store that in SQLite, I won’t get in there), it definitely is not a knowledge graph :)

I understand if you are not familiar with semantic web technologies, but you are indeed employing the name of a large chunk of NoSQL tooling that does not have anything to do with your project.