I would like my skill to be able to listen for specific responses, i.e. make Alexa bias towards utterances of one or multiple intents that I specify in the skill's response, for the next user input.

For example, let's say my skill has a CityIntent which has utterances:

• I live in {city}
• It is {city}
• {city}

And my skill has another MovieIntent which has utterances:

• I like {movieType}
• I prefer {movieType}
• {movieType}

And at certain times my skill may also expect {yes/no} answer from user.

Since {city} and {movieType} have different value, Alexa usually does a good job of figuring out which intent should be mapped.

However, sometime the single word utterances are incorrectly mapped to wrong intents, and there's very little or hacky way for my skill can cope with such cases.

Therefore I want my skill to have the ability to specify what the NEXT intention user is likely to make, at any point during conversation. Then Alexa can bias the listening towards the likely utterances and map to the correct intents.

I have looked into DialogModel, however it doesn't seem to be applicable because it doesn't allow switching intent, i.e. my code cannot be handling MovieIntent and then request Alexa to ElicitSlot for CityIntent.

Thanks!

Currently, there is no way to accurately do automated testing of how user audio resolves (in terms of intents and slots) for a given skill.

At present, this testing is more-or-less done manually. There are several use cases where automation would be vitally important. Given:

-When testing a large skill, it is extremely cumbersome to manually test a wide array of sample utterances for every change we make to the voice model. This discourages iterative design.
-The overall Alexa voice model is constantly shifting. This is a good thing, but often this results in changes to how our skills launch utterances, one-shots, etc are resolved, and right now we have no way to do this testing on a regular, automated cadence.
-Testing a skill across a variety of voice types (varying gender, age, accent) is not something that we see done today, because the effort to manage something like that is considerable.

And, on a point unrelated to test automation, it would also be beneficial if we could have our users who are struggling with misfiring intents send us an audio clip of their voice and let us send that to this endpoint to see what's happening. Trying to reproduce a user's accent/pitch/prosody as a developer is (often comical, but) not particularly helpful.

All of these cases could be resolved by:
1. An endpoint within the SMAPI or some other similar REST service; which,
2. Accepts as a POST request an audio file in a specified format;
3. Along with whatever request metadata might be relevant; as well as
4. A parameter in the path or body that specifies the id of the skill under test; and
4. Returns a JSON object with the exact Alexa request that would've been made to the specified skill

Ideally this API could also have a mechanism for dealing with things like sessions and dialog management (and how the intent resolution may change in that state), but the 90% case could be easily covered by a simple "isNewSession" flag that lets us emulate both one-shots and open session requests.

It's worth noting that we've actually tried (with some success) to solve this problem on our own - to middling success - via AVS. The functionality just does not exist for this to be addressed by third parties, unfortunately. A description of our feeble attempt can be found here: http://www.3po-labs.com/blog/a-proof-of-concept-and-its-roadmap

Currently if a user streams audio via the skill there is no friendly way to get back to the skill without the user saying an invocation command.

I'd propose a way to allow a skill to open a new session, allowing speechOutput after the PlaybackNearlyFinished or PlaybackFinished events occur in the AudioPlayer interface.

There are a couple use-cases for this:

1) A podcast skill where it would be beneficially to ask the user if they'd like to listen to the next episode.
2) Give some information about the next episode before it begins to play
3) Provide a purchase opportunity after an episode completes but before the next begins.
4) Allow the user to interact with some other aspect of the skill other than audio (e.g. Tell me about this podcast, or I want to donate to this organization).