To be honest this is completely the wrong way round if you look at the skill spam of Mycroft unless you are looking at this a different way. Due to qty there is no need to test as the complexity without a docker manager would be quite huge as well as overhead never mind just disk space.
Suppose you could all layer from a base but wow such a divergence from what Rhasspy is.
There is a reason its called R-Hass-Py because it choose a really good distributed model and if by skills you mean other application intent json processors so that the likes of Hassio, Mopidity, Kodi, Snapcast, Almond, Magicmirror as these are all examples of polished skills that become so proficient they are termed applications.
Really skills shouldn’t be Rhasspy specific as in this great and varied world of opensource there is a huge collection of software that need a interoperable intent api that the HMI of voice.ai of many can control and share.
Many of those applications already have MQTT & security methods that are backed by OS security and can reside in containers of many forms or other server instances.
As in skills do you mean the intent recognition and processing that all is needed for rhasspy to be a voice.ai HMI?
As yes it might be good to have a repo collection of intent recognition and process templates for common applications but that doesn’t need docker.
If you where thinking about docker installs of those applications that is really the remit of those applications.
Whatever you do don’t make Rhasspy a garbage can of spammed and poorly implemeneted skills that Mycroft frequently is.
To make it worse there is no need for rhasspy skill processing as voice.ai is a HMI!