How manage BMAD for three different domains? E.g. Backend, Frontend and Hardware

[multivac2x]

I have a project that involves three different domains:

• Server (Backend)
• Dashboard (Frontend)
• Sensors (Hardware)

I would like to understand how in BMAD I can manage the analysis of the three different domains.

My initial idea is to have one general analysis and three different repositories, the general analysis and the three repos will be linked together as submodules.

Any suggestion?

[fjanicki]

Having more or less the same question, we have a monorepo with multiple apps / feature libraries (frontend, backend, dbs, etc...) and we would like to be able to focus bmad on implementing a specific feature, usually in a branch. If 2 devs are working in 2 different branches, the bmad files risk having conflicts. Is there a workflow to address this?

Ideally it should ask the feature name at the very beginning (if applicable) and put all output files in _bmad_output/{feature_name}/artifacts

[multivac2x]

I am currently developing as solo, but the issue that some files should or will be modified remains. E.g. Can happen that during the implementation I discover that a feature or a db field is missing.

In addition, how do you manage the architecture for the different frontend, backend, dbs, etc? In my case the DB and APIs are in the backend but they used by the HARDWARE to understand how to send data using the api endpoints.

In any case I am still playing to see how to have the best layout to manage this type of situations.

BTW, playing little bit with the brainstorming modality I got the following that seems quite fine for my case:

Central Repository:
Cross-component epics that span multiple services (e.g., end-to-end user journeys, system-wide features)
Project-level epics for overall architecture decisions

Component Repositories:
Component-specific epics and all user stories for that service
Implementation details and acceptance criteria specific to the component

[nicmosc]

Hi @multivac2x we have a similar problem in my team. We have two monorepos at the moment: backend and frontend.

I tried out BMAD in the frontend monorepo and it works great, however its context is only scoped to the frontend which is not realistic. We sometimes have features that require changes in both repositories in parallel. Plus, i added some customization to BMAD which should apply to both repos, and that both teams can consume.

I didn't quite understand what you ended up doing in your comment, care to explain?

I saw someone else had a similar question here: #1429

[multivac2x]

Multi-Repo Orchestration Setup

This is a work-in-progress solution I've put together for managing documentation and project artifacts across multiple repositories. It's simple, but it handles the issues I needed to solve.

The Repos

I have one orchestrator repo that acts as the central hub, plus these component repos:

• hardware-nodes
• api-server
• frontend
• ai-engine
• mobile

What Lives Where

The orchestrator repo contains all the shared documentation that the component repos might need. Think of these as read-only resources for the components—they should never be edited there.

The main folders in the orchestrator are:

• /docs/ — core project documentation including business analysis, database structure, and API endpoints. Orchestrator is the source of truth.
• /project-management/{component}/ — epics and stories for each component, organized into subfolders by name. Component Repos are the source of truth.
• /business-analysis/{component}/ — component-specific PRDs and related docs (because the PRD for the api-server is quite different from the mobile one, given the different technologies and optimization needs). Orchestrator is the source of truth.

How the Sync Works

The sync flows in two directions depending on the folder, with different sources of truth.

From orchestrator → component repos (read-only docs):
The /docs/ folder in each component repo receives content from the orchestrator's /docs/ directory. This includes business analysis plus any additional documentation like DB schemas and API docs. The orchestrator is the source of truth here, so /docs/ folders in each component repos are added to .gitignore.

From component repos → orchestrator (epics and stories):
The /project-management/ folder in each component repo syncs back to /project-management/{component-name}/ in the orchestrator. This contains an epics.md file and a /stories/ folder where each story lives in its own file—keeping context usage minimal. Epics and stories are managed locally using a local BMAD installation, so the component repos are the source of truth for these.

Not yet in use:
The /business-analysis/{component}/ folders aren't currently being synced. Right now I only have the PRD there, plus in one folder some other files from an old BMAD execution (brainstorming, epics-validation, implementation-readiness-report, product-brief). I'm still figuring out whether I actually need all of these—will revisit soon.

The Glue

Right now I'm using a simple manual bash script with rsync to keep everything in sync. You could set this up as a GitHub Action, but honestly I got annoyed with all the API authentication setup. Having all the repos on my local machine and just running rsync turned out to be way easier.

Planned: AGENTS.md Sync

One thing I'm planning to add is syncing the AGENTS.md file from each component repo's root to the orchestrator. This file is specific to each component and gets continuously updated during fine-tuning work, so the component repos need to be the source of truth.

I'm thinking it should sync to /project-management/{component}/ rather than /business-analysis/{component}/, and run at the end of the rsync script. Haven't implemented this yet, but it's coming soon.

Let me know if you think that something can be improved. As I said at the beginning my solution is a WIP.

[jlethuau]

hello @multivac2x ! Is it possible to get some feedback on this strategy? Is it working, and has it delivered good results, or has it evolved since then? thanks