The Missing Workspace Layer for Agentic Polyrepo Development

Source: Dev.to

Problem Overview

Coding agents can take a feature from spec to a working PR in a single repository—that part is basically solved.
But taking a feature end‑to‑end usually means working across multiple repositories. You need to:

1. Understand the architecture across all repos – coding standards, service relationships, how things connect.
2. Coordinate branches – the same feature branch in every repo that is part of the change.
3. Cross‑repo verification – run tests, check status, and validate across the whole stack, not just within one checkout.

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

The Workspace Layer

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/

• The 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 provides the structure and cross‑repo operations on top of it.

A Day with Mars + 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, so it knows how the services relate, what the coding standards are, and what patterns to follow – across all repos.

Verification

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

Review & merge

Use your standard git/GitHub tooling. Mars coordinates the workspace; the rest of the workflow stays unchanged.

The Workspace Itself Can Be a Git Repo

git clone git@github.com: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

• Version‑control mars.yaml and your agent config together.
• Any developer (or CI job) clones that one repo, runs mars clone, and has a fully bootstrapped workspace in two commands.
• Team onboarding: productive in minutes, not hours.
• CI environments: same two commands to set up cross‑repo verification.
• Standardisation: one source of truth for which repos belong together and how agents should operate across them.

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 that makes sense for your project:

repos:
  - url: git@github.com:org/frontend.git
    tags: [frontend, web]
  - url: git@github.com:org/backend-api.git
    tags: [backend, api, payments]
  - url: git@github.com:org/shared-lib.git
    tags: [shared, backend, frontend]

All commands support --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] appears in both --tag backend and --tag payments queries. Tag by function, team, deployment group—whatever matches how your team thinks about the codebase.

Comparison with Other Multi‑Repo Tools

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

Installation

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

Quick Start

# Create a workspace
mars init

# Add repositories (tags are optional but recommended)
mars add https://github.com/org/frontend.git --tags frontend
mars add https://github.com/org/backend.git  --tags backend

# Clone everything and see the status
mars clone
mars status

Full docs on GitHub:
Website:

When to Reach for Mars

• Multiple repos that need to be worked on together.
• Coding agents are part of your workflow.
• You need shared context and coordinated operations across the stack.

When Not to Use Mars

• Your codebase is already a single monorepo (the problem Mars solves doesn’t exist).
• You require heavy custom plugin ecosystems that Mars deliberately avoids for simplicity.
• You have strict git‑history coupling or release‑cycle constraints that a monorepo already satisfies.

Project Overview

• Repository Structure

  • Tightly coupled repos – use Git submodules.
  • Single repo – just use plain Git.

• Platform Support

  • Requires Windows compatibility.

• License

  • Open source, MIT licensed.

• Community Feedback

  • I’d love feedback—especially from anyone working with coding agents across poly‑repos.
  • What does your workspace look like?