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.

[voipp]

App1 is consumer and main logic holder. I need to specify changes in app2, needed for the feature in app1. So , during specify phase, i need copy plan into app2 repo

[mnriem]

If app1 and app2 are commonly changed together, the simplest setup is one top-level Spec Kit project containing both applications. A cross-app feature can then use one spec and plan.

If they are genuinely independent projects, define and version the shared API/event contract. Create a local feature spec and plan in each app, both referencing that contract and each other’s issue or PR. app1 can declare the app2 change as a dependency, but app2 should own its implementation plan. In other words, don’t copy the plan—doing so risks the two copies drifting apart.

[voipp]

app1 can declare the app2 change

how app1 should declare app2 change?

[mnriem]

It depends on where the Spec Kit project boundary is.

If one parent-level Spec Kit project contains both app1 and app2:

Use one feature spec and one plan, run from the parent directory. Describe the behavior across both apps in the same spec, define their shared API/event contract once, and split tasks.md by application—for example, app2 contract/provider tasks first, followed by app1 consumer tasks. There is no external dependency to declare because both changes belong to the same unit of work.

If app1 and app2 are independent Spec Kit projects:

In app1’s spec.md, add an external dependency stating:

• what behavior or contract app2 must provide;
• the relevant app2 issue or PR;
• the shared contract and version;
• what must be completed before the dependent app1 work can proceed.

Then create a separate spec and plan from the app2 directory. That spec should reference the app1 feature and own the requirements, design, and tasks for app2.

Spec Kit does not currently define special cross-repository dependency syntax. The dependency is expressed through linked specs/issues and a shared contract. Avoid copying the complete app1 plan into app2, because the copies can drift and ownership becomes unclear.

Posted on behalf of @mnriem by GitHub Copilot (model: GPT-5.6 Sol).

[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.

[mnriem]

Moderator context: The original comment reproduced in the quoted reply above was hidden after its author posted a burst of automated, AI-generated responses across multiple discussions that was moderated as spam. That moderation action applies only to the hidden comment and its author; @lilisalinas936-design was not flagged for replying to or quoting it.

Posted on behalf of @mnriem by GitHub Copilot (model: GPT-5.6 Sol).