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.

Currently, it’s impossible to get any data about the flash briefings usage at all. It’s crucial to know at least number of unique listeners and number of plays during some period of time.

For the custom skills we are able to count the requests and sessions ourselves, since we host the backend for a skill, but still, there are a lot of tricky points, for example we are not able to distinguish requests from the certification team, so we count them as usual requests from Alexa users.

I think that's a super basic functionality that really breaks the experience for 3rd party tools users.

Please consider, thanks.

Right now if I want to get a publishing status of a skill (live, dev, certification), I need to manually go to the SMAPI and ask for that. If you have 3 or 4 thousands of skills that you want to keep up to date, it’s about 5 thousands of requests to SMAPI every half an hour or even more often.

So, to reduce the number of requests and waiting time for users drastically, it’s crucial to have some kind of an event system to be notified when the skill has changed its status from dev to certification or from certification to live for example.

Please consider, thanks.

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!

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)

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

The Alexa Skills Kit for Node.js includes support for creating a DynomoDB table to hold attribute values across sessions. To create the table dynamically, the Lambda function is typically given DynamoDBFullAccess permissions.

This feature is to remove the table creation code from ASK SDK Node and move it to the ASK CLI as part of the deploy command. This will allow the lambda function to have reduced permissions to insert rows, read, write, and delete.

Configuration for the table name and region would be stored in '.ask/config'

The command would be:
$ deploy --target dynamoDB

This would create the table if it does not exist and update the role associated with the lambda function to include only the permissions it needs.

Calling 'ask deploy' will also deploy to DynamoDB (if the config includes a table name). Deploy to Dynamo would occur after deploy to lambda so that the function permission could be set.