[Feature]: support and guidance for multi-repo products (microservices architecture) #4583

Problem Statement

Spec Kit currently provides guidance for monorepo scenarios, but many real-world products are built as multiple repositories (microservices), where each repository serves a different function within the same product.

For many organizations, monorepo is not viable due to constraints such as:

• security boundaries,
• team ownership models,
• compliance requirements,
• independent release cadences,
• operational limitations.

Without a dedicated multi-repo approach, applying Spec-Driven Development consistently at the product level becomes difficult, especially for cross-service changes.

Proposed Solution

Add official support (feature and/or documentation) for a multi-repo product workflow tailored to microservices architectures.

Suggested scope:

• Define a way to represent a product as a logical grouping of multiple repositories/services.
• Support linking and tracking spec dependencies across repos.
• Provide a recommended workflow for cross-repo changes, including:
• creating/updating specs per service,
• dependency management,
• compatibility validation,
• release coordination.
• Establish conventions for versioning and traceability across repositories.
• Include practical, end-to-end examples for non-monorepo microservices.

Alternatives Considered

Use monorepo guidance as-is
Not sufficient when monorepo cannot be adopted for organizational or technical reasons.

Keep ad-hoc team conventions per repo
Leads to inconsistent practices, weak traceability, and higher coordination overhead.

Rely only on external tooling/process docs
Helps partially, but lacks first-class, opinionated support within Spec Kit’s own workflow.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

GitHub Copilot

Use Cases

1. A product is composed of several microservices, each in its own repository.
2. A product-level feature requires coordinated updates to multiple services/specs.
3. An API contract change in one service affects dependent services in other repos.
4. Teams need clear mapping from product intent/spec to implementation across all involved repositories.
5. Release readiness depends on compatibility and sequencing across multiple repos.

Acceptance Criteria

• Documentation clearly describes when and how to use a multi-repo workflow (especially when monorepo is not possible).
• A product-level model/grouping for multiple repos/services is defined.
• Cross-repo spec linking/dependency handling is documented (or supported as a feature).
• A recommended end-to-end flow for cross-repo changes is provided.
• Versioning and traceability conventions across repos are defined.
• At least one practical microservices example (non-monorepo) is included.

Additional Context

No response