Almost every team with more than one product has a repository like this. A billing engine that the web shop, the subscription portal and the partner API all call. A component library three front ends import. It belongs to everyone and therefore to no one, and the way it usually fails is quiet: someone changes a function signature for their product, their tests pass, the change is merged, and a different product breaks a week later.
Until now CodeLynq made that worse rather than better. A repository belonged to exactly one project, so a shared one was either connected twice, with nothing linking the two copies, or it lived in one project and the others did not know it existed. We fixed that properly.
One repository in several projects
A repository can now be added to more than one project in the same organisation. In a project's repository settings, "Add existing repository" offers the ones other projects already have. The repository keeps one home project, where its credentials and settings are managed; the others link to it. If you remove it from its home project, it moves to the next project that uses it rather than disappearing from all of them.
A linked repository is a full member of each project. Runs can change it, specs are drafted against it, checks read it and it appears on the architecture map. The organisation also gets one Repositories page listing every repository and which projects use it.
A description that travels with the repository
Each repository has a description you write: what it is, what depends on it, what must not change casually. "Billing engine. Prices are in cents everywhere. The webhook payload is a public contract with two partners." It goes into every prompt that works on that repository, from spec drafting to the run itself, in whichever project the work starts.
For a shared repository the run prompt adds one more thing: the names of the other projects that use it, and an instruction to keep its public interfaces (APIs, function signatures, schemas, events) backward compatible, or to say plainly in the summary what the other projects would have to change. That alone removes a class of accidents. It does not remove all of them, which is why there is a second step.
An impact check when the pull request opens
When a run in one project opens a pull request on a shared repository, CodeLynq starts an impact check in every other project that uses it. For each of those projects it:
- clones that project's repositories, with the shared repository checked out at the pull request's branch, so the project's own code sits next to the changed version;
- runs that project's test command against the combination;
- gives a read-only agent the diff and asks it to find every place this project uses what the diff touches, imports, API calls, signatures, schemas, events, configuration, and check each one against the new code;
- files what breaks as a task in the affected project, with a link to the pull request that caused it.
The timing is the point. After merge, a breakage is an incident in somebody else's product. While the pull request is open, it is a review comment: the change can be adjusted, made backward compatible, or merged together with a fix on the other side. Impact findings are filed as tasks even at medium severity, because nobody in the affected project knows the change is coming.
A check that finds nothing is a good result. If the change does not touch anything the other project uses, the agent is told to say so and return no findings, and that is what you see.
What it does not do
- Only new pull requests trigger it. When a run iterates on a pull request that is already open, after review comments or a failed CI build, the impact check does not run again. Neither does it run for changes people push themselves; it is part of the CodeLynq run.
- It does not block the pull request. The results land in the affected projects as tasks. Whoever reviews the pull request decides whether to wait for them.
- It costs model credit. Each check reads another project and runs its tests, so a repository shared by five projects means four checks per pull request. That is why it can be turned off per repository, for a shared repository whose changes you already coordinate another way.
- It is only as good as the other project's tests.Without a test command, the check relies on the agent reading the code, which catches broken contracts but not every changed behaviour.
Where to start
If you have a shared repository, start with the description. Write three or four sentences about what other products rely on, before you link it anywhere. It costs nothing, it improves every spec and run that touches the repository, and writing it tends to surface the one interface everybody assumed someone else was keeping stable. More on how product teams use CodeLynq is on CodeLynq for product teams.