Simple voice control of DIY devices could be achieved if the Routines section of the Alexa App had an option to do an HTTP POST.

eg/ I have a home-made lamp (based on an ESP8266) which I currently control using a custom skill that drops the JSON payload to a Linux server which interprets it then does a HTTP POST to the lamp's URL with the required mode as a parameter. ("mode=candles"/"mode=off"/"mode=purple"...etc)

I could (and other hobbiests and educators could) much more easily have implemented this with an Alexa Routine identified by "make it candle time" with a line in the routine which would hike the command over to the lamp's URL without the need for the custom skill or my local server.

The POST option would need to accept a HOST:PORT combination in order to perform appropriate routing to devices once it hits someone's router.

This would open up opportunities for people to implement voice control of custom devices without the need to create a skill, have their own server or implement forwarding in AWS.

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.

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.

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.

More than 1 million Bulgarian immigrants scattered across the globe are struggling to preserve their cultural identity/heritage and to pass it over to their children. There are Alexa skills (like "Bulgarian library" skill) which could help them teach BG-language to their children however currently Amazon does not allow access to this skill from anywhere except US,UK,CA,AU. Most of the world (Germany, France, Italy, Spain, etc) has no access to it. So, in this case splitting the globe into regions makes no sense whatsoever.

Would be greatly appreciated by thousands of people IF Amazon allows access to skills which are outside the physical "region" a given person currently resides into (without having to give up all other services tied to that region)

One way to accomplish this is:
As part of certification process, in "opt in for auto distribution" to have additional "exempt from local interaction-model requirement" checkbox along with "why you need this ?" text box where basically the developer could ask for a given skill to be distributed (say in Germany) even though only English interaction-model is implemented. This would be rare case anyway and Amazon still keeps the right to allow if reasonable or deny such request.

Thanks for consideration

A public S3 bucket is used to host skill icons, audio files, images, and videos for Alexa skills. This feature adds a new deploy target to the ASK CLI.

Configuration for the bucket name and region would be stored in '.ask/config'
$ deploy --target s3

The would sync all files and folders in a known local folder to the bucket at: https://s3.amazonaws.com/my-bucket/

The first time this is done, the bucket will be created and a CORS configuration applied.

Calling 'ask deploy' will also sync local folders and files to S3. Because the skill icon can be hosted in the S3 bucket, deploy to s3 will occur before the deploy of the skill.json file.

Behind the scenes, the following commands will be called:

make bucket

aws s3 mb s3://{bucket-name}/ --profile {aws-profile-name}

set CORS

aws s3api put-bucket-cors --bucket {bucket-name} --cors-configuration file://.deploy-s3/s3-cors.json --profile {aws-profile-name}

File: s3-cors.json
{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedHeaders": ["Authorization"],
"AllowedMethods": ["GET"],
"MaxAgeSeconds": 3000
}
]
}

sync s3

aws s3 sync ./.deploy-s3 s3://{bucket-name}/ --profile {aws-profile-name} --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers