We would like to use this, but can't because the rules are too restrictive.If a user is asked about what they want info about, they should not be forced to say "tell me about Point Defiance Zoo". They should be able to say "Point Defiance Zoo" with no leading phrase. Instead of forcing us to use a leading or trailing phrase, please allow the use of just {query} (without 'search for...' or other text around it as in the example below:
{

"name": "SearchIntent",

"samples": [

"search for {Query}",

"find out {Query}",

"search for {Query} near me"

],

"slots": [

{

"name": "Query",

"type": "AMAZON.SearchQuery"

}

]

}

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

Allow the Endpoints to be changed for a Live skill WITHOUT submitting for re-certification.

In the new Developer Console for a Live (already published) skill, you can see the endpoint ARNs in textboxes which would indicate that they are editable, but the Save Endpoints button is disabled.

The following scenarios outline why the endpoints should be editable. The timing and reasons for changing the endpoints shows that they should be done without triggering a re-certification.

Scenario 1
The skill's lambda function is hosted in a region that goes down. With a quick change of the ARNs, your skill will be Live again hosted from a different region. No re-certification needed. No changes were made to the skill and the timeliness of getting your skill active again to support users does not fit the timeline for re-certification.

Scenario 2
You have already certified and published a skill and you discover a bug that is crashing your lambda. No utterances have changed, no responses have changed, but you want to quickly deploy a hotfix to the lambda function only. No re-certification needed. No changes were made to the skill features and the timeliness of getting your skill active again to support users does not fit the timeline for re-certification.

Scenario 3
You are using versioning and aliasing of Lambda functions. You have two aliases: beta & prod. The first time you certified/published your skill, you used the 'prod' alias suffixed to the ARN. Weeks later, it is time to make changes to the interaction model and lambda code. You version and then alias the most recent changes to you lambda with the 'beta' alias. The 'In Development' version of your skill is pointing to the beta ARN. You go ahead and publish the skill and after certification it is the version that has the 'Live' status. But the ARN is pointing to the beta alias. At this point the lambda code is correct, but the alias is wrong. In the Lambda console, you assign the 'prod' alias to the latest version and in the Developer Console, change the ARN to the 'prod' aliased version. Now the beta alias is ready to be used for the next set of changes. The current two-phase (In Development => Live) deployment of skills does not function well with the versioning and aliasing of lambda functions unless you are able to change the ARNs for a Live skill. The fact that the reason for changing the ARN is because of certification it would be skill to require re-certification just for changing the alias portion of the ARN.

If there are concerns about bait-n-switch (where a skill is certified and then the code is swapped out for other code) then changing the endpoints could put this skill on a re-evaluation list to be checked out and removed if needed.

The audio player interface allows playing from a streaming service - e.g. a radio station
This is a continuous stream that could run for many hours - but the skill is only given the opportunity to provide song information at the start.
It could respond to user requests - such as "What song is this?" (which is OK) but, primarily for devices with screens, it would be useful for the skill to be able to provide title/subtitle/graphics as the songs change within the continuous stream.

This could be done by having the Skill start the audio stream with a duration parameter which would result in a callback when it is about to be reached - similar to the PlaybackNearlyFinished request.
The Skill could then send new metadata (potentially with an offset to say display in X seconds) and with a new duration parameter.

An alternative approach that could work without any skill being developed at all ...
If the player automatically took the metadata from an ICY stream (as provided by Shoutcast / Icecast servers) then it would be a good alternative - especially if the skill to parse a regex that should be used to parse the ICY title - with a default that would handle "artist name - song title" which is what many internet radio stations use (and StreamURL for the image).
For example ...
Playing http://www.dandelionradio.com/DandelionRadio.pls.

Name : Dandelion Radio
Genre : Alternative
Website: http://www.dandelionradio.com
Public : yes
Bitrate: 128kbit/s
ICY Info: StreamTitle='Rocker: D. A. Stern - Isn't It Obvious?';StreamUrl='http://www.dandelionradio.com/images/drlogosq-black.jpg';

It's increasingly common and frustrating to have Alexa ignore intents provided by the skill and instead pivot to a native function / keyword function.

For example, in a cooking skill I've included various intents for calling up the list of recipes offered by the skill. But as soon as Alexa hears the word "recipe", she quits the skill and says, "Sure. I can search by dish name and ingredients. What would you like?"

Alexa obviously did not check my list of intents, because if she did she would've read the list of recipes in my skill to the user.

The same problem exists with any intent that includes the word "list". As soon as Alexa hears the word "list" she assumes the user wants to view their Alexa shopping list---even if there are custom intents in the skill to handle user requests with the word "list" in them.

By default Alexa should *always* check for a matching intent within the skill *first*, and only resort to native / keyword functions if she doesn't find a match *within* the skill.

Currently all skills must run through Amazon’s Natural Language Understanding and provide a language model to Alexa. While this is helpful for getting started, many more advanced features for Language Processing and response building benefit heavily from having the user’s speech accessible to perform more complex operations like sentiment analysis, conversation reconstruction or custom natural language processing through models on other services. This allows developers to deliver a richer experience to users through the additional processing it makes possible.
For my use case in specifically it would be acceptable to have an option in the console to disable the language model and only receive the speech transcript in requests, and I think there are other developers who would benefit from this as well. Currently to get access to an approximation of the raw speech requires a basically empty language model, which works but suffers in performance.