> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.meetgail.com/platform/communications/llms.txt.
> For full documentation content, see https://docs.meetgail.com/platform/communications/llms-full.txt.

# Actions Creation guide

> A best practices guide for you to create the best Actions possible

# How to Build Bulletproof Actions

## 1. Core Mindset

* Treat the computer like a **super-intelligent baby**
* Never assume context, intent, or understanding
* If something feels “obvious” to a human, it is **not obvious** to the system
* Prompting and scripting = **coding in plain English (pseudocode)**

***

## 2. Think in Extreme Granularity

* Every step must be broken into **explicit, literal steps**
* Never rely on implied behavior

Ask yourself:

* *How does it know where to get this?*
* *How does it know what to say vs what to do?*
* *What happens if the caller says something slightly different?*

***

## 3. Actions Structure (Always)

Every use action clearly contain:

### Title

* Naming only
* Has zero impact on performance

### Objective

* Defines *when* the action should run
* Must be a **conditional statement**
* Never list steps here
* Answers: *“Under what condition does Gail enter this flow?”*
* Think: *“If the caller wants (x, y, z), then follow these steps:”*

### Steps

* Step-by-step instructions
* Linear
* Explicit
* Granular
* No ambiguity

***

## 4. Conditionals Are Gates (Not Suggestions)

Use conditionals to control flow precisely.

* **If / Then**
  * One condition must be true
* **Or**
  * Any one condition can be true
* **And**
  * All conditions must be true
* **Nor**
  * None of the conditions can be true

Conditionals decide **which path the flow follows**.

***

## 5. Directives vs Spoken Steps (Critical)

### Directives

* Tell Gail what to do internally
* Gail should **never say these out loud**

Examples:

* Show empathy
* Do not disclose timing
* Do not mention internal processes

### Spoken Steps

Must explicitly start with:

* “Ask the caller…”
* “Tell the caller…”

Never mix directives with spoken text — this breaks realism.

***

## 6. What Bad Scripts Have in Common

* Objectives that describe steps instead of conditions
* Vague steps like:
  * “Guide the caller…”
  * “Provide the link…”
* Missing answers to:
  * Where does the info come from?
  * How is it delivered?
  * What exact questions are asked?
* Transfers without determining **who** or **why**

***

## 7. What Good Scripts Do Well

* Objectives clearly define **when the flow starts**
* Steps are:
  * Linear
  * Explicit
  * Unambiguous
* Conditional logic is used **inside steps** to handle variations
* One use case can handle multiple scenarios if:
  * The end outcome is the same
  * The logic paths are clearly gated

***

## 8. Always Think Linearly

* Actions are **flowcharts written in words**
* Gail checks steps **top to bottom**
* If a condition isn’t met → move to the next step
* Once a condition is met → execute → exit flow

***

## 9. Start With the Outcome, Then Work Backwards

Ask:

* What is the final outcome? (transfer, quote, payment, info, etc.)
* What conditions must be satisfied to reach that outcome?
* What info must be gathered **before** taking steps?
* What decisions change the path?

***

## 10. Design Like You’re Teaching a Child

Ask yourself:

* Would a 5-year-old know what to ask next?
* Would they know the order?
* Would they know what *not* to say?
* If not → add steps

***

## 11. Key Rules to Remember

* Be specific
* Be literal
* Be granular
* Avoid assumptions
* One step = one clear instruction
* Linear > clever
* Clarity beats brevity