A skill cannot be separated from its pipeline as easily as a library can be separated from an application. It depends on the runtime, model, tools, vision capabilities, launch methods, and secret storage.
A QA skill built on Linux Computer Use may be useless to a developer on Windows. Copying a folder is not enough to run it: the environment, tools, and permissions must also be reproduced. Even the same instruction may need different emphasis for different models.
A ZIP archive diverges into separate versions as soon as it is shared. A dedicated repository attached as a submodule adds synchronization work for every project participant, including those who do not need the skill locally and could not run it anyway. A plugin does not solve the mismatch between runtime environments.
Yet a skill directly affects production code while being managed worse than an ordinary library: it has no clear recommended version, owner, compatibility history, or retirement process. What must be shared, therefore, is not the instruction file but the entire executable pipeline of which that skill is a part.