I am currently working in a multi-repo brownfield, and I would like to use Spec Kit, but was not sure how well it would work in this scenario, especially with an existing codebase implemented in multiple repos, with an existing separate repo for specs.

The TLDR is that it worked well, and I think I can make some additional edits to the constitution to make it work even better. Spec Kit was able to put specs in our spec repo, obtain context from a code repo, and correctly implement the code in the code repo.

The project, Radius, maintains multiple repositories with distinct purposes: a design-notes repository for specifications and architectural decisions, a repository containing the actual implementation of the core codebase, a repo for docs, a web UI dashboard, and a repo for resource types and recipes, as well as a few others that I did not include in this test.

This test aimed to answer the overall question by implementing a real feature, Kubernetes health probes for the Universal Control Plane (UCP) using Spec Kit's full workflow (specify → clarify → plan → analyze → implement). The results would determine whether Spec Kit could be adopted without disrupting our established repository organization.

NOTE: I used large prompts for the constitution (~30 lines), and specification (~120 lines) but I did not tell Spec Kit where to find the code. It discovered the radius repository autonomously.

Test Configuration

Repository Structure

The test used a VS Code Insiders multi-root workspace with five repositories. I was only interested in working in two of the repositories, but I wanted to see if Spec Kit could reason across all of them and find the right repo for the code.

1. design-notes (https://github.com/radius-project/design-notes) - Specifications and design documents
2. radius (https://github.com/radius-project/radius) - Core implementation codebase
3. docs (https://github.com/radius-project/docs) - Documentation website
4. dashboard (https://github.com/radius-project/dashboard) - Web UI dashboard
5. resource-types-contrib (https://github.com/radius-project/resource-types-contrib) - Community-contributed resource types and recipes

Spec Kit was installed in the design-notes repository with constitution and templates, while the other repositories were included as workspace folders to provide code context.

Workspace Setup

VS Code workspace/
├── design-notes/          # Spec Kit installed here
├── radius/                # Core implementation
├── docs/                  # Documentation
├── dashboard/             # Web UI
└── resource-types-contrib/ # Resource types & recipes

Test Results

Context Awareness

Spec Kit demonstrated cross-repository awareness throughout the workflow:

Autonomous Discovery (when resolving "NEEDS CLARIFICATION" markers):

• Go version: 1.25.0 from radius/go.mod
• HTTP framework: go-chi/chi/v5 from route inspection
• Logging: go-logr with uber-go/zap from radius/pkg/ucp/ucplog/

Accurate File References across artifacts:

• plan.md: Referenced actual radius paths (pkg/ucp/server/server.go, deploy/Chart/values.yaml, .github/workflows/)
• tasks.md: All 50 tasks used correct radius repository file paths
• Constitution checks validated against existing radius patterns (linting, test infrastructure)

Implementation Accuracy:

• Modified existing files following established patterns
• Used correct import paths: github.com/radius-project/radius/pkg/ucp/ucplog
• Created new pkg/ucp/health/ package matching Radius code conventions

Repository Confirmation

During /Spec Kit.implement, Spec Kit detected the multi-repo setup and explicitly asked:

The current workspace contains:
- design-notes repository (where we are now)
- radius repository (actual codebase)

Which approach would you like me to take?

Only after confirmation did it implement code in the radius repository.

Key Findings

What Worked Well:

Spec Kit was able to determine cross-repository context by reading and analyzing sibling workspace folders without requiring additional configuration. (But in the future I would add information about the multi-repo workspace to the constitution.) It was able to identify and follow patterns in the existing codebase.

Branching Behavior:

Spec Kit created the expected feature branch in the design-notes repository, but it did not create a new branch in the radius repository (where the code was implemented), which is good because I strongly prefer to manage branches on my own rather than have Spec Kit do it for me.