specKit workflow spanning multiple related Repos

[mprabhanjan]

Hi experts,

Currently what is the recommendation / best-practices for running a specKit workflow on multiple repos that are tied together?
Ex: I've one repo that has all mgmt+control plane code(r1); a second repo that has code for DataPlane(r2); and 3rd repo (r3) that contains all integration test-suites, spanning both the r1 & r2 repos.

I'm looking for a way to run a single specKit workflow that can look at both r1 & r2 when generating the spec.md, plan.md, etc, and during speckit-implementation can generate code in both r1 & r2, and can generate test-suites in r3.

What's the best way to accomplish the above?
Thanks

[TongyiDai]

Spec Kit does not currently provide one atomic project that writes spec.md, plan.md, tasks, and code across several independent Git repositories. Its project boundary is the directory containing .specify/; Git operations still belong to the containing Git worktree.

For your three-repository layout, I would use an umbrella specification plus one implementation spec per repository:

system-spec/           # coordination repo
  specs/001-feature/
    spec.md             # end-to-end behavior and contracts
    plan.md             # repo ownership and rollout order
    contracts/          # API/events shared by r1, r2, r3

r1/specs/001-feature/  # management/control-plane work
r2/specs/001-feature/  # data-plane work
r3/specs/001-feature/  # cross-repo integration tests

Link all three implementation specs and PRs back to the umbrella spec. Treat the shared API/event schemas as versioned contracts, and define an explicit merge order—for example, backward-compatible contract in r2, consumer changes in r1, then end-to-end coverage in r3. This avoids pretending that three repositories can be committed or rolled back as one transaction.

If you can move the projects into a monorepo, Spec Kit now documents directory-scoped member projects. Each member gets its own .specify/ and specs/, and SPECIFY_INIT_DIR selects which project a command targets:

SPECIFY_INIT_DIR=apps/control-plane specify workflow list
SPECIFY_INIT_DIR=apps/data-plane specify workflow list

Even in that layout, each invocation targets one Spec Kit project. A multi-root IDE/agent workspace can read all three repos, but the cross-repo coordination and commit boundaries still need to be explicit in the plan.

Reference: https://github.com/github/spec-kit/blob/main/docs/guides/monorepo.md

[mnriem]

This is a great answer and matches the recommended approach exactly — nothing to add. The key points: Spec Kit's project boundary is the .specify/ directory, so multi-repo coordination is deliberately explicit (umbrella spec + per-repo specs + versioned contracts + a defined merge order) rather than pretending several repositories commit atomically. For the monorepo path, directory-scoped member projects with SPECIFY_INIT_DIR are the way, per the monorepo guide. Marked as the answer — thanks @TongyiDai.

Posted by GitHub Copilot (model: Claude Opus 4.8) on behalf of @mnriem.