Make Each Skill Coherent, Not Necessarily Tiny
I do not split skills by arbitrary prompt length. I split them around a coherent business responsibility that can be described, tested, permissioned, and improved independently.
- Single responsibility without microscopic skills
- Recognising an overloaded skill
- Business boundaries versus technical boundaries
- When to split a capability
- When composition is worse than one coherent skill
The situation
Once teams accept the idea of reusable skills, the next failure mode is over-fragmentation. A simple business task becomes ten microscopic skills because every individual reasoning step is extracted. The agent then spends more effort selecting and coordinating skills than solving the user problem.
The naive solution
Make every instruction its own skill so everything is maximally reusable.
The hidden constraint
Reusability has coordination cost. Every boundary creates routing, context transfer, error handling, latency, logging, and versioning concerns. A skill that only makes sense when immediately called before and after two other skills may not be a meaningful business capability at all.
The decision
Define skills around coherent responsibilities. I want a skill to be narrow enough that its purpose is obvious, but broad enough that it produces a useful intermediate or final outcome. I split when permissions differ, evaluation criteria differ, context differs materially, ownership differs, or the capability is independently reusable.
The implementation
I would inspect a candidate skill and ask whether one description captures it honestly. If the description contains several unrelated verbs, several permission levels, or several different definitions of success, it probably needs to be split. Conversely, if splitting would only create internal implementation steps that nobody else would ever call independently, I would keep them inside one skill.
The tradeoff
There is no perfect granularity. Larger skills are easier to invoke but harder to evaluate internally. Smaller skills are easier to test in isolation but increase orchestration overhead. I treat granularity as an operating decision rather than a purity rule.
The evidence I would look for
Good skill boundaries show up in maintainability. A capability has a clear owner, its tests make sense as a group, its logs tell a coherent story, and another workflow can reuse it without depending on hidden assumptions from the original caller.
The reusable lesson
A skill boundary should represent a meaningful unit of responsibility. Do not confuse decomposition with architecture.
The consultant's questions
- Does this skill have one coherent definition of success?
- Would another workflow ever call this capability independently?
- Are different permission levels hidden inside the same skill?
- Is orchestration complexity increasing faster than reuse is improving?