Choose theme
AI Resources
Graft
Graft builds a local context graph that coding agents can use to understand a repository without remapping it from scratch in every session.
Its structural layer uses tree-sitter to map files, symbols, calls, and repository shape without a model or API key. An optional deeper build uses a model chosen by the user to add summaries and concept nodes, while integrations expose the graph through command-line tools, MCP, and agent instruction files. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.
What it is
A repository map for coding agents
Graft turns source structure into a local graph with file cards, symbols, call relationships, repository maps, freshness checks, and linked context that agents can query before editing.
Why it stands out
Readable files instead of a separate graph service
The generated context lives in a local graft folder as readable files and structural sidecars. The core graph does not need embeddings, a vector database, a daemon, or a model call, which makes it a distinct alternative to database-backed code-intelligence tools.
Availability
Public npm package and MIT source
Graft is available as the @nanonets/graft npm package for Node.js 20 or newer. The repository documents a dry run, selective agent setup, local-only structural commands, optional model-backed enrichment, and source under the MIT license.
Why it matters
What makes it useful
Coding agents often spend part of each session rediscovering where code lives and what depends on it. Graft gives them a reusable local map for orientation, call tracing, exhaustive indexed search, and change-impact questions, so more of the session can go toward the actual task.
What to know
Where it fits
Open it when a coding agent needs persistent repository context but a separate vector database or graph service feels heavier than the job. It is especially relevant for recurring work in a large codebase, monorepo, or folder containing several repositories.
Notable points
What stands out
The project reports fewer tokens and tool calls in its controlled benchmark, plus larger single-task savings in a separate repository sweep. Those figures come from Graft's own tests and should be treated as workload- and agent-specific rather than expected results for every repository.
Before using
What to review
The project documents graft init --dry-run for previewing setup changes. Selected agent wiring can change project instructions and user-level Codex configuration or hooks; --no-global narrows that reach.
Keep the generated graft cache and any model-written summaries appropriate for the repository. Source code or sensitive internal details may be sent to the provider chosen for the optional deep build.
For a repository attached to Trail, the README documents a daily background trail push after HEAD changes. GRAFT_TRAIL_AUTOPUSH=0 or trailAutoPush: false disables that path; it is separate from local graph building and the anonymous telemetry setting.
Check language and framework coverage against the repository. Structural analysis is based on the parsers and relationships the current release supports, so dynamic behavior still needs verification in the code and tests.
The project security policy says only the latest published npm release receives fixes; older versions are not separately patched.
Review the anonymous telemetry setting during setup. The project says it does not collect code, file paths, repository names, symbols, queries, prompts, or error messages, and documents ways to inspect or disable the fixed aggregate events.
Reader fit
Who may find it relevant
Developers who repeatedly use Claude Code, Codex, Cursor, Gemini CLI, or another supported coding agent in the same repositories.
Teams comparing readable local context files with SQLite, property-graph, vector-search, or hosted code-intelligence layers.
Builders who want repository maps, symbol search, call tracing, impact checks, and MCP access without running a separate context service.
Less relevant for small one-off projects, non-code knowledge bases, or readers looking for a complete coding agent rather than its context layer.
Editorial note
Why LifeHubber lists it
A question about one package need not query the entire monorepo. Graft documents graft ask with --in to restrict a query to a named sub-project, while queries from a multi-repository parent can search its children. That lets a developer choose whether the question belongs to one package or crosses repository boundaries.
Source links
Source materials
Reader note
Before relying on this entry
LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.
What to explore next
Compare how the repository map is stored and explored.
Graft keeps its working graph in local files and structural sidecars. These alternatives continue the same question with persistent graph databases, broader query surfaces, and visual exploration.
More in AI Agents
Keep browsing this category
Explore more AI agent projects.
Paperclip
paperclipai/paperclip
A self-hosted server and dashboard for coordinating agent teams through companies, goals, roles, issues, heartbeats, budgets, approvals, and persistent activity records.
OpenDots
CopilotKit/OpenDots
An early CopilotKit template for a persistent specialist-agent workspace with editable pages, per-Dot computers, and separately configured conversation, voice, and Slack services.
Hugging Face Serge
huggingface/serge
A GitHub-native pull request reviewer with default-branch rules, Action, App and staged web modes. Optional write-capable tasks can open fix PRs after CI failures; that separate flow is off by default and requires explicit opt-in.
For project maintainers
Listed here? You can use the badge.
If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.
