◇ Could this help me?
Yes for the specialist structure, with a condition on the orchestrator. Narrow skills that each do one job are better for a mechanical reason rather than an aesthetic one: only the matched skill's content gets loaded, so a library of focused skills wastes less context than a few sprawling ones, and each is easier to test and fix in isolation. The team analogy is apt. General practice, with the honest qualification that the orchestrator is the optional half: routing by skill description is already how selection works, so a dedicated routing layer earns its place once there are enough specialists that descriptions start colliding, and adding it to a library of three is indirection without benefit. Build the specialists now and add the router when the symptom appears.
Review my skills for scope rather than content. Find any skill that handles several unrelated situations and tell me how to split it into narrow specialists that each do one job, with a clear output shape for each. For every specialist, write the short description carefully, since that is what decides whether it gets selected, and tell me which of my descriptions currently overlap enough that you would pick the wrong one. Then be honest with me about whether I have enough specialists to justify a separate orchestrator skill that only routes, or whether better descriptions would solve the same problem without the extra layer.