u/Kitchen-Leg8500

Backstory: when the "Build with Opus 4.7" hackathon was announced, I had the thesis but not the project. I was obsessing over the tokenomics of agents; how to make your tokens go further, and shared that angle in the application even without a concrete build in mind. The direction the tech world is heading, competing between co-workers, teams, or companies to see who can use the most tokens, feels unsustainable to me. In my mind, it should be who can produce the best work with as few tokens as possible.

The application result came back and I wasn't selected. I still believed the project was worth building. After eight substantive cycles of work, v1.0 ships today and I am proud of my findings and the improvements I have felt in quality of code written with the aid of this tool.

What it is: ContextAtlas is an MCP server that runs underneath Claude Code and pre-computes a curated atlas of your codebase, fusing LSP-grade structural precision with architectural intent extracted from your ADRs by Opus 4.7. When Claude calls get_symbol_context("OrderProcessor"), it gets the symbol's signature, governing ADR constraints, recent commits, and related tests in one response. The thing it would otherwise spend 40 tool calls reconstructing.

SYM OrderProcessor@src/orders/processor.ts:42 class
  SIG class OrderProcessor extends BaseProcessor<Order>
  INTENT ADR-07 hard "must be idempotent"
    RATIONALE "All order processing must be safely retryable."
  REFS 23 [billing:14 admin:9]
  GIT hot last=2026-03-14
  TESTS src/orders/processor.test.ts (+11)

Why Opus 4.7 specifically: the extraction pipeline takes prose ADRs and produces structured claims with severity labels, symbol candidates, and rationale. Frozen-prompt invariant; the EXTRACTION_PROMPT constant was validated empirically across 12 production ADRs (100% JSON parse, 169 claims extracted correctly) before the rest of the pipeline was scaffolded. Opus 4.7 at default effort handles this; smaller models tested at calibration time underperformed on the severity-classification axis. The same extraction prompt generalized cleanly across TypeScript, Python, Go, and Ruby codebases without per-language tuning, which I think is itself a meaningful data point about where Opus 4.7 sits on prose-to-structure tasks.

Two paths to set it up:

• Skills path (/index-atlas, /generate-adrs, /prime-atlas); subscription-bounded, no API key required. Best fit if you're already in Claude Code.
• CLI path (contextatlas init && contextatlas index); Anthropic API direct, ~$0.20-1 per incremental refresh, ~$5-15 first-time ADR scaffolding. Best fit for CI/CD integration.

Both produce structurally identical atlases.

Numbers (with caveats): Across hono (TypeScript), httpx (Python), cobra (Go), 45-72% token reduction on architectural-intent prompts with zero quality regression across measured axes. Quality measured under blind paired-mode LLM-judge methodology with pre-registered thresholds (paired-t at N=27 per axis). Factual correctness CLEAN distinguishable win; hallucination and actionability borderline-positive; completeness not distinguishable. 76% tie rate across base pairs confirms anonymization stripped condition-identifying signal cleanly. I wanted measurements, not vibes.

Honest limits: single-judge model (Sonnet 4.6) at v1.0; cross-vendor panel is post-launch work. Quantitative claims bounded to three benchmark repos. Tie- and trick-bucket prompts routinely show ContextAtlas net-negative; that's reported inline rather than buried. Favorable and unfavorable results both ship, including a v0.3 hypothesis of mine that got falsified at v0.5 and is documented as such.

Install:

npm install -g contextatlas
contextatlas init && contextatlas index
# then add the MCP server entry to your Claude Code config (snippet in the README)

What's next: language adapters for Rust, Java, and C# are the obvious gaps, and the adapter interface is small and stable enough that they're realistic community contributions. v1.1 thesis is shaping up around developer onboarding flows and quality-validation work that was deferred from v0.8. External deps repos or documentation outside of the working repo have been tested and expanded, however polishing is set to be in v1.1 as well.

Full write-up: https://www.contextatlas.io/blog/v1.0.0

Repo: https://github.com/traviswye/ContextAtlas

Also launching on DevHunt today: https://devhunt.org/tool/contextatlas; votes are very appreciated if you find ContextAtlas useful or an interesting approach.

Happy to answer anything about the Opus 4.7 extraction pipeline, the methodology, why I bet on FTS5+BM25 instead of embeddings, or anything else. Star the repo if you want to follow along, file an issue if it breaks for you on your codebase, and please be honest; this only gets better with feedback from people running it on real repos.

ContextAtlas is an MCP server I just shipped at v1.0 after eight substantive cycles of work. I came at this from the agent-tokenomics angle; frustrated that most agent tooling treats token budget as unlimited rather than the actual constraint it is. But what I ended up building is more architecturally interesting than I expected, and I think the shape is worth surfacing for this sub specifically: three tools sharing one substrate, not three parallel features.

The three tools:

• get_symbol_context — the primitive. "I know the symbol; give me everything." Returns a fused bundle (signature + ADR-extracted claims + LSP references + git heat + tests + types) in one call. Multi-symbol mode handles up to 10 symbols per request.
• find_by_intent — semantic-query composite over the same substrate. "I don't know the symbol; find it by what it does." Ranks via local FTS5 + BM25 against indexed claim text — no embedding service, no external calls, deterministic.
• impact_of_change — blast-radius composite. "I'm about to change this; what breaks?" Adds git co-change and test impact on top of the primitive.

The composites are thin shells over the primitive; protecting the primitive is the load-bearing engineering investment.

Architectural invariant: zero API calls at query time. All expensive reasoning happens once at index time. Opus 4.7 extracts structured claims from your ADRs, docstrings, and filtered commit messages, keyed to LSP-resolved symbol IDs. Output is atlas.json a committable team artifact that lives in your repo alongside the code. Local SQLite cache derives from it on session start.

That's also the architectural bet vs the graph-based MCP servers in this space (Graphify and others). Same category, pre-computed indexes over codebases, but different shape. They derive structure via parsing/extraction and expose graph primitives (get_neighbors, shortest_path); ContextAtlas delegates structure to language servers and returns pre-composed bundles in one call at query time. Whether that's a better bet for any given workload is an empirical question; benchmark substrate is in the linked repo.

Why FTS5 + BM25 rather than embeddings: deterministic, offline, no external service, exact symbol-form matching. Extended FTS5 to handle identifier-shaped queries — narrow_attribution doesn't get tokenized into narrow + attribution anymore. Embeddings stay on the roadmap as an evidence-gated post-v1.0 enhancement if benchmark data shows they help.

                INDEX TIME (once per source change)
                ──────────────────────────────────────
                ADRs ──────────┐
                Docstrings ────┤
                Git commits ───┼──► Opus 4.7 extraction
                LSP symbols ───┘              │
                                              ▼
                              atlas.json (committed to repo)
                                              │
                                              ▼
                              SQLite + FTS5 BM25 (local cache)

                QUERY TIME (every Claude call, zero API)
                ──────────────────────────────────────
                Claude Code:  get_symbol_context("X")
                                              │
                                              ▼
                              One fused bundle, sub-100ms
                              (LSP refs + intent + git + tests)

Fused Bundle example:

SYM OrderProcessor@src/orders/processor.ts:42 class
  SIG class OrderProcessor extends BaseProcessor<Order>
  INTENT ADR-07 hard "must be idempotent"
    RATIONALE "All order processing must be safely retryable."
  REFS 23 [billing:14 admin:9]
  GIT hot last=2026-03-14
  TESTS src/orders/processor.test.ts (+11)

Two entry points, substrate-equivalent:

• CLI path — contextatlas init && contextatlas index. Anthropic API direct.
• Skills path — /index-atlas, /generate-adrs, /prime-atlas. Subscription-bounded; no API key.

Both produce structurally identical atlases. Mechanical validation gates at both surfaces (contextatlas validate-atlas, validate-adrs) enforce substrate equivalence.

Languages supported at v1.0: TypeScript (tsserver), Python (Pyright), Go (gopls), Ruby (ruby-lsp + optional ruby-lsp-rails). The LanguageAdapter interface is ~6 methods; raw LSP JSON-RPC over stdio, no vscode-languageclient dependency. Rust, Java, C# are realistic community contributions — guide at docs/language-adapter-guide.md.

Numbers (with caveats): 45-72% token reduction on architectural-intent prompts across hono (TS) / httpx (Python) / cobra (Go), with zero quality regression across measured axes. Quality measured under blind paired-mode LLM-judge methodology with pre-registered thresholds (paired-t at N=27 per axis). Factual correctness CLEAN distinguishable win; hallucination and actionability borderline-positive; completeness not distinguishable. Single-judge model (Sonnet 4.6) at v1.0 — cross-vendor panel is post-v1.0 work. Tie- and trick-bucket prompts routinely show ContextAtlas net-negative; that's reported inline rather than buried. 21 ADRs covering every load-bearing decision; full benchmark methodology in a separate repo that is linked throughout the readme.

Install:

npm install -g contextatlas
contextatlas init && contextatlas index
# then add the MCP server entry to your Claude Code config (snippet in the README)

What's next: language adapters for Rust, Java, and C# are the obvious gaps, and the adapter interface is small and stable enough that they're realistic community contributions. Non-markdown ADR formats (RST, AsciiDoc) similarly. v1.1 thesis is shaping up around developer onboarding flows and the dormant-capability-quality-validation work deferred from v0.8.

Full write-up: https://www.contextatlas.io/blog/v1.0.0

Repo: https://github.com/traviswye/ContextAtlas

Also launching on DevHunt today: https://devhunt.org/tool/contextatlas — votes are very appreciated if you find ContextAtlas useful or an interesting approach.

Curious what this sub thinks about the three-tools-one-substrate shape vs the more common graph-primitives shape. Happy to dig into ADRs, the conformance test layout across four language adapters, the query-time-no-API invariant, or anything else. Star the repo if you want to follow along, file an issue if it breaks for you on your codebase, and please be honest; this only gets better with feedback from people running it on real repos.