Multi-Project Graph — Cross-Codebase Intelligence at Scale

Scenario: Analyzing 15 projects from a parent directory to build a starter template Scale: 15 codebases, ~100,000 nodes, 300,000+ edges, 8 indexed languages Plugin feature: Multi-language graph parsers (v1.5.0) + cross-project repo_root queries

The Problem

When you manage multiple projects — SaaS products, client work, templates — questions span codebases:

• "Which of my projects has the best contact management implementation?"
• "Are all my apps on the same Next.js version?"
• "What tables are in every project vs unique to one?"
• "If I build a starter template, what's the foundation that every app needs?"

Without structural intelligence, answering these requires opening each project, reading files, taking notes, and manually comparing. With 15 projects, that's hours of context-switching.

What Happened

Task: Build a monorepo starter template by analyzing 15 production projects to find the common foundation — database tables, UI patterns, and dependencies that every project shares.

Step 1: Build Graphs for All Projects (2 minutes)

From ~/Projects (the parent directory), built graphs for all 15 child projects in parallel:

build_or_update_graph({ repo_root: "~/Projects/project-a", full_rebuild: true })
build_or_update_graph({ repo_root: "~/Projects/project-b", full_rebuild: true })
...13 more in parallel

Time: ~30 seconds for all 15 graphs (parallel MCP calls).

Step 2: Foundation Table Analysis (instant)

Queried each project's SQL nodes to find tables present in ALL production projects:

For each project:
  SELECT name FROM nodes WHERE kind = 'Table'
→ Intersect across all projects
→ 18 foundation tables found in every project
→ 0 missing from the template

Result: The template's database was already complete — 18 tables, 13 functions, all matching production. The 5 verification tables (passkeys, TOTP) were the only gap — present in 2 of 3 projects.

Step 3: Entity Vertical Analysis — "Carpet Matches Drapes" (instant)

For each foundation entity (contacts, accounts, users, devices, etc.), queried the full vertical across all projects:

This instantly told us which project to copy each feature from — the one with the most complete DB-to-UI implementation.

Step 4: Dependency Version Drift (instant)

Queried Package nodes across all projects:

For each project:
  SELECT name, return_type FROM nodes WHERE kind = 'Package' AND name = 'next'

Found: 9 of 10 projects still on TypeScript 5 (only one on 6). Supabase JS 12 minor versions behind in 5 projects. One project still on Zod 3 while all others moved to Zod 4.

What This Would Take Without the Graph

Token Economics

At multi-project scale, Explore agent overhead multiplies per project. Each agent re-loads its own system prompt, CLAUDE.md, and hooks — then does internal grep/read cycles that are all billed but invisible to the parent context.

Without Graph — Explore Agent Cost

This exceeds any single context window. Reality: you'd need 5-10 sessions, each with its own startup overhead, losing cross-project context between them.

With Graph — MCP Query Cost

All in a single session, with all results in main context for cross-project comparison.

True Ratio

Why multi-project makes the gap exponential: At single-project scale, the graph saves 30x (60k → 2k tokens). At multi-project scale, it's 37x (2.1M → 58k) — but the real cost isn't the ratio. It's that 2.1M tokens can't fit in one session. Explore agents force 5-10 context restarts, losing cross-project comparisons between each. The graph keeps everything in one session, which is what makes cross-project intersection queries (foundation tables, entity verticals, version drift) possible at all.

Head-to-Head: Single-Project vs Multi-Project

The Impact

What Changed in v1.5.0

Four new parsers, all regex-based (no tree-sitter dependency):

1. SQL parser — CREATE TABLE, columns, RLS policies, indexes, foreign keys, triggers, database functions. Supports Supabase migrations + Prisma schemas.
2. Package parser — package.json dependencies (prod/dev/peer), scripts, workspaces. Also turbo.json tasks and pnpm-workspace.yaml.
3. Config parser — tsconfig.json (paths, strict mode), next.config.* (experimental flags), tailwind.config.* (plugins), .env.example (variable names + categories, never values).
4. Markdown parser — Content-level section indexing with classification (rule, convention, decision, reference, setup). Extracts file references from documentation.

Plus:

• Cohesion audit — detects "grab bag" files (many functions, no internal calls), mixed concerns, inline candidates
• Recommendation engine — each finding says "split", "split-on-next-touch", "monitor", or "ignore" with a reason

The graph runs silently. Claude uses it automatically. No configuration beyond /composure:initialize.

Composure v1.5.0 · Claude Opus 4.6 (1M context) · Updated 2026-03-30