Cross-Repo Architecture

Multi-repo intelligence for local development and pipeline delegation -- how skills detect cross-repo scope, tag plan steps by repo, check sibling impact, and hand off work to the correct repository.

Problem

The Multi-Repo Problem

ADO pipelines run with checkout: self -- each pipeline only has access to the repo where its YAML file lives. But work items frequently span multiple repos.

Bug Reports

A bug report’s root cause may be in the backend repo, but the pipeline runs in the frontend repo.

User Stories

A story may need changes in both frontend and backend repos. Implementation must happen in the repo that owns the affected code.

DoD Checks

DoD checks can span all repos that contribute to a story. Fixing a DoD gap may require changes in a different repo than where the check runs.

Each Repo Has Its Own

CLAUDE.md, .claude/rules/, .ai/config.yaml (project conventions), pipeline instances (different YAML, bound to the correct repo), and installed plugins (same dx plugins but configured per-project).

Solution

The Solution

Each agent type exists as a separate pipeline in each repo. When a pipeline discovers work belongs elsewhere, it delegates.

Pipeline Layout Per Repo

Repo A (e.g. Frontend)          Repo B (e.g. Backend)
BugFix-Agent                    BugFix-Agent
DevAgent                        DevAgent
DOD-Fix-Agent                   DOD-Fix-Agent
DOD-Agent                       DOD-Agent
QA-Agent                        QA-Agent
DOCAgent                        DOCAgent
DOR-Agent                       (no DOR -- single repo)
PR-Review                       PR-Review
PR-Answer                       PR-Answer

Which Agents Support Cross-Repo?

Agent	Cross-Repo?	Reason
BugFix	Yes (delegation)	Bug may be in any repo
DevAgent	Yes (delegation)	Story implementation may target any repo
DoD Fix	Yes (delegation)	DoD failures may require fixes in another repo
PR Answer	Multi-repo routing	Lambda routes to correct repo based on PR repo name
DoD / QA / DOCAgent / DoR / PR Review	No	Read-only, repo-independent, or same-repo only

Pattern 1

Cross-Repo Delegation

Pipeline starts, Claude discovers work targets another repo, writes delegate.json, YAML step queues the target pipeline.

Delegation Flow

From triage to delegate.json to target pipeline -- the full cross-repo handoff.

Pipeline A Claude runs triage/research

Detection Cross-Repo Scope found

delegate.json Claude writes handoff file

YAML Step Reads JSON, queues pipeline

Pipeline B Target repo full context

delegate.json Format

Written by Claude to .ai/run-context/delegate.json

delegate.json

{
"targetRepo": "My-Backend-Repo",
"pipelineId": "789",
"reason": "Bug root cause is in backend Sling models",
"templateParameters": {
  "bugId": "12345",
  "eventId": "evt-001"
}
}

Field	Type	Description
`targetRepo`	string	Name of the target repository
`pipelineId`	string	Pipeline definition ID from `CROSS_REPO_PIPELINE_MAP`
`reason`	string	Human-readable explanation of why delegation is needed
`templateParameters`	object	Parameters passed to the target pipeline run

Where Detection Happens

Coordinator	When	What It Reads
`dx-bug-all`	After Step 1 (triage)	`triage.md` → Cross-Repo Scope section
`dx-agent-all`	After Phase 1 (requirements)	`research.md` → Cross-Repo Scope section
`dx-req-dod`	After Step 1 (DoD read)	`research.md` → Cross-Repo Scope (if exists)

Pattern 2

Lambda-Level Routing (PR Answer)

A different pattern where the target repo is known before Claude starts -- from the webhook payload itself.

PR Answer Routing

The Lambda picks the right pipeline based on which repo the PR belongs to. No Claude involvement for routing.

ADO PR Comment Repo-scoped hook fires

PR Router Extract repo from payload

Pipeline Map Look up repo pipeline ID

Queue Correct repo pipeline

Key Difference from Delegation

No Claude involvement needed for routing. The Lambda itself picks the right pipeline using ADO_PR_ANSWER_PIPELINE_MAP — a JSON object mapping repo names to PR Answer pipeline IDs. Each repo creates its own repo-scoped ADO service hook filtered to that repository + base branch.

Design

Design Decisions

Why delegate.json, why System.AccessToken, and why not route at the Lambda level.

Why delegate.json?

Claude writes a JSON file; a YAML step makes the API call. This avoids giving Claude curl permissions, keeps auth details out of the AI context, and produces a simple, auditable shell script that only runs if the file exists.

Why System.AccessToken?

Automatically available in every ADO pipeline. Has read access to all repos in the same project/collection. Has “Queue builds” permission. No secrets to manage — rotates automatically.

Why Not Lambda Routing?

For BugFix/DevAgent/DoD-Fix, the target repo is not known until AFTER Claude runs triage/research. The Lambda only knows the work item ID — it does not know which repo the fix should go to. Delegation happens mid-pipeline, not at invocation time.

Why Exit After Writing delegate.json?

The pipeline in Repo A does not have the target repo’s codebase, conventions, or plugins. Running the fix there would produce wrong results. Better to delegate to Repo B’s pipeline which has everything set up correctly.

Local

Local Cross-Repo Intelligence

Skills detect, tag, and verify cross-repo impact during local development -- no pipelines required.

Prerequisite

Local cross-repo intelligence requires the repos: section in .ai/config.yaml with at least name, role, and path for each sibling repo.

Skills with Cross-Repo Awareness

/dx-req — Scope Detection

During research (Phase 5c), detects when a story spans sibling repos by checking for cross-repo signals: dialog field dependencies, data model changes, template references, exporter modifications. Appends a ## Cross-Repo Scope section to research.md listing affected repos, field dependencies, and deployment order.

/dx-plan — Step Tagging

When research.md contains a Cross-Repo Scope section, tags each plan step with its target repo: [My-Backend-Repo] Add dialog field. Groups steps by repo with deployment dependency notes (typically backend before frontend).

/dx-pr-review — Field Impact

When reviewing a PR that modifies _cq_dialog XML files, greps sibling FE repos (via repos[].path) for usage of renamed or removed field names. Reports breaking changes and flags new fields available for frontend consumption.

Local Cross-Repo Flow

How cross-repo intelligence flows through the local development workflow.

/dx-req Detects scope across repos

research.md Cross-Repo Scope section

/dx-plan Tags steps with [repo]

/dx-step Developer works per-repo steps

/dx-pr-review Checks sibling field impact

Local

Local Developer Flow (Pipelines)

Cross-repo detection still runs locally, but delegation is manual.

What Happens Locally

When a developer runs /dx-bug-all 12345 locally:

DX_PIPELINE_MODE is not set
Cross-repo detection still runs (triage/research)
Cross-repo scope appears in the summary
No automatic delegation — developer decides

Manual Handoff

The summary tells the developer: “Also affects My-Backend-Repo — run /dx-bug-all 12345 there.” The developer manually switches to the other repo and runs the command. No delegate.json is created.

Config

Configuration Required

Environment variables needed for cross-repo delegation and PR routing.

Per Code-Writing Pipeline (BugFix, DevAgent, DoD Fix)

Variable	Value	Purpose
`CROSS_REPO_PIPELINE_MAP`	`{"My-Backend-Repo":"789"}`	Maps repo names to pipeline IDs of the same agent type
`SOURCE_REPO_NAME`	`$(Build.Repository.Name)`	Set automatically — tells Claude which repo it is in
`DX_PIPELINE_MODE`	`true`	Enables delegation behavior

Per PR Router Lambda

Variable	Value	Purpose
`ADO_PR_ANSWER_PIPELINE_MAP`	`{"Frontend":"123","Backend":"456"}`	Routes PR comments to correct repo’s pipeline
`ADO_ORG_URL`	org URL	For ADO REST API calls

New Repo

Adding a New Repo

Six steps to bring a new repository into the multi-repo automation.

1. Install Plugins

Run /dx-init and /aem-init in the new repo. This sets up .ai/config.yaml, rules, and project knowledge.

2. Import Pipelines

Import pipeline YAMLs into ADO, bound to the new repo. Set pipeline variables (same as existing repos).

3. Update Maps

Update CROSS_REPO_PIPELINE_MAP on all existing code-writing pipelines — add the new repo’s pipeline IDs. Update ADO_PR_ANSWER_PIPELINE_MAP on the PR Router Lambda.

Error Handling

CROSS_REPO_PIPELINE_MAP not set: no delegation — continue locally with warning
Target repo not in the map: log warning, continue locally
ADO API call fails: pipeline step fails — visible in ADO logs
Target pipeline paused/disabled: ADO queues the run but it will not execute
DX_PIPELINE_MODE not set: skip delegation entirely (local mode)