I have a project coming up for someone that may include sensitive info, and I thought it would be useful to be able to run a script to delete voice clips through the CLI in order to scrub information it might have sent off without having to manually go through the app or something every time.

Or, even better, a way through the ASK to say something like "Alexa, delete voice recordings" and have it delete the recordings in some way.

I had originally asked about this in the dev forum and it was suggested that I suggest it here. I think it would be very useful for companies that would like to move to using VUI with Alexa but don't want any kind of sensitive information (like health info, for instance) to be leaked.

Even if this request is parsed as "Have a setting where you don't save recordings when speaking to Alexa", though I figured the voice clips are recorded for a reason, so deleting the recordings programmatically would be super helpful in this case.

Currently when enabling Beta testing for a skill, it is necessary to add the email addresses of the beta testers. They will then receive an invite, which will allow them to test the skill. The invite URL is not usable by anybody who has not been added to the list. It would be nice to be able to allow users to apply to be testers have with options for this to either be on an approval basis or open. This would then make it a lot easier to manage testers as it would not be necessary for us to obtain their email addresses.

PROBLEM: Forcing a user to remember a skill name is counter-intuitive, bad experience and leads to low adoption rates.

Examples :
Alexa, tell Agent NEO to find my Home Value
Alexa, tell Harmony to turn on my TV
Alexa, ask AllRecipes for a Pasta Recipe

Proposed Solution:
Alexa, find my home's value (Alexa knows that the skill Agent NEO that the user has enabled, can handle this intent)
Alexa, turn on my TV (Alexa knows that the skill Agent NEO that the user has enabled, can handle this intent)
Alexa, find a Pasta Recipe (Alexa knows that the skill AllRecipes that the user has enabled, can handle this intent)

All Alexa has to do to achieve this is, scan through the intent handlers of the skills the user has installed. Then simply pass the command to the correct skill. This is so much smoother than having to tell Alexa to tell a skill name to do something.

Google home introduced this feature a few months ago and it works so seamlessly.

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.

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

I get the error message:

> This may be due to an expired session, or a model that exceeds 1MB in size.

which is new a new constraint, 3 month ago that same language model worked fine (in the old alexa console, which now also throws this error message). My language model is rather huge (~2.8MB), since I'm using the occupations model of the European Commission (ESCO: https://ec.europa.eu/esco/portal/occupation).

It is very unfortunate that the custom types are counted against the 1 MB budget. If I used the built-in types, I could use more intents and example sentences in my languageModel. Therefore, I suggest that the custom types be budgeted separately. For example X megabytes per custom type.