> ## Documentation Index
> Fetch the complete documentation index at: https://rasa.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Skills & Routing

> How Mantle picks a skill, stacks sub-skills, and handles topic changes.

[Skills](https://rasa.com/docs/mantle/skills.md) are what you author; routing is what Mantle does with them at
runtime: deciding which skill is active, stacking them when one calls another,
and coping when the user changes the subject mid-task.

## Choosing a skill

The model reads each skill's `description` and picks the one that matches the
user's intent. The framework's job is to constrain that choice: before a skill
is offered, it checks the skill's `requires:` against what it already knows, so
a skill that needs an authenticated user is not even a candidate until
authentication is complete. The framework decides which skills are eligible; the
model chooses among them. See
[Guarantees & Guardrails](https://rasa.com/docs/mantle/orchestration/guarantees.md).

## The skill stack

Mantle tracks active skills on a stack. The current skill sits on top; when it
finishes, it comes off and the one underneath resumes.

* **Sub-skills.** A skill can hand off to another for a sub-task:
  `card_replace` calls `verify_identity`, which runs and passes its result back
  up. The parent always resumes where it left off. See
  [Sub-skills](https://rasa.com/docs/mantle/build-guide/sub-skills.md).
* **Interruptions.** The user changes topic mid-task. The current skill stays on
  the stack while Mantle handles the new request. It may return to the paused
  skill afterward, but that is not guaranteed. The user drives.

If a skill was partway through a fixed sequence of steps, its place is held. Once
the interrupting work finishes, the agent *offers* to resume it and continues from
the same step if the user agrees; otherwise the paused skill is dropped. It never
silently jumps back into a half-finished task.

## What the Inspector records

When you [inspect a conversation](https://rasa.com/docs/mantle/getting-started.md), Mantle writes explicit
lifecycle events for every skill (including built-in defaults):

| When | Event |
| - | - |
| A skill becomes active | `skill_activated` |
| The skill finishes | `skill_completed` |
| The skill is cancelled | `skill_cancelled` |
| Another skill interrupts it | `skill_interrupted` |
| The paused skill continues | `skill_resumed` |

Activated and completed carry the skill id only. Cancel, interrupt, and resume
also record the step where that happened. Cancelling a skill produces one
`skill_cancelled` even if several `flow_cancelled` events fire underneath.

The tracker still writes skill-level `flow_*` next to `skill_*` so older
consumers that only know flow events keep working. That extra `flow_*` is
temporary: Inspector currently shows both as separate log rows; later it will
show `skill_*` only for skill lifecycle. Ordered-block steps still emit
`flow_*` only (no `skill_*`). Historical conversations that only have flow,
MCP tool, or `slot_set` events still load.

Tool invocations persist as `tool_executed` (local Python or MCP, with the
server name when MCP) plus a matching `mcp_tool_executed` for compatibility.
Inspector's conversation log shows one tool-call row for that pair. Memory
writes persist as `memory_set` / `memory_cleared` plus a matching `slot_set`.
The Inspector memory panel still groups them like today's slot writes; the event
detail shows both types.

The field-level contract is in the [Execution Loop](https://rasa.com/docs/mantle/reference/execution-loop.md#tracker-events)
reference.

## Structured invocation vs. interruption

These two ways of leaving a skill behave differently, and the difference matters
for what you can rely on:

| | `@skill.<name>` invocation | User-initiated interruption |
| - | - | - |
| Who triggers it | The skill's own instructions | The user changing topic |
| How the parent is parked | As a delegation, resumed automatically when the target completes | As a digression, and the engine offers the customer a resume |
| Who decides what happens next | The skill author, at authoring time | The customer, in the moment |

Public memory is readable across skills either way, so what separates them is
control rather than data. The full parking rules are in
[skill.md](https://rasa.com/docs/mantle/reference/skill-md.md#jumps-to-blocks-and-skills).

## Next steps

> **[Skills](https://rasa.com/docs/mantle/skills.md)**
>
> What a skill is and what goes in it.

> **[Sub-skills & Composition](https://rasa.com/docs/mantle/build-guide/sub-skills.md)**
>
> Compose focused skills into larger flows.


## Related topics

- [System Prompt](https://rasa.com/docs/mantle/reference/system-prompt.md)
- [Execution loop reference](https://rasa.com/docs/mantle/reference/execution-loop.md)
- [Mantle](https://rasa.com/docs/mantle/overview.md)
- [Constraint Table](https://rasa.com/docs/mantle/reference/constraint-table.md)
- [Prompt templates](https://rasa.com/docs/mantle/reference/prompt-templates.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.