Repository: RasaHQ/rasa
Pull request: Updated Convo Pattern & Form Docs to Use Example Bots
**Proposed changes**:
- Updated Convo Pattern & Form Docs to use example bots
- Updated concert bot to include convo patterns doc use case

**Status (please check what you already did)**:
- [ ] added some tests for the functionality
- [x] updated the documentation
- [ ] updated the changelog (please check [changelog](https://github.com/RasaHQ/rasa/tree/master/changelog) for instructions)
- [ ] reformat files using `black` (please check [Readme](https://github.com/RasaHQ/rasa#code-style) for instructions)


Problem statement:
Revisit example bots before RC
Before the RC, we need to make sure that all the example bots are:
- [x] written as rules/stories according to our docs recommendations
- [x] used as examples in our documentation. if they aren't, we should consider getting rid of them or adapt them to what we describe in the docs

Hints from issue discussion:
@melindaloubser1 can you take this one on? 
Yes

Commit message: titles for code blocks

Patch to review:
diff --git a/docs/docs/business-logic.mdx b/docs/docs/business-logic.mdx
index 56aaf77bd1bc..0c85a46f6369 100644
--- a/docs/docs/business-logic.mdx
+++ b/docs/docs/business-logic.mdx
@@ -25,12 +25,9 @@ about the user's preferences to find them a suitable restaurant:
 </Chat>
 
 
-This page is a guide on handling the business logic of collecting user information to fulfill a request.
+This page is a guide on handling the **business logic** of collecting user information to fulfill a request.
 In the example above, business logic includes needing to know the user's preferred cuisine, party size, and seating preference.
-It uses abbreviated examples from the [formbot example bot](https://github.com/RasaHQ/rasa/tree/master/examples/formbot).
-Adapt the example
-described in this guide to build an assistant that can handle a conversation
-like the one above, or apply the guidelines to your own use case.
+The examples on this page come from the [formbot example bot](https://github.com/RasaHQ/rasa/tree/master/examples/formbot).
 
 ## Step-by-step Guide on Using Forms to Handle Business Logic
 
@@ -56,11 +53,11 @@ from the user:
 - whether they want to sit outside or not
 
 
-You define a form in the domain file (domain.yml) by specifying [slot mappings](forms.mdx#slot-mappings) for each
+You define a form in your domain by specifying [slot mappings](forms.mdx#slot-mappings) for each
 piece of required information. Slot mappings define both which
 slots are required, and how each slot can be filled:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 forms:
   - restaurant_form:
       cuisine:
@@ -81,7 +78,7 @@ forms:
 For any slot filled `from_entity`, the entity needs to be added
 to the domain.
 
-```
+```yaml-rasa title="domain.yml"
 entities:
   - cuisine
   - number
@@ -89,9 +86,9 @@ entities:
 
 Entities like numbers
 can be extracted by the [DucklingEntityExtractor](./components.mdx#ducklinghttpextractor). To use it, add  DucklingEntityExtractor
-to your NLU pipeline in `config.yml`.
+to your NLU pipeline:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 language: en
 pipeline:
 # other components
@@ -109,7 +106,7 @@ Since the form relies on certain [slots](domain.mdx#slots) being available,  you
 forms are usually `unfeaturized`, since their value doesn't change
 the flow of the conversation.
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 slots:
   cuisine:
     type: unfeaturized
@@ -135,7 +132,7 @@ about validation actions.
 To specify how the bot should ask for the required information,
 you define [`responses`](domain.mdx#responses) called `utter_ask_{slotname}` in your domain:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_ask_cuisine:
     - text: "What cuisine?"
@@ -149,9 +146,9 @@ responses:
 ### 2. Updating the configuration
 
 A form's [happy path](glossary.mdx#happy--unhappy-paths) should be defined as a [rule](rules.mdx) which means you'll need to add the [RulePolicy](policies.mdx#rule-policy)
-to your policies in your configuration file:
+to your policies:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 policies:
   - name: RulePolicy
 ```
@@ -161,14 +158,14 @@ policies:
 The form itself takes care of the logic around asking the user for all
 the required information, so
 you need only two rules for a form's happy path:
-One to that defines when it starts, and one that defines what happens when it has been filled.
+One that defines when it starts, and one that defines what happens when it has been filled.
 For the restaurant search example, in real life the assistant would look up
 a restaurant based on the user's preferences.
 In this case, the bot will utter a response with the details
 that would be used for a search.
 
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
   - rule: activate restaurant form
     steps:
@@ -201,9 +198,9 @@ examples for how the user will provide the required information.
 
 You need to provide training examples for the
 intent(s) that should activate the form.
-Add the intent `request_restaurant` to nlu.yml:
+Add examples for the intent `request_restaurant`:
 
-```yaml-rasa
+```yaml-rasa title="nlu.yml"
 nlu:
 - intent: request_restaurant
   examples: |
@@ -235,7 +232,7 @@ that isn't trained on your training data. Only a few examples are shown for each
 for your bot to work well, you should add more training data than is shown here:
 
 
-```yaml-rasa
+```yaml-rasa title="nlu.yml"
 nlu:
 - intent: affirm
   examples: |
@@ -266,9 +263,9 @@ nlu:
     - nine people
 ```
 
-Update domain.yml to include these intents:
+Update your domain to include these intents:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 intents:
   - request_restaurant
   - affirm
@@ -280,7 +277,7 @@ intents:
 
 Add the responses that are sent after the form has been submitted:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_submit:
   - text: "All done!"
@@ -297,11 +294,11 @@ Forms can simplify the logic of collecting user
 information. To define a minimal form like the restaurant search
 example above, this is a summary of what you'll need to do:
 
-- [ ] Update `config.yml`
-- [ ] Define the form with slot mappings
+- [ ] Add the RulePolicy to `config.yml`
+- [ ] Define the form with slot mappings in the domain
 - [ ] Add all required slots to the domain
 - [ ] Add rules for activating and submitting the form
-- [ ] Add examples for the intent to activate your form
+- [ ] Add examples for the intent(s) to activate your form
 - [ ] Add examples for the intent(s) to fill the required slots
 - [ ] Define an action or response for the bot to take when the form is completed
 - [ ] Update your domain with new intents and actions you've defined
diff --git a/docs/docs/chitchat-faqs.mdx b/docs/docs/chitchat-faqs.mdx
index 72c1e1e56b88..ac75bca33fe6 100644
--- a/docs/docs/chitchat-faqs.mdx
+++ b/docs/docs/chitchat-faqs.mdx
@@ -33,7 +33,7 @@ For FAQs and chitchat, you always want the assistant to respond the same way eve
 the same type of question is asked. [Rules](rules.mdx) allow you to do exactly that.
 To use rules, the you need to add the [RulePolicy](./policies.mdx#rule-policy) to your policies in your configuration file:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 policies:
 # other policies
 - name: RulePolicy
@@ -43,7 +43,7 @@ Next, include the ResponseSelector in your NLU pipeline in your configuration fi
 The ResponseSelector requires a featurizer and intent classifier to work, so
 it should come after these components in your pipeline, for example:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 pipeline:
   - name: WhitespaceTokenizer
   - name: RegexFeaturizer
@@ -64,7 +64,7 @@ By default, the ResponseSelector will build a single retrieval model for all ret
 To retrieve responses for FAQs and chitchat separately, use multiple ResponseSelector components
 and specify the `retrieval_intent` key:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 pipeline:
 # Other components
 - name: ResponseSelector
@@ -96,7 +96,7 @@ grouped under that retrieval intent will then be handled the same way.
 The action name starts with `utter_` and ends with the retrieval intent's name.
 Write rules for responding to FAQs and chitchat:
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
   - rule: respond to FAQs
     steps:
@@ -116,7 +116,7 @@ NLU training examples for the ResponseSelector look the same as
 regular training examples, except that their names must refer to the retrieval
 intent they are grouped under:
 
-```yaml-rasa
+```yaml-rasa title="nlu.yml"
 nlu:
   - intent: chitchat/ask_name
     examples: |
@@ -134,7 +134,7 @@ nlu:
 
 Be sure to update your domain file to include the added `chitchat` intent:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 intents:
 # other intents
 - chitchat
@@ -148,12 +148,12 @@ retrieval intents. Besides this, they can have all the characteristics of
 normal bot [response](domain.mdx#responses). For the chitchat intents
 listed above, our responses could look like:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_chitchat/ask_name:
   - image: "https://i.imgur.com/zTvA58i.jpeg"
-    text: hello, my name is retrieval bot.
-  - text: Oh yeah, I am called the retrieval bot.
+    text: Hello, my name is Retrieval Bot.
+  - text: I am called Retrieval Bot!
   utter_chitchat/ask_weather:
   - text: Oh, it does look sunny right now in Berlin.
     image: "https://i.imgur.com/vwv7aHN.png"
diff --git a/docs/docs/contextual-conversations.mdx b/docs/docs/contextual-conversations.mdx
index 0538fdb491db..f6c45bb64b4b 100644
--- a/docs/docs/contextual-conversations.mdx
+++ b/docs/docs/contextual-conversations.mdx
@@ -14,85 +14,77 @@ three overdue bills". The assistant needs to know the previous action to choose
 
 To create a context-aware conversational assistant, you need to define
 how the conversation history affects the next response.
-For example, if a user asks Sara, the Rasa bot, how to get started using Rasa,
-Sara gives the user
-different information based on whether they've built an AI assistant before or not:
-
-A conversation with a new user:
-<Chat caption="New User Conversation">
-<ChatUserText>How can I get started with Rasa?</ChatUserText>
-<ChatBotText>To determine how I can help you best, I'm going to ask you a few questions.</ChatBotText>
-<ChatBotText>Let's go. Are you new to Rasa?</ChatBotText>
+
+For example, if a user asks the example concert bot how to get started,
+the bot responds differently based on whether or not they like music:
+
+A conversation with a user who likes music:
+<Chat caption="User likes music">
+<ChatUserText>How can I get started ?</ChatUserText>
+<ChatBotText>I can help you find concerts and venues. Do you like music?</ChatBotText>
 <ChatUserText>yes</ChatUserText>
-<ChatBotText>And have you built a contextual assistant or a bot before?</ChatBotText>
+<ChatBotText>Awesome! You can ask me things like "Find me some concerts" or "What's a good venue"</ChatBotText>
 </Chat>
 
-A conversation with a returning user:
-<Chat caption="Returning User Conversation">
-<ChatUserText>How can I get started with Rasa?</ChatUserText>
-<ChatBotText>To determine how I can help you best, I'm going to ask you a few questions.</ChatBotText>
-<ChatBotText>Let's go. Are you new to Rasa?</ChatBotText>
+A conversation with a user who doesn't like music:
+<Chat caption="User doesn't like music">
+<ChatUserText>How can I get started ?</ChatUserText>
+<ChatBotText>I can help you find concerts and venues. Do you like music?</ChatBotText>
 <ChatUserText>no</ChatUserText>
-<ChatBotText>Ok, which product would you like to know more about? Rasa Open Source or Rasa X?</ChatBotText>
+<ChatBotText>Oh no!</ChatBotText>
 </Chat>
 
-
 ## Step-by-step Guide on Creating Contextual Conversation Patterns
 
-### 1. Creating Stories
-
-[Stories](./stories.mdx) are examples of how conversations should go.
-In the example above, Sara responds differently for new users
-and users with previous experience because of stories like this:
-
-
-```yaml-rasa
-stories:
-  - story: New user
-    steps:
-  - intent: how_to_get_started
-  - action: utter_getstarted
-  - action: utter_first_bot_with_rasa
-  - intent: affirm
-  - action: action_set_onboarding
-  - slot_was_set:
-    - onboarding: true
-  - action: utter_built_bot_before
-
-  - story: Not new user
-    steps:
-  - intent: how_to_get_started
-  - action: utter_getstarted
-  - action: utter_first_bot_with_rasa
-  - intent: deny
-  - action: action_set_onboarding
-  - slot_was_set:
-    - onboarding: false
-  - action: utter_ask_which_product
-```
-
-These stories diverge based on the user's intent (`affirm` or `deny`). Based on
-the user's intent, an action sets a slot that further directs
-the conversation.
-
-### 2. Defining Slots
+### 1. Defining Slots
 
 [Slots](domain.mdx#slots) are your assistant's memory. Slots store pieces of information that your
 assistant needs to refer to later and can direct the flow of the conversation
 based on `slot_was_set` events. There are different [types of slots](domain.mdx#slot-types),
 and each affects the conversation flow in its own way.
 
-In the getting started example, the `onboarding` slot is a boolean slot. If it is true, the
-user is treated as a new user and the bot sends onboarding messages. If it is false, the bot sends different messages
-aimed at returning users.
+In the concert bot example, the `likes_music` slot is a boolean slot. If it is true, the bot sends an intro message. If it is false, the bot sends a different message.
 You define a slot and its type in the domain:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 slots:
-  onboarding:
+  likes_music:
     type: bool
 ```
 
+### 2. Creating Stories
+
+[Stories](./stories.mdx) are examples of how conversations should go.
+In the example above, the concert bot responds differently for users who like music
+and users who don't because of these two stories:
+
+```yaml-rasa title="stories.yml"
+stories:
+  - story: User likes music
+    steps:
+    - intent: how_to_get_started
+    - action: utter_get_started
+    - intent: affirm
+    - action: action_set_music_preference
+    - slot_was_set:
+      - likes_music: True
+    - action: utter_awesome
+
+  - story: User doesn't like music
+    steps:
+    - intent: how_to_get_started
+    - action: utter_get_started
+    - intent: deny
+    - action: action_set_music_preference
+    - slot_was_set:
+      - likes_music: False
+    - action: utter_goodbye
+```
+
+These stories diverge based on the user's intent (`affirm` or `deny`). Based on
+the user's intent, a custom action sets a slot that further directs
+the conversation.
+
 ### 3. Configuring the TEDPolicy
 
 In addition to adding stories to account for context,
@@ -155,16 +147,16 @@ action to take next.
 In the story below, the user asks for help three times in a row. The first two times,
 the bot sends the same message, but the third time, it hands them off to a human
 
-```yaml-rasa
+```yaml-rasa  title="stories.yml"
 stories:
   - story: user persists in asking for help
     steps:
-  - intent: help
-  - action: utter_help
-  - intent: help
-  - action: utter_help
-  - intent: help
-  - action: action_human_handoff
+    - intent: help
+    - action: utter_help
+    - intent: help
+    - action: utter_help
+    - intent: help
+    - action: action_human_handoff
 ```
 
 In order for the model to learn this pattern, it needs to know at least the previous
@@ -174,9 +166,9 @@ predict the human handoff action.
 
 
 You can set the `max_history` by passing it to your policy's settings
-in the policy configuration yaml file, for example:
+in your config file, for example:
 
-```
+```yaml-rasa title="config.yml"
 policies:
   - name: "TEDPolicy"
     max_history: 5
diff --git a/docs/docs/fallback-handoff.mdx b/docs/docs/fallback-handoff.mdx
index 94b6a9a1f86c..45017e56937d 100644
--- a/docs/docs/fallback-handoff.mdx
+++ b/docs/docs/fallback-handoff.mdx
@@ -21,7 +21,7 @@ but for which you haven't implemented a user goal yet.
 You will need to define an `out_of_scope` intent in your NLU training data and add any known
 out-of-scope requests as training examples, for example:
 
-```yaml-rasa
+```yaml-rasa title="nlu.yml"
 nlu:
 - intent: out_of_scope
   examples: |
@@ -39,7 +39,7 @@ As with every intent, you should source the majority of your examples
 You'll need to define an out-of-scope response in the domain file.
 Using the utterance `utter_out_of_scope` as the default response, that would look like:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_out_of_scope:
   - text: Sorry, I can't handle that request.
@@ -49,7 +49,7 @@ responses:
 
 Finally, you will need to write a rule for what should happen for in out-of-scope request:
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
 - rule: out-of-scope
   steps:
@@ -88,9 +88,9 @@ for what the bot should do when `nlu_fallback` is predicted.
 
 #### 1. Updating the configuration
 
-To use the FallbackClassifier, add it to your NLU pipeline in config.yml.
+To use the FallbackClassifier, add it to your NLU pipeline:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 pipeline:
 # other components
 - name: FallbackClassifier
@@ -100,9 +100,9 @@ pipeline:
 #### 2. Defining the response message
 
 Define the message the bot should send when a message is classified with low confidence
-by adding a response.
+by adding a response:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_please_rephrase:
   - text: I'm sorry, I didn't quite understand that. Could you rephrase?
@@ -114,7 +114,7 @@ The following
 [Rule](./rules.mdx) will ask the user to rephrase when they send a message that is
 classified with low confidence:
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
 - rule: Ask the user to rephrase whenever they send a message with low NLU confidence
   steps:
@@ -145,7 +145,7 @@ the corresponding confidence threshold using the following steps:
 You will need to add the RulePolicy to your policies in config.yml. 
 By default, the rule policy comes with the settings below:
 
-```yaml-rasa
+```yaml-rasa title="config.yml"
 policies:
 - name: RulePolicy
   # Confidence threshold for the `core_fallback_action_name` to apply.
@@ -161,9 +161,9 @@ policies:
 #### 2. Defining the default response message
 
 To define what your bot will say when action confidence is below the threshold,
-define a response `utter_default`. 
+define a response `utter_default`:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_default:
   - text: Sorry I didn't get that. Can you rephrase?
@@ -184,7 +184,7 @@ The following snippet is an implementation of a custom action which does the sam
 `action_default_fallback` but dispatches a different template
 `utter_fallback_template`:
 
-```python
+```python title="actions.py"
 from typing import Any, Text, Dict, List
 
 from rasa_sdk import Action, Tracker
@@ -219,38 +219,29 @@ clarifying questions. The Two-Stage Fallback is made to handle low NLU confidenc
 using the following sequence:
 
 - A user message is classified with low confidence
-
-    - The user is asked to confirm the intent
-
+  - The user is asked to confirm the intent
 - The user confirms or denies the intent
-
-    - If they confirm, the conversation continues as if the intent was classified
-        with high confidence from the beginning. No further fallback steps are taken.
-
-    - If they deny, the user is asked to rephrase their message.
-
+  - If they confirm, the conversation continues as if the intent was classified
+    with high confidence from the beginning. No further fallback steps are taken.
+  - If they deny, the user is asked to rephrase their message.
 - The user rephrases their intent
-
-    - If the message is classified with high confidence, the conversation
-      continues as if the user had this intent from the beginning.
-
-    - If the rephrased user message still has low confidence, the user
-      is asked to confirm the intent.
-
+  - If the message is classified with high confidence, the conversation
+   continues as if the user had this intent from the beginning.
+  - If the rephrased user message still has low confidence, the user
+   is asked to confirm the intent.
 - The user confirms or denies the rephrased intent
-
-    - If they confirm, the conversation continues as if the user had this intent from the beginning.
-    - If they deny, an ultimate fallback action is triggered (e.g. a handoff to a human).
-
+  - If they confirm, the conversation continues as if the user had this intent from the beginning.
+  - If they deny, an ultimate fallback action is triggered (e.g. a handoff to a human).
 
 The Two-Stage-Fallback can be enabled using the following steps:
 
+
 #### 1. Updating the configuration
 
 Add FallbackClassifier to your pipeline and the [RulePolicy](./policies.mdx#rule-policy)
 to your policy configuration:
 
-```yaml
+```yaml title="config.yml"
 pipeline:
 # other components
 - name: FallbackClassifier
@@ -267,7 +258,7 @@ policies:
 To define how your bot asks the user to rephrase their message,
 define  the response `utter_ask_rephrase`:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_ask_rephrase:
   - text: I'm sorry, I didn't quite understand that. Could you rephrase?
@@ -281,9 +272,9 @@ see the [documentation default actions](default-actions.mdx).
 
 Add the following [Rule](./rules.mdx) to your training data. This rule will make sure
 that the Two-Stage-Fallback will be activated whenever a message is received with
-low classification confidence.
+low classification confidence:
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
 - rule: Implementation of the Two-Stage-Fallback
   steps:
diff --git a/docs/docs/forms.mdx b/docs/docs/forms.mdx
index cb1896d0016c..e1b1bf5b0f51 100644
--- a/docs/docs/forms.mdx
+++ b/docs/docs/forms.mdx
@@ -29,15 +29,18 @@ need to define [Slot Mappings](./forms.mdx#slot-mappings) for each slot which yo
 form should fill.
 You can specify one or more slot mappings for each slot to be filled.
 
-The following example of a form `your_form` will fill only one slot
-`age` from an extracted entity `age`.
+The following example of a form `restaurant_form` will fill the slot
+`cuisine` from an extracted entity `cuisine` and slot `num_people` from entity `number`.
 
 ```yaml-rasa
 forms:
-  your_form:
-    age:
-    - type: from_entity
-      entity: age
+  restaurant_form:
+    cuisine:
+      - type: from_entity
+        entity: cuisine
+    num_people:
+      - type: from_entity
+        entity: number
 ```
 
 Once the form action gets called for the first time, the form gets activated and will
@@ -57,14 +60,14 @@ triggering a form, you can for example use the following rule:
 rules:
 - rule: Activate form
   steps:
-  - intent: intent_which_activates_form
-  - action: your_form
-  - active_loop: your_form
+  - intent: request_restaurant
+  - action: restaurant_form
+  - active_loop: restaurant_form
 ```
 
 :::note
-The `active_loop: your_form` step indicates that the form should be activated after
-`your_form` was run.
+The `active_loop: restaurant_form` step indicates that the form should be activated after
+`restaurant_form` was run.
 :::
 
 ### Deactivating a Form
@@ -81,15 +84,16 @@ rules:
 - rule: Submit form
   condition:
   # Condition that form is active.
-  - active_loop: your_form
+  - active_loop: restaurant_form
   steps:
   # Form is deactivated
-  - action: your_form
+  - action: restaurant_form
   - active_loop: null
-  - slot_was_set: 
+  - slot_was_set:
     - requested_slot: null
-  # The action we want to run when the form is submitted.
-  - action: utter_all_slots_filled
+  # The actions we want to run when the form is submitted.
+  - action: utter_submit
+  - action: utter_slots_values
 ```
 
 Users might want to break out of a form early. Please see
@@ -235,14 +239,14 @@ rules:
 - rule: Example of an unhappy path
   condition:
   # Condition that form is active.
-  - active_loop: your_form
+  - active_loop: restaurant_form
   steps:
   # This unhappy path handles the case of an intent `chitchat`.
   - intent: chitchat
   - action: utter_chitchat
   # Return to form after handling the `chitchat` intent
-  - action: your_form
-  - active_loop: your_form
+  - action: restaurant_form
+  - active_loop: restaurant_form
 ```
 
 In some situations, users may change their mind in the middle of the form action
@@ -257,7 +261,7 @@ rules:
 - rule: Example of an unhappy path
   condition:
   # Condition that form is active.
-  - active_loop: your_form
+  - active_loop: restaurant_form
   steps:
   - intent: stop
   - action: utter_ask_continue
@@ -266,10 +270,10 @@ rules:
   - active_loop: null
 ```
 
-It is **strongly** recommended that you build these rules or stories using 
-[interactive learning](./writing-stories.mdx#using-interactive-learning). 
+It is **strongly** recommended that you build these rules or stories using
+[interactive learning](./writing-stories.mdx#using-interactive-learning).
 If you write these rules / stories by hand you will likely miss important
-things. 
+things.
 
 ## Advanced Usage
 
@@ -290,7 +294,7 @@ section of your domain:
 
 ```yaml-rasa
 actions:
-- validate_your_form
+- validate_restaurant_form
 ```
 
 When the form is executed it will run your custom action. In your custom action
@@ -318,9 +322,9 @@ from rasa_sdk import Action
 from rasa_sdk.events import SlotSet
 
 
-class ValidateSlots(Action):
+class ValidateRestaurantForm(Action):
     def name(self) -> Text:
-        return "validate_your_form"
+        return "validate_restaurant_form"
 
     def run(
         self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict
@@ -365,9 +369,9 @@ from rasa_sdk import Action
 from rasa_sdk.events import SlotSet
 
 
-class ValidateSlots(Action):
+class ValidateRestaurantForm(Action):
     def name(self) -> Text:
-        return "validate_your_form"
+        return "validate_restaurant_form"
 
     def run(
         self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict
@@ -388,7 +392,7 @@ which should be extracted next. If all desired slots are filled, set `requested_
 to `None`.
 
 The following example shows the implementation of a custom action which requests
-the three slots `last_name`, `first_name`, and `city`.
+the three slots `cuisine`, `num_people`, and `outdoor_seating`.
 
 ```python
 from typing import Dict, Text, List
@@ -400,14 +404,14 @@ from rasa_sdk import Action
 from rasa_sdk.events import SlotSet
 
 
-class ValidateSlots(Action):
+class ValidateRestaurantForm(Action):
     def name(self) -> Text:
-        return "validate_your_form"
+        return "validate_restaurant_form"
 
     def run(
         self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict
     ) -> List[EventType]:
-        required_slots = ["last name", "first_name", "city"]
+        required_slots = ["cuisine", "num_people", "outdoor_seating"]
 
         for slot_name in required_slots:
             if tracker.slots.get(slot_name) is None:
@@ -430,7 +434,7 @@ The response to this `explain` intent depends on where we are in the story.
 In the restaurant case, your stories would look something like this:
 
 ```yaml-rasa
-stories: 
+stories:
 - story: explain cuisine slot
   steps:
   - intent: request_restaurant
@@ -438,7 +442,7 @@ stories:
   - active_loop: restaurant
   - slot_was_set:
     - requested_slot: cuisine
-  - intent: explain 
+  - intent: explain
   - action: utter_explain_cuisine
   - action: restaurant_form
   - active_loop: null
@@ -452,13 +456,13 @@ stories:
     - requested_slot: cuisine
   - slot_was_set:
     - requested_slot: num_people
-  - intent: explain 
+  - intent: explain
   - action: utter_explain_num_people
   - action: restaurant_form
   - active_loop: null
 ```
 
-Again, it is **strongly** recommended that you use 
+Again, it is **strongly** recommended that you use
 [interactive learning](./writing-stories.mdx#using-interactive-learning) to build these stories.
 
 ### Using a Custom Action to Ask For the Next Slot
@@ -480,12 +484,12 @@ from rasa_sdk import Action
 
 class AskForSlotAction(Action):
     def name(self) -> Text:
-        return "action_ask_age"
+        return "action_ask_cuisine"
 
     def run(
         self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict
     ) -> List[EventType]:
-        dispatcher.utter_message(text="How old are you?")
+        dispatcher.utter_message(text="What cuisine?")
         return []
 ```
 
diff --git a/docs/docs/reaching-out-to-user.mdx b/docs/docs/reaching-out-to-user.mdx
index 2866118e0b4a..b0a4c9961c52 100644
--- a/docs/docs/reaching-out-to-user.mdx
+++ b/docs/docs/reaching-out-to-user.mdx
@@ -24,9 +24,9 @@ welcome rule.
 ### 1. Update the configuration
 
 Since you are using a rule for this behavior, you need to add the [RulePolicy](./policies.mdx#rule-policy)
-to your `config.yml`:
+to your configuration file:
 
-```yaml-rasa
+```yaml-rasa  title="config.yml"
 policies:
   # other policies
   - name: RulePolicy
@@ -35,10 +35,9 @@ policies:
 ### 2. Add a rule
 
 To have the assistant respond to the intent `greet` with a welcome message
-only at the beginning of a conversation, add the following rule to your
-`rules.yml` file:
+only at the beginning of a conversation, add the following rule:
 
-```yaml-rasa
+```yaml-rasa  title="rules.yml"
 rules:
   - rule: welcome user
     conversation_start: true  # this rule only applies at the beginning of a conversation
@@ -49,9 +48,9 @@ rules:
 
 ### 3. Add a response template
 
-Finally, add a template for the `utter_welcome` response to your `domain.yml`:
+Finally, add a template for the `utter_welcome` response to your domain:
 
-```yaml-rasa
+```yaml-rasa title="domain.yml"
 responses:
   utter_welcome:
   - text: Hi there! What can I help you with today?
@@ -99,7 +98,7 @@ In the dry plant example, your Raspberry Pi needs to send a message with the int
 `EXTERNAL_dry_plant` to the `trigger_intent` endpoint. This intent will be reserved for use by the Raspberry Pi, so
 there won't be any NLU training examples for it.
 
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 intents:
   - EXTERNAL_dry_plant
 ```
@@ -114,7 +113,7 @@ easier to see which intents are expected to come from external devices when work
 To tell the assistant which plant needs watering, you can define an entity that you'll post along with the intent.
 To be able to use the entity value directly in a response, define a slot by the same name:
 
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 entities:
   - plant
 
@@ -127,7 +126,7 @@ slots:
 
 You'll need a rule that tells your assistant how to respond when it receives a message from the Raspberry Pi.
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
   - rule: warn about dry plant
     steps:
@@ -139,7 +138,7 @@ rules:
 
 You'll need to define the response text for `utter_warn_dry`:
 
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 responses:
   utter_warn_dry:
   - text: "Your {plant} needs some water!"
@@ -189,7 +188,7 @@ To schedule a reminder, you need to define a custom action that returns
 the `ReminderScheduled` event. For example, the following custom action
 schedules a reminder for five seconds from now:
 
-```python
+```python  title="actions.py"
 import datetime
 from rasa_sdk.events import ReminderScheduled
 from rasa_sdk import Action
@@ -240,7 +239,7 @@ entity, the action reacting to the reminder can use it to say "Remember to call
 
 To schedule a reminder, add a rule:
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
 - rule: Schedule a reminder
   steps:
@@ -255,7 +254,7 @@ rules:
 
 You should add NLU training examples for scheduling the reminder:
 
-```yaml-rasa
+```yaml-rasa title="nlu.yml"
 nlu:
 - intent: ask_remind_call
   examples: |
@@ -268,7 +267,7 @@ nlu:
 
 You should also add it to your domain:
 
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 intents:
   - ask_remind_call
 ```
@@ -278,7 +277,7 @@ intents:
 By adding SpacyNLP and SpacyEntityExtractor to your pipeline in config.yml, you won't need to annotate any of the
 names in your training data, since Spacy has a `PERSON` dimension:
 
-```yaml-rasa
+```yaml-rasa  title="config.yml"
 pipeline:
 # other components
 - name: SpacyNLP
@@ -303,7 +302,7 @@ In the call reminder example, you want to use the entities that come with the
 reminder to be reminded to call specific people, so you need to write a custom
 action that does that:
 
-```python
+```python title="actions.py"
 class ActionReactToReminder(Action):
     """Reminds the user to call someone."""
 
@@ -327,7 +326,7 @@ class ActionReactToReminder(Action):
 
 To tell your bot what action to run when a reminder is triggered, add a rule.
 
-```yaml-rasa
+```yaml-rasa title="rules.yml"
 rules:
 - rule: Trigger `action_react_to_reminder` for `EXTERNAL_reminder`
   steps:
@@ -340,7 +339,7 @@ rules:
 You'll need to define the intent that triggers reacting to the reminder. You don't need to add any training examples,
 since the intent is reserved for the reminder.
 
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 intents:
 - intent: EXTERNAL_reminder
 ```
@@ -367,7 +366,7 @@ If you only want to cancel certain reminders, you can specify some parameters by
 For the call reminder example, you can define a custom action `action_forget_reminders` that cancels
 all reminders:
 
-```python
+```python title="actions.py"
 class ForgetReminders(Action):
     """Cancels all reminders."""
 
@@ -393,7 +392,7 @@ All reminders are cancelled whenever you shutdown your Rasa server.
 
 You'll need to add a rule for cancelling a reminder.
 
-```yaml-rasa
+```yaml-rasa  title="rules.yml"
 rules:
 - rule: Cancel a reminder
   steps:
@@ -407,7 +406,7 @@ rules:
 You'll need to define an intent that triggers cancelling the reminder.
 
 
-```yaml-rasa
+```yaml-rasa  title="nlu.yml"
 nlu:
 - intent: ask_forget_reminders
   examples: |
@@ -418,7 +417,7 @@ nlu:
 ```
 
 You should also add it to domain.yml:
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 intents:
 - intent: ask_forget_reminders
 ```
diff --git a/docs/docs/unexpected-input.mdx b/docs/docs/unexpected-input.mdx
index 97ce563c9df3..5e36645909ca 100644
--- a/docs/docs/unexpected-input.mdx
+++ b/docs/docs/unexpected-input.mdx
@@ -17,7 +17,7 @@ This page is a guide on methods for handling unexpected input that is still with
 Depending on what kind of unexpected
 input you're trying to handle, some or all of the methods describe may be applicable for you. This guide
 is not about disambiguating user input or handling out-of-scope questions; for these cases see
-the guide on [fallback and human handoff](fallback-handoff.mdx)
+the guide on [fallback and human handoff](fallback-handoff.mdx).
 
 
 ## User Interjections
@@ -54,7 +54,7 @@ The response should differ for each slot. For example:
 Since we want the `requested_slot` to influence the conversation,
 we need to make the `requested_slot` featurized, and assign it the categorical type:
 
-```yaml-rasa
+```yaml-rasa  title="domain.yml"
 slots:
   requested_slot:
     type: categorical
@@ -72,7 +72,7 @@ unfeaturized slots are only used for storing information.
 
 You can then write stories for specific responses to interruptions based on the value of `requested_slot`, for example:
 
-```yaml-rasa
+```yaml-rasa title="stories.yml"
 stories:
 - story: cuisine interruption
   steps:
diff --git a/examples/concertbot/actions/actions.py b/examples/concertbot/actions/actions.py
index e218939f5881..1036536935dc 100644
--- a/examples/concertbot/actions/actions.py
+++ b/examples/concertbot/actions/actions.py
@@ -49,3 +49,19 @@ def run(self, dispatcher, tracker, domain):
         venues = tracker.get_slot("venues")
         dispatcher.utter_message(text=f"venues from slots: {venues}")
         return []
+
+
+class ActionSetMusicPreference(Action):
+    def name(self):
+        return "action_set_music_preference"
+
+    def run(self, dispatcher, tracker, domain):
+        """Sets the slot 'likes_music' to true/false dependent on whether the user
+        likes music"""
+        intent = tracker.latest_message["intent"].get("name")
+
+        if intent == "affirm":
+            return [SlotSet("likes_music", True)]
+        elif intent == "deny":
+            return [SlotSet("likes_music", False)]
+        return []
diff --git a/examples/concertbot/config.yml b/examples/concertbot/config.yml
index 386f1a8cab3e..614da5a99e27 100644
--- a/examples/concertbot/config.yml
+++ b/examples/concertbot/config.yml
@@ -10,6 +10,7 @@ pipeline:
     min_ngram: 1
     max_ngram: 4
   - name: "DIETClassifier"
+    epochs: 100
   - name: FallbackClassifier
     threshold: 0.4
     ambiguity_threshold: 0.1
diff --git a/examples/concertbot/data/nlu.yaml b/examples/concertbot/data/nlu.yaml
index 87b674601ae0..97a8e76c333b 100644
--- a/examples/concertbot/data/nlu.yaml
+++ b/examples/concertbot/data/nlu.yaml
@@ -38,3 +38,20 @@ nlu:
       - compare reviews
       - show me a comparison of the reviews
 
+  - intent: how_to_get_started
+    examples: |
+      - how do I get started
+      - what can I do
+      - start
+
+  - intent: affirm
+    examples: |
+      - yes
+      - yeah
+      - yep
+
+  - intent: deny
+    examples: |
+      - nope
+      - no
+      - absolutely not
\ No newline at end of file
diff --git a/examples/concertbot/data/stories.yaml b/examples/concertbot/data/stories.yaml
index 7399acbdf558..9e8afde366aa 100644
--- a/examples/concertbot/data/stories.yaml
+++ b/examples/concertbot/data/stories.yaml
@@ -31,3 +31,23 @@ stories:
       - concerts: [{"artist": "Foo Fighters", "reviews": 4.5}]
     - intent: compare_reviews
     - action: action_show_concert_reviews
+
+  - story: how_to_get_started, doesn't like music
+    steps:
+    - intent: how_to_get_started
+    - action: utter_get_started
+    - intent: deny
+    - action: action_set_music_preference
+    - slot_was_set:
+      - likes_music: False
+    - action: utter_goodbye
+
+  - story: how_to_get_started, likes music
+    steps:
+    - intent: how_to_get_started
+    - action: utter_get_started
+    - intent: affirm
+    - action: action_set_music_preference
+    - slot_was_set:
+      - likes_music: True
+    - action: utter_awesome
diff --git a/examples/concertbot/domain.yml b/examples/concertbot/domain.yml
index 2deb1f978de5..01e45ca4afa0 100644
--- a/examples/concertbot/domain.yml
+++ b/examples/concertbot/domain.yml
@@ -5,19 +5,24 @@ slots:
     type: list
   venues:
     type: list
+  likes_music:
+    type: bool
 
 intents:
- - greet
- - thankyou
- - goodbye
- - search_concerts
- - search_venues
- - compare_reviews
- - bot_challenge
- - nlu_fallback
+  - affirm
+  - deny
+  - greet
+  - thankyou
+  - goodbye
+  - search_concerts
+  - search_venues
+  - compare_reviews
+  - bot_challenge
+  - nlu_fallback
+  - how_to_get_started
 
 entities:
- - name
+  - name
 
 responses:
   utter_greet:
@@ -30,12 +35,17 @@ responses:
     - text: "you're very welcome"
   utter_iamabot:
     - text: "I am a bot, powered by Rasa."
+  utter_get_started:
+    - text: "I can help you find concerts and venues. Do you like music?"
+  utter_awesome:
+    - text: "Awesome! You can ask me things like \"Find me some concerts\" or \"What's a good venue\""
 
 actions:
   - action_search_concerts
   - action_search_venues
   - action_show_concert_reviews
   - action_show_venue_reviews
+  - action_set_music_preference
 
 session_config:
   session_expiration_time: 60  # value in minutes


Code review comments:
diff_hunk: @@ -38,3 +38,20 @@ nlu:
       - compare reviews
       - show me a comparison of the reviews
 
+  - intent: how_to_get_started
+    examples: |
+      - how do I get started
+      - what can I do
+      - start
+
+  - intent: affirm
+    examples: |
+      - yes
+      - yeah
+      - yep
+
+  - intent: deny
+    examples: |
+      - nope
+      - no
+      - absolutely not
path: examples/concertbot/data/nlu.yaml
text: @user1:

```suggestion
      - absolutely not
  
```