Claude Code Knowledge Graph: Setup and Useful Boundaries

A knowledge graph models the relationships between code symbols, modules and architecture findings in a form that Claude Code can query at the start of a task. Instead of scanning the full repository to understand dependencies, Claude Code retrieves a verified map of what connects to what. Tools like fenbs keep the decisions and task state alongside the graph, so the full picture — code structure, agreed rules and current progress — is available to every session.

This guide explains what a code knowledge graph does for Claude Code, how to build one, and where the useful boundary lies between the graph and an outside task record.

What problem a knowledge graph solves

Claude Code's context window is finite. On a large codebase, reading enough files to understand a dependency chain can consume most of the window before any work is done. A session that spends the first twenty turns finding out what calls what is slow and leaves little room for the actual task.

A knowledge graph pre-computes the structure. A query like "which modules import AuthService" returns a direct answer without a file search. Claude Code can then focus its context budget on the relevant code rather than on discovery.

The graph also serves as a verified record. Analysis you ran last week and confirmed is still accurate today. You do not need to re-derive the same findings each session.

What to model in the graph

Start with the facts that take the most time to establish manually:

• Module and file relationships: which files import which, and which packages each module depends on.
• Key symbol definitions: where the main classes, functions and types are defined.
• Public interfaces: which functions and types are part of the public API of each module.
• Verified architecture findings: facts you have confirmed, such as which service owns a particular database table.
• Known entry points: the main files that trigger a given user-facing flow.

Keep the graph focused on structural facts that stay stable across sessions. Avoid putting task state, decisions or work-in-progress notes into the graph — those belong in a task record where they can be updated and attributed.

How to build and query the graph

Several tools generate dependency graphs from source code. For JavaScript and TypeScript, madge and ts-morph can extract import trees. For Python, pydeps and ast analysis produce module dependency maps. Language servers (via LSP) expose symbol and reference data that can be extracted.

Once generated, the graph can be stored as a text file, a JSON structure or a local graph database. Claude Code can read text and JSON natively. A graph database like Neo4j or a simple in-memory store requires a query layer that Claude Code can call as a tool.

The simplest starting point is a plain text or markdown file that lists the key modules, their responsibilities and their main dependencies. This is not a full graph, but it gives Claude Code enough structure to navigate a large codebase without reading every file.

For detailed setup guides on Claude Code's documentation and tooling options, see Claude Code docs and Claude Code sandbox.

Keeping the graph accurate

A graph that drifts from the actual codebase is worse than no graph. Claude Code may rely on stale information and introduce inconsistencies. Mark each entry with the date it was verified. Regenerate the import-dependency parts automatically on each significant refactor.

Manually verified findings — the "AuthService owns the users table" kind — need a person to re-check them when the code changes. Add a note saying who verified each finding and when. Claude Code can flag when it notices a finding that contradicts what it sees in the current code.

Treat the knowledge graph as a living document, not a one-time artifact. A stale graph with outdated dependency edges may be harder to spot than a missing graph, because Claude Code will trust it.

Where the graph ends and fenbs begins

A knowledge graph is for structural, derived facts: import paths, symbol locations, dependency edges. It is generated from the code and regenerated when the code changes.

fenbs is for chosen facts: decisions people made, rules that apply, task progress and lessons. These cannot be derived from the code; they reflect what the team agreed and what happened during the work.

Keep them separate. A single document that mixes import paths with task notes gets stale unevenly and is harder to maintain. The graph is updated by tools; the task record is updated by people and their AI assistants.

How to do this with fenbs

1. Create a free account and add the project.
2. Generate an initial code graph for the codebase and add a summary of its structure as a context note in fenbs.
3. Record key architecture decisions — which service owns what, which patterns were adopted — as Decisions and rules in fenbs.
4. Connect Claude Code from Integrations. Ask it to read the project context before it starts. Point it at the graph file for structural queries.
5. When the architecture changes, update both the graph and the decision record.

For personal knowledge graph software and general knowledge graph tools that are not code-specific, see personal knowledge graph software. For more on Claude Code's setup, see what Claude Code is.