The Missing Workspace Layer for Agentic Polyrepo Development

Coding agents can take a feature from spec to working PR in a single repo. That part is basically solved.

But taking a feature end to end usually means working across multiple repos. You need to configure your agent to understand the architecture across all of them and coordinate work between them. That's where the workflow breaks.

This post is about the workspace layer that makes cross-repo agentic development work.

The Problem: Agent Config and Coordination Across Repos

When a feature touches backend, frontend, and shared libraries, you need three things:

1. The agent needs to understand the architecture across all repos — coding standards, service relationships, how things connect.
2. You need coordinated branches — the same feature branch in every repo that's part of the change.
3. You need cross-repo verification — run tests, check status, and validate across the stack, not just within one checkout.

In a single repo, agents handle all of this naturally. Across repos, you're manually configuring context per repo, creating branches one at a time, and switching between terminals to verify.

The Workspace Structure

Mars creates a workspace where all repos live under one tree:

workspace/
├── .claude/          # or .cursor/, .aider.conf — any agent config
├── CLAUDE.md         # shared context: architecture, standards, patterns
├── mars.yaml         # workspace definition
└── repos/
    ├── backend-api/
    ├── frontend-app/
    ├── shared-lib/
    └── infra/

Agent config at the workspace root is inherited by every repo. You configure your agent once — architecture overview, coding standards, service relationships — and every repo gets that context automatically. No per-repo duplication.

Mars creates this structure and provides cross-repo operations on top of it.

Developer + Agent Workflow

Here's what a day looks like with Mars and a coding agent:

Morning sync:

mars sync              # pull latest across all repos
mars status            # one table: every repo's branch, dirty state, ahead/behind

Starting a feature:

mars branch feature-auth --tag backend    # coordinated branch across backend repos

The agent already has full architectural context from the workspace-level config. It knows how the services relate, what the coding standards are, and what patterns to follow — across all repos.

Agent implements the feature across repos on the same branch, seeing shared config and understanding how services connect.

Verification:

mars exec "npm test" --tag frontend       # targeted tests on frontend repos
mars status                                # which repos changed? any drift?

Review and merge using standard git/GitHub tooling. Mars coordinates the workspace; the rest of the workflow is unchanged.

The Workspace Repo Pattern

Here's something that falls out of this structure naturally: the workspace itself can be a git repo.

git clone [e-mail]:org/platform-workspace.git
cd platform-workspace
mars clone    # clones all repos defined in mars.yaml
# done — full workspace with shared agent config, all repos, ready to work

You version-control mars.yaml and your agent config together. Push it to GitHub. Any developer (or CI job) clones that one repo, runs mars clone, and has a fully bootstrapped workspace in two commands.

• Team onboarding: new developer is productive in minutes, not hours.
• CI environments: same two commands to set up cross-repo verification.
• Standardization: one source of truth for which repos belong together and how agents should operate across them. Reviewed through normal PRs.

This gives you the shared context and reproducibility of a monorepo without coupling git histories, CI pipelines, or release cycles.

Tag-Based Filtering

Every repo in mars.yaml gets tags — however makes sense for your project:

repos:
  - url: [e-mail]:org/frontend.git
    tags: [frontend, web]
  - url: [e-mail]:org/backend-api.git
    tags: [backend, api, payments]
  - url: [e-mail]:org/shared-lib.git
    tags: [shared, backend, frontend]

Every command supports --tag to target subsets:

mars branch feature-x --tag backend       # branch only backend repos
mars exec "npm test" --tag frontend        # test only frontend repos
mars status --tag payments                 # status for payments-related repos
mars sync --tag shared                     # pull latest on shared repos only

Multiple tags per repo enable cross-cutting operations. A repo tagged [backend, payments] shows up in both --tag backend and --tag payments queries. Tag by function, by team, by deployment group — whatever matches how your team thinks about the codebase.

Existing Tools and Tradeoffs

Mars isn't the first multi-repo tool. Here's how it compares:

Tool	Language	Config	Approach
git submodules	git-native	.gitmodules	Couples repos at git level, tracks specific commits
gita	Python	CLI-based	Group and manage repos, requires Python
myrepos	Perl	.mrconfig	Config-file driven, powerful but complex
meta	Node	meta.json	JSON config, plugin system
Mars	Bash	mars.yaml	Tag-based filtering, zero deps, workspace-as-agent-config design

Mars trades extensibility and plugin systems for zero dependencies and simplicity. The main differentiator is design intent: Mars creates a workspace structure where agent config sharing is an emergent property of the layout. Other tools manage repos; Mars creates a workspace that agents can inhabit.

Getting Started

# Install
npm install -g @dean0x/mars

# Or: brew install dean0x/tap/mars
# Or: curl -fsSL https://raw.githubusercontent.com/dean0x/mars/main/install.sh | bash

# Create a workspace
mars init
mars add https://github.com/org/frontend.git --tags frontend
mars add https://github.com/org/backend.git --tags backend
mars clone
mars status

Full docs on GitHub: github.com/dean0x/mars

Website: dean0x.github.io/x/mars

Wrapping Up

Mars is for teams that want independent repos but need a coherent workspace for agentic development. It creates the structure, coordinates the git operations, and gets out of the way. The agents handle the rest.

When to reach for it: multiple repos, coding agents in your workflow, need for shared context and coordinated operations across the stack.

When not to: tightly coupled repos (use submodules), single repo (just use git), need Windows support.

It's open source, MIT licensed, and I'd love feedback — especially from anyone working with coding agents across polyrepos. What does your workspace look like?