Multi-Repository Setup: Separate Specs Repo with FE and BE as Independent Repos

[sbale-cci]

Hi everyone,

I’m exploring a multi-repository architecture and would appreciate guidance on the recommended way to structure this using Spec Kit.

---

Current Setup

I have three separate repositories:

1. projectX-specs

   • Contains constitution, specs, OpenAPI, domain models, ADRs
   • Intended to be the single source of truth
   • All /speckit.constitution, /speckit.specify, and /speckit.plan are run here

2. projectX-be

   • FastAPI backend
   • Needs to consume specs and potentially run /speckit.implement

3. projectX-fe

   • Next.js frontend
   • Needs to consume OpenAPI and shared contracts

The goal is:

• Keep specs authoritative and isolated in their own repository
• Avoid duplicating spec files in FE or BE
• Allow BE and FE to consume the same versioned specs
• Prevent spec drift

---

Core Question

What is the recommended way to use Spec Kit in this multi-repo setup?

More specifically:

• Is Spec Kit designed to work across repositories?
• Is there a supported way to configure a spec root that lives outside the current repo?
• Should specs be shared via Git submodules?
• Or is the expected pattern to publish generated artifacts (for example OpenAPI, TypeScript types, Pydantic models) as versioned packages?

---

Additional Context

I want to avoid:

• Accidental regeneration of specs inside implementation repos
• Duplicate spec directories
• Spec drift between FE and BE

The ideal workflow would be:

1. Specs repo evolves and versions contracts
2. FE and BE depend on a specific spec version
3. /speckit.implement runs only against the canonical spec

Would appreciate any guidance or examples of how others are handling multi-repo setups with Spec Kit.

Thanks!

[mnriem]

Use Spec Kit at the top-level and create the specs there

[sbale-cci]

Hi @mnriem ,

I’m planning to keep the specs in a separate repository and then reference or use those specs within each FE and BE repository. The goal is to avoid a monorepo setup while still allowing both repositories to consume the same specification source.