I'm getting intent failures with no corresponding error messages in logs (using alexa-skills-kit-sdk-for-nodejs and Lambda).

In troubleshooting, it looks like I may be exceeding the max allowed size of the JSON Response object. I see from the docs that the total size of your response cannot exceed 24 kilobytes.

I'm using session attributes to store data I need, and in some circumstances that data is larger than 24kb. The same documentation as referenced above says: When returning your response, you can include data you need to persist during the session in the sessionAttributes property. The attributes you provide are then passed back to your skill on the next request.

We need a way to store more than 24kb between intents in a session and not pass it in as part of the JSON Request object. Obviously if it goes in to the request it is going to come out as part of the response object and exceed the size limit.

I already persist data with DynamoDB, pulling in data to a new session each time. I don't want to have to go to the DB after every intent in the same session!

Allow users to link their social media accounts (Facebook, Twitter, Instagram, etc) in the Alexa App itself. Then allow skills to query which accounts are linked and request permission to use those links, without requiring each skill to perform account linking separately (and perhaps not even exposing the account details to the skill, for greater privacy!).

This would allow a skill to request permission to post to Facebook, for example, to share their new high score. The skill would request this permission at the time of the interaction, and the approval would be delegated to Amazon's built-in handling (to make sure the skill did not deceive the user into granting permission). Once permitted, the skill would be able to use an Amazon API that would in turn call the social media API.

This would abstract this common interaction away from each skill, provide greater consistency, and encourage organic growth of skills.

Right now the process of adding a new language to an existing skill in the developer console is tedious, especially when the data for those languages is exactly identical.

For example, right now, the process for manually copying things on the Publishing Information tab (Launch tab on the new console) alone involves tabbing back and forth 12 different times between the two languages to copy the text from the six different fields. For an English language skill being released worldwide, that process has to be done 4 times (and that's only going to grow).

Making things worse, in the new console, each time you tab you also get forced into a "save" dialog even if you didn't change anything (as described here: https://alexa.uservoice.com/forums/906892-alexa-skills-developer-voice-and-vote/suggestions/33345916--unsaved-data-flow-doesn-t-work-properly) which further multiplies the number of manual clicks you have to make just to have a new language with identical configuration.

A "copy to (select locale)" option would be much preferrable.

Acknowledging that there are minor differences in the available intents between locales (US first name intent not available in India, etc), it would be reasonable to still do the copy but just notify the developer that their intent model needs fixing.

"STOP" and "PAUSE" have two very distinct meanings:

"STOP": cause (an action, process, or event) to come to an end.
"PAUSE": a temporary stop in action or speech.
Different words, different meanings.

Unfortunately, AudioPlayer confuses the two, and even the documentation warns that

"when your skill is not in an active session but is playing audio, or was the skill most recently playing audio, utterances such as 'stop' send your skill an AMAZON.PauseIntent instead of an AMAZON.StopIntent."

This creates a poor user experience, and it doesn't take long to find at least 30 questions, requests relating to this.

For example, when a user is playing audio and they want to stop, they mean stop. As in, cease playing. However, when they "pause", they usually want to do something. In which case, the skill could wait for a command. Then the user could say "how long is this track" or "skip forwards 30 seconds".

This would at least provide a partial fix to the request below, although implement the idea below would provide a far better solution in all cases.

https://alexa.uservoice.com/forums/906892-alexa-skills-developer-voice-and-vote/suggestions/33406042-remove-requirement-for-invocation-name-when-an-aud

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).

We have a use case to put Alexa devices into many rooms and write custom Alexa skills to serve different responses and perform database updates based on which room they are in. As a result, we need to uniquely identify each Alexa in order to identify the room. We have look into various work around:
1) use "context:System:device:deviceId" which is specific to each skills and changes when the skills disable/enable.
2) use different userid to identify different Alexa but this would mean having many user accounts if the deployment is big
3) when Skill detects unknown "context:System:device:deviceId", expect user to use a certain utterance to provide the room information and register the new id in database.

However, none of these are scalable nor reliable so a real unique device ID for each Alexa would be desirable. Thanks!