About skills in Composer and reuse of conversation logic between bots

APPLIES TO: Composer v1.x and v2.x

To share conversational logic, you can create or consume skills. A skill is a bot where some of its features are callable from other bots. In this way, you can create a user-facing bot and extend it by consuming your own or third party skills.

  • A skill is a bot that can perform a set of tasks for another bot. A bot can work as both a skill and a user-facing bot.
  • A skill consumer is a bot that can call one or more skills. A user-facing skill consumer is also called a root bot.
  • A skill manifest is a JSON file that describes the actions the skill can perform, its input and output parameters, and the skill's endpoints.
    • Composer can use the information in a skill manifest to connect a bot to a deployed skill.
    • Composer creates a skill manifest for you when you export a bot as a skill.

The user interacts directly only with a root bot; however, the root bot can delegate some of its conversational logic to a skill.

You should already be familiar with some of the basics of bot design:

How Bot Framework skills work

Skills are a feature of the Bot Framework SDK and Composer:

  • Skills and skill consumers communicate over HTTP using the Bot Framework protocols.
  • Skills support user authentication.
  • A skill consumer can consume multiple skills.
  • A skill consumer can consume a skill developed in any language. For example, a C# bot can consume a skill implemented using Python.
  • A skill can also be a skill consumer and call other skills.
  • A skill advertises its capabilities through a skill manifest.

This diagram shows some of the possible permutations.

Block dialog of skill consumers and skills

Different skill consumers can access both distinct and common skills. Skills and consumers can use different programming languages.

How skills and consumers communicate

It's important to understand certain aspects of this design, independent of which bot you're designing.

  • The skill consumer and skill manage their own state separately.
  • Because the root and skill bots communicate over HTTP, the instance of the consumer that receives an activity from a skill may not be the same instance that sent the initiating activity. Different servers may handle these two requests.
  • The user-root conversation is different than the root-skill conversation.
    • Each consumer-skill conversation has a unique ID, different from the conversation between the user and the root bot.
    • A consumer-skill conversation ends when the skill completes its task or when the consumer cancels the conversation.


Service-level authentication is managed by the Bot Connector service. The framework uses bearer tokens and bot application IDs to verify the identity of each bot.


All deployed bots (the skill consumer and any skills it consumes) must have valid application credentials.

When testing both a consumer and skill locally, you can test both bots without an app ID or password. However, an Azure subscription is still required to deploy your skill to Azure.

Claims are validated based on the bot's configuration file.

  • You must update skills to allow specific consumers to call them.
  • Composer updates the consumer bot's configuration when you add a skill to the bot.

How skills describe their features

A skill manifest is a JSON file that describes the actions the skill can perform, its input and output parameters, the skill's endpoints, and a dispatch model for the skill. Composer can use the dispatch model to help a consumer bot route supported user requests to the skill.

  • The skill publisher can provide the skill manifest as a remote file or as a compressed copy of the skill's manifests folder.
  • For information about the skill manifest format, see how to write a skill manifest.

Next steps