What sort of extra data are you interested to pass into the CPS_match_query() method?

The signature was made like it is to provide a simple interface where the purpose of the arguments are understandable and easy to operate on.

If we want to give access to the Message maybe we can make a lowelevel version that can be used in place of the more highlevel versions.

for the common playback skill something like:

    def __handle_play_query(self, message):
        """Query skill if it can start playback from given phrase."""
        search_phrase = message.data["phrase"]

        # First, notify the requestor that we are attempting to handle
        # (this extends a timeout while this skill looks for a match)
        self.bus.emit(message.response({"phrase": search_phrase,
                                        "skill_id": self.skill_id,
                                        "searching": True}))

        # CALL THE NEW COOL LOW LEVEL METHOD WITH THE MESSAGE
        result = self._CPS_low_level_match_query(message)

        if result:
            match = result[0]
            level = result[1]
            callback = result[2] if len(result) > 2 else None
            confidence = self.__calc_confidence(match, search_phrase, level)
            self.bus.emit(message.response({"phrase": search_phrase,
                                            "skill_id": self.skill_id,
                                            "callback_data": callback,
                                            "service_name": self.spoken_name,
                                            "conf": confidence}))
        else:
            # Signal we are done (can't handle it)
            self.bus.emit(message.response({"phrase": search_phrase,
                                            "skill_id": self.skill_id,
"searching": False}))

    def _CPS_low_level_match_query(self, message):
        return self.CPS_match_query_phrase(message.data['phrase'])

So if the complete message object is of interest the _CPS_low_level_match_query() method can be overridden.

Edit: fixed some issues in the code...

I do see advantages to passing something simple like 'phrase'. My initial thought was actually just to add message so it would be an optional parameter in addition to phrase. I mainly did this the way I did to match what we did in converse (removed utterance based on feedback that it was redundant)..

For the Neon use case that prompted this change for me, we include user data in message objects for our requests to support multiple users. In general, adding params to Message objects helps maintain context throughout the core which I see as a benefit.

Is there a strong preference from anyone here one way or the other? I like Ake's suggestion as it means less work to maintain backwards comatibility now, though I see adding an extra 'message' param (in addition to phrase) as possibly more logical going forward.. Skill authors would be encouraged to add the param for signatures to match, but wouldn't have to do anything differently to interface

i like @forslund suggestion! not sure about the naming of the new function, but the implementation looks solid and i would like to see that in all common_XXX frameworks. for the hivemind i often need the message object for proper routing