Skills & Routing

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’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.

​

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.
• 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, Mantle writes explicit lifecycle events for every skill (including built-in defaults): 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 reference.

​

Structured invocation vs. interruption

These two ways of leaving a skill behave differently, and the difference matters for what you can rely on: 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.

​

Next steps