Part of the power is that I can change a skill, or maintain it. But if it is running somewhere else, am I still allowed to influence how it works?
This is one of the strange things about skills. They do not feel fully fixed in the way normal software is supposed to feel fixed. With ordinary software, we like to think that the implementation defines the behavior. A skill is different.
The quality of the skill is in the running of it. We can read the instructions, improve them, and make changes, but only running it shows what it really does.
A skill is partly instructions and partly interpretation
Even when the instructions are clear, the agent will often do the meaning of the skill instead of the exact literal instruction. That can be useful. It can also be surprising.
If I say clone a repository, I might expect a fresh clone. But if the agent
sees a directory with the same name, it may decide to use that directory
instead. Sometimes it will even use the current directory if it sees a
.git directory there, even when it does not match the project I
meant.
This gets especially messy in a repositories directory where there are many projects next to each other. The instruction may sound simple, but the real behavior depends on what the environment looks like and what the agent thinks the goal is.
You only see the real skill in execution
A skill is not fully visible in its prompt or markdown file. You see the real thing when it runs in a real environment with real files, real state, and real assumptions. That is also where it connects to the question of when a skill becomes software.
A skill on paper can look clean. A skill in execution can reveal shortcuts, ambiguities, hidden dependencies, and strange interpretations. The running is part of the definition.
Maintenance changes too
This also changes what maintenance means. Maintaining a skill is not only rewriting the text. It is watching what happens, noticing where the meaning drifts, and tightening the conditions so the agent does the intended thing more often.
In that sense, maintaining a skill is closer to gardening than to shipping a finished binary. You trim, observe, redirect, and run it again.
What happens when it runs somewhere else?
This brings me back to the first question. Part of the power of these skills is that I can influence them directly. I can edit the file, rerun the skill, and see what changes. But if the skill is moved to some shared machine or a company runtime, does that still stay true?
If the useful part of the skill is in the running of it, then distance matters. If I lose the ability to inspect, change, and rerun it easily, I lose part of the thing that made it powerful in the first place.
Maybe that is the real boundary
The boundary may be less about prompt versus software, and more about whether I can still shape the skill directly or only consume it after it hardens.
Agent systems need that question. If software becomes more useful when it is malleable, we should be careful not to turn it back into a distant system too quickly.