4 Using entity resolution and built-in intents to extend an Alexa skill

This chapter shows how to extend the Sleep Tracker skill into a more robust “Super Sleeper” by shifting development from the browser to the Alexa Skills Kit CLI, and by improving understanding and handling of user input with entity resolution and built‑in intents. It reframes a skill as two coordinated parts—an interaction model that trains Alexa’s NLU and fulfillment code that responds to requests—and emphasizes faster, more disciplined workflows through local files, version control, and one‑command deployment. It also covers the user’s entry points into a skill, including launching without an intent and gracefully exiting with consistent, platform‑wide behaviors.

The ASK CLI streamlines creation, configuration, and deployment: developers define the skill manifest and interaction models locally, organize code under lambda/custom, and deploy both model and Lambda with a single command. The generated project structure makes locales and intents explicit, while the “standard” skill builder (via ask-sdk) prepares the skill for integrations like DynamoDB. The CLI’s simulate command lets you test utterances end‑to‑end through Alexa’s NLU, capture the resulting JSON, and even invoke the Lambda handler locally for rapid, repeatable testing without constant redeployments.

Entity resolution upgrades custom slot types into entities with IDs, canonical values, and synonyms, letting fulfillment rely on stable IDs instead of fragile synonym lists and improving resilience to phrasing variation and recognition errors. The chapter demonstrates how to read resolution results safely, account for multiple matches, and understand where entity resolution does and doesn’t apply (for example, built‑in number slots). It also integrates built‑in intents like Stop and Cancel and introduces LaunchRequest handling, showing how flexible canHandle logic and careful handler ordering enable shared handlers, clear entry experiences, and consistent, user‑friendly exits.

Figure 4.1. The ASK CLI works locally for some functions, and in conjunction with the SMAPI for others

Figure 4.2. Each part of the file structure corresponds to a different part of the finished skill

Figure 4.3. Entity resolution groups similar values together under a single canonical value and ID

Figure 4.4. The deployment sends the different files in different directions to configure the skill

Figure 4.5. The flow to determine which handler will respond to a request is like a conveyor belt, with the request coming off the belt once a condition is met

Figure 4.6. The simulate command communicates with Alexa and returns the request and response

• Using the ASK CLI creates a central, local place for skill creation and configuration and demonstrates the relation between the fulfillment and interaction configuration.
  
• People will ask for the same thing in different ways, and entity resolution provides a tidy way to organizing these synonyms, with a canonical value and an ID.
  
• Some intents are common enough for Alexa to provide established interaction models; developers can add these built-in intent to any skill.
  
• The flow of information that starts with the user’s utterance doesn’t stop inside the fulfillment, but instead shuffles through each handler object’s canHandle method until one returns true.
  
• LaunchRequest is triggered when a user asks for a skill without an explicit intent. A handler must be created by the developer to catch and respond to this request.
  
• The ASK CLI’s simulate command will simulate an Alexa invocation without using a device or the developer console.
  
• Capturing the request created by the Alexa service and sending it to the fulfillment handler directly allows for quick, local invocation of the skill fulfillment without deploying.
  

FAQ