When I submit a skill for certification, there is no way to know when it is going to go live. It may go Live off-hours or when I am not available.

This causes several issues.

1) I can't promote my skill ( Can't tell my users my skill will be available on xx/xx)

2) I can't be available to monitor after initial deployment. (monitor logs, have support ready etc..)

3)I don't know when to turn on any backend API's, Systems etc. (If I have version 1.0 of let's say a lambda function on arn xxxx. I have no way of knowing when to deploy version 1.5 that contains new features etc.)

In summary, process should be as follows:
1) Receive notification that my skill has passed certification (yayyyy) press this button to make it Live.
2) I prepare all my backend systems, send out any communications.
3) Everything is ready time to press the big red button. We are now live.

The current flash briefing content (per provider) is a 'one size fits all approach'. Everyone gets the same NPR briefing, for example.

There are many use-cases where user-specific information could be very powerful in the flash briefing, often in concert with interactive skills. Some examples:

* A sport team skill that (in the flash briefing) reminds you of your game time this weekend (or of changes), without you ever having to touch a calendar

* A retailer skill that (in a flash briefing) advises of significant deals, relevant to your buying history or explicit 'watch list'.

I think this would take flash briefing content 'to the next level'.
Please consider!

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

Problem:

When an audio streaming skill is actively streaming/playing, users of the skill have to re-open the skill in order to issue additional commands. This creates a very awkward user experience, for example:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, ask AnyPod to play the oldest episode"

<oldest episode starts playing>

"Alexa, ask AnyPod to fast forward 3 minutes"

<episode fast forwards>

"Alexa, ask AnyPod to <etc>"

--

Solution 1:

Ideally this interaction would go like this:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"AnyPod, play the oldest episode"

Having "AnyPod" (the skill's invocation name) substitute in as an alternate wake word would be great. But of course you'll never do that in a million years, until in a few years from now when you actually do. So how about this as a compromise in the meantime:

-------------

Solution 2:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, play the oldest episode"

This will require some clever engineering to determine whether the user is said something that maps to a valid intent within the active audio streaming skill's invocation model - and if not, handle the request the same way they are currently handled. That seems reasonably doable.

It does create potential problems where an audio streaming skill may have an intent that conflicts with the invocation name of another skill -ie, the user may wish to open another skill but find that the audio streaming skill "hijacked" their request because the invocation name for the other skill triggered an intent in the audio streaming skill. But, that problem is solvable a few different ways - put greater restrictions on the intents that can be accessed in this scenario, for example:
a "catch all" intent with nothing but a custom slot could not be allowed

any intent with words matching the invocation name of existing skills would not be allowed (they would be allowed during normal skill usage, but not in this more restricted context)