> ## Documentation Index
> Fetch the complete documentation index at: https://mantle.rasa.com/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](/skills) 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 decides which skills are eligible: `hidden`,
`disabled`, and engine-managed skills are omitted from routing. A
`precondition` does **not** hide the skill — the engine parks it as pending
and runs the bound resolver first. See
[Guarantees & Guardrails](/mantle/guarantees).

## 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](/build-guide/sub-skills).
* **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. That offer is the bundled
`default_continue_interrupted` skill — see
[Continue interrupted](/reference/default-skills#continue-interrupted).

<h2 id="what-the-inspector-records">
  What the Inspector records
</h2>

When you [inspect a conversation](/getting-started), Mantle writes explicit
lifecycle events for every skill (including built-in defaults) and for every
authored ordered block:

| 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` |
| An ordered block starts | `ordered_block_entered` |
| The block finishes | `ordered_block_completed` |
| The block is cancelled | `ordered_block_cancelled` |
| Another skill interrupts the block | `ordered_block_interrupted` |
| The paused block continues | `ordered_block_resumed` |

Skill activated and completed carry the skill id only. Ordered-block entered
carries the skill id and the authored block id (for example `submit` — not a compiled
`skill__block` id). Cancel, interrupt, resume, and ordered-block completed
also record the step where that happened. Cancelling a skill produces one
`ordered_block_cancelled` per open block and a single `skill_cancelled` for the
skill.

A skill that is only an ordered block (no surrounding prose) records both
`skill_activated` and `ordered_block_entered` on the same start. Hybrid prose
records `skill_activated` when the skill starts, then `ordered_block_entered`
when that conversation later enters a block — without a second
`skill_activated`. Parking a block still records `skill_interrupted` as well as
`ordered_block_interrupted`.

Inspector draws Block rows only from `ordered_block_*`, with labels such as
`Travel Notice skill / submit block entered`. Skill and block lifecycle is
recorded as `skill_*` and `ordered_block_*`.

Tool invocations persist as `tool_executed` (local Python or MCP, with the
server name when MCP). Memory writes persist as `memory_set` / `memory_cleared`,
which are grouped by Inspector memory panel.

The field-level contract is in the [Execution Loop](/reference/execution-loop#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](/reference/skill-md#jumps-to-blocks-and-skills).

## Next steps

<CardGroup cols={2}>
  <Card title="Skills" icon="cube" href="/skills">
    What a skill is and what goes in it.
  </Card>

  <Card title="Sub-skills & Composition" icon="layers" href="/build-guide/sub-skills">
    Compose focused skills into larger flows.
  </Card>
</CardGroup>


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