What Is Cross-Repo
Dependency Mapping?
Cross-repo dependency mapping automatically discovers and tracks how repositories in a software organisation depend on each other — answering the question "if I change repo A, what else breaks?" before you make the change.
Cross-repo dependency mapping is the practice of automatically discovering and tracking how repositories in a software organisation depend on each other, by parsing actual source files and building a directed graph of consumer-to-producer relationships across all repos in a GitLab group or GitHub organisation.
Unlike service catalogs (which require manual declaration) or dependency update tools (which react after a new version is published), cross-repo dependency mapping is auto-discovered from code and answers questions before a change is made.
"Cross-repo context": the same idea, named for the AI agent era
As AI coding agents (Claude Code, Codex, Cursor) have moved past the single-file editor into multi-repo work, the platform engineering and AI tooling communities have converged on a new phrase for the same primitive: cross-repo context.
The two terms describe the same artifact from different sides.
Cross-repo dependency mapping is the practice
that produces the graph — parsers reading Terraform source blocks, Dockerfile
FROM statements, go.mod, package.json, Helm
Chart.yaml, and CI include directives across an entire org.
Cross-repo context is the consumed artifact
— the structured knowledge an AI coding agent (or an engineer) reads when querying that
graph to decide whether a change is safe.
Meta's April 2026 post on their tribal knowledge engine describes the same primitive as a "cross-repo dependency index" and reports that providing this layer turns "what depends on X?" from a multi-file exploration of roughly 6,000 tokens into a single graph lookup of about 200 — a 30× reduction. The structural argument behind that number is unpacked in Meta needed 50+ AI agents to map their tribal knowledge — the most durable piece of their stack is the part you can build today.
Whichever phrase fits your team's vocabulary, the underlying object is the same: a queryable, source-derived graph of how repositories depend on each other across every ecosystem in use. The rest of this page uses cross-repo dependency mapping for the practice and graph; the cross-repo context framing applies whenever the graph is being consumed by an agent or human at decision time.
Tribal knowledge is not a dependency strategy
Modern platform and infrastructure teams maintain shared components consumed across many repositories. A Terraform module might be sourced by forty repos. A Docker base image might be pulled by every service in the org. A GitLab CI template might be included by eighty pipelines.
When any of these shared components change, the teams consuming them need to know. Without cross-repo dependency mapping, this knowledge exists only as tribal knowledge in senior engineers' heads. When those engineers leave, go on holiday, or simply can't keep up with the growing number of repos, the organisation loses visibility into its own dependency graph.
The consequences are predictable: breaking changes cascade silently, incident response slows because nobody can trace what depends on what, and new engineers have no way to understand the infrastructure's interconnections.
Silent cascades
Breaking changes propagate through the graph without warning, surfacing only in production failures.
Slow incident response
Engineers spend hours manually grepping repos to trace what depends on a failing component.
Stale catalogs
Service catalog entries go out of date the moment they are created; no tool enforces correctness.
From raw repos to a queryable dependency graph
- 01
Enumerate
Every repository in a GitLab group or GitHub organisation is listed via the platform API — no manual inventory needed.
- 02
Clone
Each repo is shallowly cloned at the default branch. Only the source tree is needed; full history is skipped for speed.
- 03
Parse
Source files that declare dependencies are parsed: Terraform source blocks, Dockerfile FROM statements, CI include directives, Helm Chart.yaml, go.mod, package.json, requirements.txt, and more.
- 04
Detect artifacts
Each repo is also inspected for what it produces: a Docker image, a Python package, a Helm chart, a Terraform module.
- 05
Resolve
Parsed references are resolved to the actual repos or artifacts within the organisation, connecting consumers to producers.
- 06
Build the graph
A queryable directed graph of consumer-to-producer relationships is assembled across the entire org, ready for impact analysis.
The key distinction from other approaches is that the graph is built from what is actually in the code, not from manually maintained metadata. This means it stays current as repos change, without requiring engineers to update a catalog or manifest.
What ecosystems it covers
Cross-repo dependencies exist across every infrastructure and application ecosystem. A comprehensive dependency mapping solution covers all of them — and tracks them together.
- Terraform modules
- Docker base images
- GitLab CI templates
- GitHub Actions workflows
- Helm chart dependencies
- Ansible roles & collections
- Python packages
- Go modules
- npm packages
- Kubernetes & Kustomize
- ArgoCD applications
The real value emerges when these ecosystems are tracked together. A Terraform module change might affect a Docker build, which affects a CI pipeline, which affects a Helm deployment. Single-ecosystem tools miss exactly these cross-boundary connections.
Most valuable for teams managing shared infrastructure
-
Platform engineers
Build and maintain shared infrastructure components consumed by dozens of other teams.
-
DevOps & SRE teams
Need instant blast-radius analysis during incident response to trace what depends on what.
-
Engineering managers
Coordinating breaking changes across teams without days of manual dependency discovery.
-
Organisations with 50+ repos
Using a polyrepo setup — especially those with multiple infrastructure ecosystems.
The problem typically becomes acute when an organisation passes roughly 50 repositories, and becomes critical past 100. It is most painful for teams using multiple ecosystems (Terraform, Docker, CI templates, Helm) rather than a single tool.
Cross-repo dependency mapping for AI coding agents
AI coding agents working across more than one repository hit the same wall human engineers do: the dependency graph that determines whether a change is safe lives outside any single repository's boundary, which means it lives outside the agent's context window.
The teams running coding agents at scale have published their architectures for handling this. Mabl maintains an 850-line Repo Coordination Graph that their agents query at planning time, and reports context drift dropping from ~40% of agent failures to under 5% after the graph shipped. Meta's cross-repo dependency index reduces "what depends on X?" from a multi-file exploration (~6,000 tokens) to a single graph lookup (~200 tokens) — a 30× efficiency gain on one of the most common questions an agent asks during planning.
Cross-repo dependency mapping, exposed as a queryable API, is what these systems converge on. Deterministic parsers across every ecosystem. Refreshed automatically. Queryable as a single lookup. The graph exists separately from the agents and outlasts any single agent session.
Why agents need it specifically
Reconstruction is expensive
An agent re-discovering the graph from raw files pays token cost on every invocation. A precomputed index is paid for once.
Freshness beats training
A model trained six months ago doesn't know about the repos your team created last week. A parser-derived graph from last night's scan does.
The interface outlasts the model
Models change every six months. The dependency graph doesn't. A queryable graph behind a stable API has the same shape whether the agent calling it is Claude 4.7, Claude 5, or whatever runs in 2027.
Riftmap: a cross-repo dependency mapping tool
Riftmap is a change impact engine for multi-repo systems. It scans a GitLab or GitHub organisation with a single read-only access token, automatically discovers every cross-repo dependency from the actual source files across all 12 ecosystems, and builds an interactive dependency graph with visual blast-radius analysis. No per-repo configuration. No YAML to maintain.
Common questions
01 What is cross-repo dependency mapping?
Cross-repo dependency mapping is the practice of automatically discovering and tracking how repositories in a software organisation depend on each other. It answers the question: if I change something in repo A, which other repos are affected? The graph is built by parsing actual source files — not from manually maintained metadata.
02 Is cross-repo dependency mapping the same as "cross-repo context"?
Yes — they describe the same primitive from different sides. Cross-repo dependency mapping is the practice that produces a queryable graph by parsing source files. Cross-repo context is what an AI coding agent (or an engineer) consumes when it queries that graph to decide whether a change is safe. The phrase "cross-repo context" has gained traction as agents like Claude Code, Codex, and Cursor have moved into multi-repo work, where local correctness within a single repository is no longer enough.
03 How is cross-repo dependency mapping different from a service catalog?
Service catalogs (like Backstage) require teams to manually declare their dependencies and keep entries up to date. Cross-repo dependency mapping is auto-discovered directly from code, so it stays current without any human maintenance. It also answers impact questions before a change is made, whereas service catalogs are primarily reference directories.
04 How does cross-repo dependency mapping work?
A dependency mapper enumerates every repository in a Git organisation, shallowly clones each one, and parses source files that declare dependencies — Terraform source blocks, Dockerfile FROM statements, CI include directives, Helm Chart.yaml, go.mod, package.json, and more. It then resolves those references to actual repos and builds a directed graph of consumer-to-producer relationships.
05 What ecosystems does cross-repo dependency mapping cover?
A comprehensive solution covers Terraform modules, Docker base images, GitLab CI and GitHub Actions templates, Helm chart dependencies, Ansible roles and collections, Python packages (requirements.txt, pyproject.toml), Go modules (go.mod), npm packages (package.json), Kubernetes/Kustomize resource references, and ArgoCD application manifests. The real value comes from tracking all ecosystems together, since a change can cross ecosystem boundaries.
06 Which teams benefit most from cross-repo dependency mapping?
Platform engineering teams that maintain shared infrastructure components, DevOps and SRE teams that need blast-radius analysis during incidents, and engineering managers coordinating breaking changes across teams. The problem typically becomes acute at 50+ repositories and critical past 100, especially in organisations that use multiple infrastructure tools.