How to handle multiple project fix?

[voipp]

I have got application app1 created with git hub speck kit. This app integrates with app2.
How can i sync specs between this two apps?

I assess bug, staying in directory for app1, in app1, the resulting fix touches initial app1 and app2.

How should i properly implement fix in app2 to make app2 spec consistent?

[hamedrabah]

There is not a core command that synchronizes two independent specs/ trees. I would keep app1 and app2 as separate Spec Kit projects, and synchronize the interface contract, not the whole feature spec.

For a fix that crosses both apps:

1. Define the affected API, event, or data contract once. Keep that artifact in the producer repo (or a dedicated contracts repo) and version it.
2. Create a small feature/fix spec in each app. Each spec should link to the same contract version and to the other repo's issue/PR.
3. Run /speckit.plan and /speckit.tasks independently in each repo. The plan workflow already treats contracts/ as the place for interfaces exposed to other systems.
4. Implement in a compatibility-safe order: normally the additive/backward-compatible app2 change first, then the app1 consumer change, and remove the old contract only in a later change.
5. Add a contract or end-to-end test at the boundary so drift fails in CI instead of being discovered manually.

Spec Kit is directory-scoped, so this separation is intentional: each project owns its own .specify/, specs/, constitution, and feature state. The monorepo guide documents that model, and the plan template describes generating interface contracts.

If the main pain is coordinating branches across sibling repos or submodules, the community catalog now includes Multi-Repo Branch Sync and a Multi-Repo Branching preset. Those can coordinate repository mechanics, but I would still avoid duplicating one spec into both apps; a shared, versioned contract plus two local implementation specs gives you clearer ownership and review history.

[173787247]

Spec Kit’s unit of work is one repo / one .specify tree. There is no built-in “sync specs across app1 and app2”. Treat the two apps as two spec projects, and make the contract explicit.

Pattern that stays consistent

1. Put the shared interface (API, events, data shapes) in a third place both repos can see:
   • a small contracts/ git submodule, or
   • a short ADR/OpenAPI file both specs link to (don’t duplicate the field list in two spec.md files).
2. In app1, the feature spec should say: “changes required in app2: …” and stop at the boundary (request/response). Don’t implement app2 inside app1’s spec directory.
3. In app2, start a new feature branch + new spec whose spec.md references app1’s feature id / PR, then /speckit.plan from app2’s directory. That is what keeps app2’s .specify and specs/ consistent.
4. If you already mixed the fix in one agent session while cwd was app1: copy the app2-relevant acceptance criteria into app2’s spec before coding app2, then implement. Don’t rely on app1’s feature.json.

Cross-repo “one specify session, two codebases” will always desync specs/. Two specify runs + a shared contract file is the clean version.

[lilisalinas936-design]

Spec Kit’s unit of work is one repo / one .specify tree. There is no built-in “sync specs across app1 and app2”. Treat the two apps as two spec projects, and make the contract explicit.

Pattern that stays consistent

1. Put the shared interface (API, events, data shapes) in a third place both repos can see:
   • a small contracts/ git submodule, or
   • a short ADR/OpenAPI file both specs link to (don’t duplicate the field list in two spec.md files).
2. In app1, the feature spec should say: “changes required in app2: …” and stop at the boundary (request/response). Don’t implement app2 inside app1’s spec directory.
3. In app2, start a new feature branch + new spec whose spec.md references app1’s feature id / PR, then /speckit.plan from app2’s directory. That is what keeps app2’s .specify and specs/ consistent.
4. If you already mixed the fix in one agent session while cwd was app1: copy the app2-relevant acceptance criteria into app2’s spec before coding app2, then implement. Don’t rely on app1’s feature.json.

Cross-repo “one specify session, two codebases” will always desync specs/. Two specify runs + a shared contract file is the clean version.