As you build more Skills, their number naturally grows. If you keep them all in the same drawer, it gets harder to tell which one to fix and how. In my case, I split Skills into two kinds by their nature.
The first is the "work Skill" — a template for simple, repetitive tasks like checking writing, cleaning up data, or verifying naming conventions. Since I want to reuse these across different projects, I usually make them global (shared across all projects).
The second is the "orchestration Skill" — the one that arranges a whole flow within a single project, from planning to drafting, checking, and release prep. It plays a kind of conductor role. Because it carries project-specific details, I keep it as a local Skill inside that project. When a step calls for it, the orchestration Skill reaches for a work Skill.
So what's the payoff of splitting them?
One is that you can run separate improvement loops. Used across many projects, a work Skill reaches polish faster; an orchestration Skill, with steps you can flexibly change, makes it easier to focus on the quality of the whole job. The directions you want to improve are simply different. Mixed into one, fixing one side tends to break the other use. Split by role, each improvement stays out of the other's way.
The other is saving context. A Skill's body loads when that Skill is invoked. So if you cram every conditional branch into one giant Skill, you tend to carry the whole text no matter which branch you take. Cut along roles, and you only load what that moment needs — the context the AI is holding stays light. The lighter it is, the more the AI can focus on the task in front of it.
The more tools you have, the more "knowing where things are" matters. Just keeping these two drawers — work Skills and orchestration Skills — separate keeps things from sprawling as they grow, and makes them easier to improve.