A shared skill does not drive consistency across distributed ownership
Standards, review boards and reference implementations all degraded the same way: each team read them differently. A shared skill removes the re-reading. It does not remove the interpretation.
Part 3 of 3. It starts at Why do we have five user APIs.
The argument
One layer is often several teams. Four API teams now means four agent teams producing API code, and nothing in the decomposition makes their output agree.
Publishing the convention once is a real advance and it is the distribution half. Linters check the shape of what each team produced. I have not seen anything that checks the judgment.
Aligning teams to components handles a request that spans components. It does nothing about several teams inside one of them. Four API teams means four agent teams producing API code, and nothing in the decomposition makes their output agree with each other.
Standards, review boards, reference implementations and templates have all been the answer to this at different times, and they degrade the same way. Each team reads the document slightly differently, and what the teams actually do drifts from what it says.
A shared skill looks like it fixes that, and it half does. Publish the convention once, install it everywhere, and the same instruction is executing in every team rather than a document each team interprets. That is real, and it removes the step where a human re-reads a standard once per team.
What it does not do on its own is make the output consistent. The instruction is executed by a model, once per team, against a different codebase with a different existing shape, so conforming installs can still produce divergent work while every report reads clean, because what is being compared is the file rather than what the file produced. A shared skill is a consistency mechanism. Across teams that each own their share of one layer, it does not drive consistency on its own.
Interpretation did not leave the system when the standard became a shared file. It moved somewhere less observable. A human who reads a standard differently argues about it in review. A model that reads it differently ships work that conforms in appearance.
What would close it is a check on the output rather than on the file, published alongside the convention and run by whoever installs it. Half of that exists. Zalando publishes its API guidelines with a linter that checks an API definition against them, and architecture fitness functions do the same for structure. They catch the shape: paths, naming, status codes. They do not catch the judgment a skill now carries, such as how errors are handled or what a field means. With ownership spread across teams, that is where the work can diverge, and a check for it is what I have not seen built.