Advanced Getting Started

You've run Quick Start. One repo is mapped, synced, and shareable. Real systems are messier — a monorepo, a fleet of services, a pile of ADRs that explain decisions the code can't. This page takes you from one board to a modeled landscape: deep layers within a repo, a board per repo, and docs woven in alongside code.

Everything here still runs the plugin path — /analyze → /sync — which needs no model connection. Connect a model provider only when you want to query the landscape in Chat. That's covered in Org-Level Intelligence.

When to go advanced

Reach for this page when any of these is true:

• You have a monorepo with several services or packages under one root.
• You have multiple repos that together form one system.
• You have architecture docs — ADRs, Confluence spaces, design briefs — that hold the "why" your code doesn't.

If none of those apply yet, Quick Start already gave you the whole loop. Come back when your system outgrows one flat board.

Layered analysis within one repo

A single board flattens a real codebase. Layers fix that. The plugin builds a drill-down hierarchy — click a node, see its internals — using three levels:

You start at L0 — that's what /analyze produces by default. Then you drill.

Drill into a node

/analyze --drill my-project/api-gateway

This creates a child board (an L1 layer) for the api-gateway node and analyzes its internals. The argument is <parent-board-slug>/<node-slug> — the board the node lives on, then the node itself. Drill again from an L1 node to reach L2.

Build every layer at once

/analyze --all

This runs the full progressive pass — L0, then L1, then L2 — pausing for review between levels so you can correct course before it goes deeper. Use it for the first deep pass on a substantial repo.

Sync the whole hierarchy

/sync --all

/sync on its own pushes one board (and prompts if you have several). --all pushes the entire layered tree in one shot.

Layers link to their parent automatically. Each drilled node carries a layerBoardSlug pointing at its child board, so in the portal you click a node and navigate straight into its internals — no manual wiring. See Workboards for the layer model in depth.

Multiple repos = multiple plugin bindings

Here's the key Advanced concept, and the one most people get backwards: one plugin binding maps one repo. Three repos means three bindings, each producing its own board and its own layer hierarchy.

This is by design, not a limit. A binding is the contract between a repo on a specific branch and a board in the portal. Keeping it one-to-one gives you a clean, honest representation: each board reflects exactly one codebase's structure, so the model never blurs two repos into a mushy half-truth. When the payments repo changes, only the payments board moves.

Rendering diagram...

How several repos live in one workspace

Each repo gets its own .contextdx/config.json and its own binding token, pointing at its own board. All those boards live in one workspace, so the portal shows them side by side as the top-level layers of your system landscape. From there Chat can draw on them to answer questions — see Org-Level Intelligence for how cross-board querying works today and where it's headed.

To set up a second repo, run /configure from inside that repo against a fresh board. Same flow as Quick Start, new binding.

A note on branches

A binding is tied to one git branch. The branch field in your config must match the branch the board's binding expects, or the next /sync fails with a 400 Branch mismatch. That's deliberate — it stops analysis from a feature branch silently overwriting a board bound to main. If you want a separate snapshot for a long-lived branch, bind a separate board to it.

Board-slug naming

Slugs are how boards reference each other and how the plugin discovers your Root Board. Keep them predictable:

• Name by repo and intent — storefront-overview, payments-overview.
• Let drill-down layers inherit from their parent — the plugin generates child slugs for you.
• Don't reuse a slug across repos; each binding owns its slugs.

Boards from docs

Code gives you accurate structure. It rarely tells you why the architecture is the way it is. Documentation sources fill that gap — and for teams whose truth lives in ADRs or a Confluence space, docs can build a board on their own.

Add a documentation source from the portal's Sources Catalog:

• Confluence — a space or page tree
• Notion — a workspace or database
• Web URL — paste any public doc URL
• Inline Text — paste markdown or notes directly

Then bind it to a board with a role:

Before a governing doc source commits anything, review the extracted nodes and edges. The agent proposes a structure from prose; you confirm it matches reality before it lands on the board. See Connecting Sources for the full source catalog and binding flow.

Combine code + docs

The strongest boards do both. Bind Board Builder as governing (structure from code, kept current by /sync) and docs as reference (the rationale behind that structure). You get an accurate, code-derived graph that the agent can also explain — "why does checkout call the legacy pricing service?" answered from the ADR that decided it.

Rendering diagram...

This is the combination to aim for once a board matters to more than just you. Structure stays honest because code drives it; context stays rich because docs back it.

Keep it current

Layered, multi-repo boards are only useful if they don't rot. They don't — analysis is incremental by default.

After code changes, re-run the same two commands:

/analyze
/sync

/analyze reads the git diff between the commit it last analyzed and HEAD, then re-analyzes only changed and added files and drops deleted ones. It applies across every mode — /analyze, /analyze --drill, /analyze --all each update only what moved in their existing boards. /sync then diffs against the portal's current state and pushes only what changed.

Use /analyze --clean to force a full re-analysis from scratch when an incremental result looks stale.

For the full command and flag reference, see the Claude Code Plugin guide. For the API and payload shape underneath, see the Board Builder API.

Checklist

• Built drill-down layers in one repo with /analyze --drill or /analyze --all
• Synced the full hierarchy with /sync --all
• Set up a second repo as its own binding against its own board
• Confirmed each board's branch matches its binding
• Added a docs source (Confluence / Notion / Web URL / Inline Text)
• Decided governing vs reference for each source and reviewed extracted nodes
• Combined a governing code board with reference docs
• Re-ran /analyze + /sync after a change and saw an incremental update

What's next

You have a rich, layered landscape across repos and docs. Now let your whole org query it.