An ESA prime ships its AI context by copy-paste

Starion publishes a repository called claude-kit, described as "a team-shareable collection of Claude Code skills, hooks, and MCP adapters." It is Apache-2.0, last updated 7 August 2026, and it is one of the more interesting artefacts I have read this year — not because of what it contains, but because of what its install instructions admit. The documented way to share it with a colleague is to copy a folder. Context drift is what happens when shared AI instructions travel by copy: every copy is correct on the day it is made and silently wrong from the next edit onward, because nothing connects it back to the original.

Your team already writes context for its AI. It ships by copy-paste.

What Starion actually published

Some housekeeping on the company first, because the corporate history here is genuinely confusing and getting it wrong is easy. Starion was formed in the 2024 demerger of RHEA Group; Starion and Nexova were both subsequently acquired by Sopra Steria, completing 30 April 2026. RHEA does not exist as an operating entity. If you are searching for prior art in this space, that naming change is why half the search results are stale.

What matters is what the engineering organisation shipped. claude-kit is a small, unglamorous, genuinely useful thing: three utility skills, some hooks, some MCP adapters, packaged with the explicit intent that a team share them. Apache-2.0, so anyone can take it.

Let me be plain about the scale, because overstating it would be the easiest way to lose the engineers who wrote it. One organisation. Zero stars. Zero forks. Three skills. This is not a movement. It is one team's internal tooling, published in the open because publishing it costs nothing and might help someone.

That is exactly why it is good evidence. Nobody built this to make a point. An engineering organisation with real deadlines independently concluded that its conventions had to be written down for the AI, per repository, and shared across the team — and then implemented that conclusion as files in git, which is what a competent team does with a problem nobody sells a solution for.

The install path is the finding

Read the setup instructions and the interesting part arrives immediately. To use a skill, you copy its folder — into ~/.claude/skills/, or into whichever repository needs it. Hooks and MCP servers, the documentation notes, "aren't auto-discovered": they have to be hand-registered in .claude/settings.json and .mcp.json. Per developer.

Nothing about that is a mistake. It is the correct reading of how the tooling works, and it matches the documented pattern for Claude Code skills. Anyone sharing skills across a team today is doing some version of it, including us before we had somewhere better to put things.

But notice what the mechanism guarantees, independent of anyone's diligence:

Every developer holds a copy with no link to its source. A copied folder has no idea where it came from. There is no version, no upstream reference, no way to ask "is mine current".

Registration is manual and per machine. Two engineers who both "have the kit" can have materially different agent behaviour, because one registered the hook and one skipped that line.

There is no update path. Not a bad update path. None. The only way a change reaches a colleague is another copy, initiated by a human who remembers to do it.

That is the distribution mechanism the entire practice currently rests on. Not just at Starion — everywhere. It is the default because it is the only thing the tooling makes easy.

The CLAUDE.md files corroborate it

If claude-kit were the only signal it would be thin. It is not. Their engineering repositories — Kalliope, COMET-SDK-Community-Edition — carry substantive, hand-written CLAUDE.md files. Not stub files. Architecture. Data flow. The boundary between generated and hand-written code. Code style. Explicit prohibitions on things the model should never do.

Those files are the part I would point an executive at, because they cost real engineering time and nobody writes them for fun. Somebody sat down and articulated what the system is and how it must be worked on, in prose, for a reader that is not human. That is context engineering whether or not anyone in the building calls it that.

And here is where the drift argument stops being theoretical. Some of what is in those files is genuinely repository-specific: this module's data flow, this SDK's generated surface. But some of it — house style, review conventions, the architectural prohibitions — is true across the whole organisation. That material now exists in two files. Change the convention and you change it twice, or you change it once and the second file is quietly wrong. We wrote the general version of this in The CLAUDE.md problem; this is what it looks like in a real engineering org that is doing everything else right.

Why this works fine at three repositories

Here is the concession that has to be in this post, because without it the rest is vendor noise.

At three repositories with one co-located team, copying is the correct decision. It has no dependencies, no service to run, no failure mode anyone needs to learn. cp -r is understood by every engineer who will ever touch it. Choosing it over a tool is not a lapse in judgement; it is judgement.

The pain here is latent, not acute. Nobody at Starion is currently blocked. If they were, they would have built something else, because they are clearly capable of it.

Which also means the incumbent competitor in this market is not another vendor. It is free DIY, and it works. Any pitch that starts from "space teams have no solution for this" is wrong on the facts and will be recognised as wrong by exactly the people it is aimed at. They have a solution. It is a filesystem and some discipline.

The honest question is not whether copying works. It is when it stops working, and what it costs to find out.

Where copy-paste breaks: version 2

The failure is never the first copy. It is the second edit.

Picture the sequence, which is not hypothetical for anyone who has run a team of thirty. A convention changes — the team decides generated code is never edited by hand, and the rule needs to be explicit because an agent got it wrong last week. Someone updates the CLAUDE.md in the repository where the incident happened.

Now: which other repositories have the old wording? Which developers' ~/.claude/skills/ hold the pre-change skill? Nobody can answer, because a copy does not record what it was copied from. There is no diff to review, because the artefacts are not connected. There is no test that fails when a convention file goes stale — this is the property that makes drift expensive, because every other kind of rot in your stack is loud and this one is silent.

Three weeks later an agent in a different repository confidently edits generated code, because as far as its context is concerned that is still allowed. The rule was updated. The copy was not. Nobody was careless; the mechanism simply has no propagation step.

There is a compounding version of this that arrives somewhere past twenty engineers. New joiners copy from whoever onboarded them rather than from the source, so copies descend from copies. Within a couple of quarters an organisation is running several generations of the same conventions at once, and the differences are invisible because nobody ever holds two versions side by side. Ask a team of that size to answer "what are our conventions" from the artefacts rather than from memory, and you generally get several answers — and reconciling them takes longer than writing them did in the first place.

Multiply by the number of tools your engineers actually use. This is why the Cursor rules version of this problem has the same shape — different file, different tool, identical distribution failure. There is a related discussion on Hacker News about pinning the rules revision in every run so at least you can tell after the fact which version an agent was working from. That is a genuinely good mitigation and worth reading. It is also an admission: you are recording which copy was used because you cannot guarantee they are the same.

What the copy step should be instead

The fix is not a better copy. It is not copying.

Reference instead of duplicate. One versioned copy of the cross-repository standards, retrieved by the agent at the moment it needs them. The per-repository file keeps only what is genuinely local — this module's data flow, this SDK's generated boundary — which is a much shorter file and a much easier one to keep true.

Give every change an author and a diff. Then updating a convention looks like the artefacts your team already reviews, and the reviewing instinct fires.

Make propagation the default rather than an action. If a standard is retrieved rather than held, the next session gets the current version because there is no second copy to go stale.

We run our own engineering this way, and the change we could actually measure was not output quality — it was the review path. When we changed our API error-handling rule, it was one edit, one diff, one author, and the next session every agent on the team had it. Under the old arrangement it was four pull requests against four files, of which two merged and two drifted for a month before anyone noticed.

Worth stating the limit of that claim precisely: none of this makes agents more accurate. There is no evidence that shared context improves how well a model does its job, and we are not going to claim it. What governed shared context buys is that it is cheaper to distribute than N copies, consistent across every tool on the team, and auditable. Drift is the thing it removes, and drift was the actual problem.

This is not a space problem

The reason to read claude-kit is not that it is aerospace. Nothing about the drift mechanism is domain-specific, and nothing about the answer needs to know what a spacecraft is. This is generic ContextOps that happened to surface in a space organisation, which is the useful kind of evidence: the pattern showed up somewhere with unusually high documentation discipline, which is where you would expect to see it first.

Two adjacent arguments are worth reading alongside it. Aerospace tribal knowledge covers the cultural half — why knowledge held by individuals fails an organisation as AI tools start every session blank. MBSE shared models versus AI copilot context covers the tooling half — why a model of the system is not a model of the team's reasoning. This post is the third leg: how the context physically travels, and what the travelling costs.

If your team has written a CLAUDE.md worth reading, you have already done the hard part. Somebody articulated how your system works for a non-human reader, and that is the expensive, unglamorous work nobody wants to do. The cheap part — making sure everyone is reading the same version of it — is the part currently done by hand. That is a solvable problem for a team, and it is worth solving before the second edit rather than after.