Skeletongraph

Works with

Parses

SkeletonGraph indexes your repository with tree-sitter — no LLM — and hands a coding agent a ranked list of the functions relevant to its task, over MCP. It is also the instrument of a study of what better code retrieval actually buys an agent that has to fix the code, across two production agents, two Claude behavioral regimes, and two benchmarks. The short answer is below; it is more useful, and less flattering, than a token ratio.

Index once with tree-sitter (no LLM) → three signals rank the same symbols → reciprocal-rank fusion returns ranked functions with file and line, served to your agent over MCP.

What we found

We ran the same retriever in every setting we could: without an agent, in a controlled agent loop on an open-weight model, and inside Claude Code (exploratory and lean regimes) and Codex CLI, on SWE-bench Verified and the decontaminated SWE-rebench — 3,433 agent runs, every patch verified by running the project's tests, plus 500 agent-free retrieval evaluations, with every agent comparison paired by task. The evaluation covers Python repositories.

1. It finds code better than every agent's own search

Without an agent, on 100 SWE-bench Verified tasks (file level):

Inside the agents, over all tasks, SkeletonGraph's first search returned a file the fix changes on 80–92% of tasks, against 61–90% for the agents' own first search (87–96% against 60–93% on the tasks where the agent actually called it). The largest margin was Codex, where the right file came first on 71% of the tasks where it was called, instead of 32%.

2. But the agents already found the right code — so that gain doesn't reach the fix

With or without SkeletonGraph, the production agents read code from the right file on 96–100% of tasks — on SWE-bench Verified usually with their very first tool call — and edited it on 88–97%. At the level of functions, where they are far from perfect (63–69% edited a function the fix changes), SkeletonGraph did not move them either. Of the 69 tasks whose outcome differed between arms, 61 were tasks where both arms had already edited the right file: they differ in whether the change was correct, not in where it was made. No production-agent setting showed a statistically detectable solve-rate improvement from retrieval. Only an agent that often failed to find the code on its own — the controlled loop, whose search-free arm edited the right file on 65% of tasks — gained (35 → 42 solved, not statistically significant).

3. What it changes is cost — and the agent decides the direction

Where an agent spends a lot searching, reading and re-checking, SkeletonGraph replaces that work and saves; where it already finds the code in one or two calls, the retriever is added on top and costs a little more. The penalty is small and bounded; the saving grows with how much the agent would have spent.

4. Agents change underneath you

Across two Claude Code windows three weeks apart—exploratory through 2.1.274 and lean at 2.1.278, on the same tasks and prompt—the built-in agent went from 10.9 to 4.7 tool turns per task, read a fifth as much, ran code after editing on 2 tasks instead of 40, and its own first search put the right file first on 85 tasks instead of 59. The same retrieval backend, under a leaner integration, went from saving 93k tokens a task to costing 66k. The product release, available tools, account-loaded skills, integration, and possibly the served model changed together. We can describe the two regimes, not attribute the break to the version number alone. That volatility is part of the result: the meaningful unit of evaluation is the complete, versioned agent environment.

What this means if you use it

• Expect better first searches, not more solved tasks. The bottleneck for current frontier agents is turning located code into a correct fix, which retrieval does not address.
• The saving depends on the complete agent environment. It is largest with agents and tasks that explore a lot, and it can turn into a small overhead with lean ones. Measure it on your own setup.
• Integration instructions cost tokens. On Codex, the shipped integration added 53k tokens a task against 8k for the plain one, with no detectable difference in solve rate.

Every result with its confidence interval and caveats is in docs/RESULTS.md; how to reproduce it is in eval/README.md. The July 2026 preprint reported the first Claude Code release window only.

SkeletonGraph has two product surfaces:

• SG IDE: MCP context server for Cursor, Claude Code, Copilot, Codex, Antigravity, Windsurf, and other agentic IDEs.
• SG CLI: terminal pipeline for route, prepare, dry-run, provider execution, and cost-aware model selection.

How it works

SkeletonGraph parses a repository into function-level structure, a cross-file call graph, and PageRank centrality with zero LLM calls — deterministic, cheap, and instant to rebuild after every edit. At query time it resolves the symbols an issue names, walks the call graph outward, and ranks candidates by three signals — BM25, code embeddings, and structural confirmation — fused with reciprocal-rank fusion.

prompt -> (optional) retrieval planner -> classify task -> find target nodes -> expand graph -> assemble packet

sg-rerank, the product default, skips the dense leg for a lighter index; sg-fusion adds it and ranks best in our retrieval benchmark (table above).

Install

pip install skeletongraph           # core: indexing, MCP server, CLI (no API key needed)

pip install "skeletongraph[llm]" # + litellm for sg run --execute / sg summarize --tier cloud pip install "skeletongraph[all]" # everything, including the evaluation harness

Quick Start: SG IDE

Use this path when you already work inside Cursor, Claude Code, Copilot, Codex, Antigravity, or another MCP-capable coding environment.

`ba