Mycroft Community Forum

Mycroft Skill Lifecycle

NOTE: I edited and added a couple links, but haven’t changed the content)

Here is my view of the “Mycroft Skill Lifecycle” and how it works/will work in the Mycroft ecosystem.

##Ideation (stick with me through that term :slight_smile: )

  1. A user or developer would post on the general “Skills Development” forum a request or idea. “I’d like to control my coffeemaker!”, “I’d like to control my breadmaker!”
  2. Discussion would be held there until it starts to solidify.
    “Maybe we could support this widget from Xyz that switches outlets on and off”
  3. As idea for a Skill gels, all interested in the skill would move discussion to a forum topic (e.g. a new topic in the Skill section here). This will likely happen when a developer is ready to take on writing the skill.
    “I’m going to take this on, everyone. Let’s take this discussion to the ‘Skills > Xyz Control’ forum topic.”

Optionally you can chat in Slack and such, but doing it in the forum archives the discussion nicely for future reference.

Skill Development (open version)

  1. Under the forum topic, potential users would discuss what they want and need the skill to do, vocabulary to use, etc. Developers would coordinate and hash out details. This will continue throughout the process.
  2. Someone will host the skill development on GitHub as the main repo under their user account. The posted Skill Template can be used as a starting place.
  3. Under the mycroft-skills GitHub repo a link to that new Skill’s repo would be created. (This is a submodule reference to the Skill repo’s master branch, actual dev work would be done within the Skill’s main repo using whatever branching and labeling structure the project participants like.)
  4. Under the subfolder, a would be created based on the template provided in the template Skill provided by Mycroft. It would include plans, development status, etc.
  5. During development any user or collaborator can potentially pull down the code and install on a device by hand by simply pulling the it into the user Skill folder on a Mycroft device.

NOTE: After some amount of time we might move non-working Skills into and “abandoned” folder to keep things clean.

Skill development (proprietary version)

  1. The organization would pull down the skill template
  2. Code would be developed and tested internally using their resources

NOTE: Skills can be tied to a custom platform via metadata, thus only appearing in the Store when a user has that platform. E.g. a skill to check how many eggs are in a Samsung refrigerator.

Skill Validation/Publishing

  1. Once a Skill is deemed “ready for the world” by its development team, they will fill out manifest from the template included in the Skill to describe the skill in the store.
  2. A manifest would included things like long and short description of the skill, sample phrases it handles, logo graphics for the store, required required device capabilities or platforms, etc.
  3. The Skill must include basic unit-tests for automated testing (phrase parsing, etc)
  4. The Skill repo URL (open development) or zipped package (proprietary development) is sent to Mycroft for validation along with a point of contact
  5. Mycroft reviews the Skill (automated scans, pip-package review, code review looking for malicious behavior, verification that all info needed has been filled out). Feedback is provided to point of contact. If changes are needed, resubmission would occur until things look good.
  6. Once validated, a Skill package is created and placed in the Skill Store

Skill Store

  1. A user logs in to their account (currently via, entering their Profile. Each Profile is associated with registered Mycroft Devices.
  2. When the user enters the Skill Store, they are presented only with Skills that are supported by at least one of their devices. Skill developers describe the supported devices via several mechanisms:
  • Specific devices: “Ford ABC 123”
  • Device capability descriptors: “requires screen”, “requires screen-rgb”, “requires bluetooth”, etc.
  1. User can select a Skill to get information about it. This would show the logo, description, example phrases, etc. that were provided when the Skill was submitted to the Store.
  2. User clicks “Install” and it would be added to the “Available Skills” for that Profile.
  3. By default, Skills would be pushed to all devices associated with the Profile that support it. User can also uncheck the Skill for specific devices, e.g. removing “Bank-of-Kansas-City” skill from a shared device in the office.
  4. If the Skill indicates that it has configuration variables, a Setup icon would appear in the Available Skills list. Clicking that icon opens up a webpage allowing the user to set options. Additionally, options can be controlled/overrided at group (“Home”/”Work”) or specific device level.
  5. Skill settings can be changed at any time from this interface, and it can be uninstalled from a specific device or from the “Available Skills” list to remove from all devices.

OPTIONALLY: Device manufacturers can have specific skills pre-associated with their specific devices. They’d appear be in the interface just the same as installed Skills.

Skill Delivery

  1. When a Mycroft device next connects to the backend, a Skill change would be flagged.
  2. New/updated skills would be pulled down as a package and installed into the user Skill folder
  3. A ref-counted registry of PIP packages would be maintained locally. Any missing package would be installed, and any unneeded packages would be uninstalled.
  4. Settings will be synched up/down

User Feedback mechanism

  1. Any installed Skill can be rated (1-5 stars) by a user from the Profile’s Available Skills list.
  2. Comments can also be added, posted to the Skill in the Store. This will also be emailed to the Skill’s Point of Contact.
  3. Optional link from Skill in store would lead back to the Skill forum topic to provide bug reports, suggestions for improvements and feature requests for future versions (going back to Ideation).

Feedback is welcome!


By the way, something like this is what I’m thinking for the manifest:

Skill Template 	

One-line description for the Skill store

Long form description for the Skill store,
This one can be multiple lines and include markdown such as:

icon-name.jpg # must be in Skill folder

Contributor name(s) or Company name

free, $xx or monthly $xx

# ftputil
# py-ApeTag

# mycroft-mark-1
# android
# android-wear
# ubuntu
# fedora
# windows
# ...

# Remove the # for all required capabilities
# text-to-speech
# display
# display-rgb
# display-hires
# audio
# audio-hifi
# bluetooth
# other...

We can also support localized sections using postfixes, default is “en-US”

One-line description for the Skill store, guv

Eine Zeile Beschreibung fur Skill Speicher

Once a skill has been validated and published, it looks like the submodule reference points to a particular commit ( Skills repo consideration seems to confirm this). Let’s say that after initial publishing, some improvements have been made and committed to master branch on the skill’s home repository. What is the procedure for requesting that the submodule reference “advanced” or recreated at current head-level commit? I’m supposing it starts with a Pull Request, but what goes in it? A fresh manifest? A change-notes summary? Any other github artifact references that should go with it?

I took a read through and I do not see these answers there either.

It’s actually a bit misleading right now. The specific reference that the git submodule points to doesn’t matter. As it is right now, devices will run git pull on their own per skill getting the latest changes as soon as they are published to the repo’s master branch.


Thanks for the clarification, @Wolfgange . I will be sure to carefully follow the “don’t develop on master” principal once I get a skill accepted for publishing. It might nonetheless be a good idea to update the skills repo with a note exhorting skill authors to be extra careful to follow that pattern.

1 Like