> For the complete documentation index, see [llms.txt](https://help.usejimo.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.usejimo.com/docs/experiences/agent/skills.md).
# Skills
Reusable, step-by-step procedures your Agent can run on your product: guide users, take actions, or explain how things work.
***
**Dashboard path:** [Agent > Train > Skills](https://i.usejimo.com/agent/skills)
A Skill teaches the Agent **how to get something done** in your product. Where [Knowledge](/docs/experiences/agent/knowledge.md) makes the Agent able to explain, Skills make it able to act: walk a user through a flow, execute the flow itself, or build a precise answer from the page and your sources.
### The three types of Skills
| Type | Short label | Who is in control | What happens |
| ---------------------------- | ----------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Execute a flow** | Execute | The Agent | It clicks and fills on behalf of the user. Steps that send, pay, delete or change permissions are handed back to the user. |
| **Guide user in a flow** | Guidance | The user | It puts a cursor and a tooltip on one control at a time and waits for the user to act. It never clicks for them. |
| **Answer complex questions** | Explain | Conversation only | It answers in text, reading the page when the eye is on, using the elements you selected and your sources. No interaction with the page. \| |
In page panels, the type shows under each Skill's name as **Execute Skill**, **Guide Skill** or **Explain Skill**; Guide and Guidance name the same type.
Execute and Guidance share the same structure: a flow of steps on the page's elements. The only difference is whether the flow progresses automatically or waits for the user, which is why a Skill can [switch between these two modes](/docs/experiences/agent/skills/create-a-skill.md) after creation. Explain is a different construction: no flow, an answer framed around the elements you select.
The right type is a trust decision as much as a capability one. **Execute** fits repetitive, low-risk tasks (create a report, apply a filter set). **Guide** fits anything the user should learn or where a wrong click matters. **Answer** fits questions whose answer depends on what is on screen, without needing to touch it.
{% hint style="info" %}
#### **Skills replaced Tours and Actions in the Agent (****since September 2026****)**
* A **Guidance** Skill replaces a Tour connected to the Agent: a walkthrough built on the fly, AI-assisted, on the scanned page.
* An **Execute** Skill replaces a No-Code Action in conversations: same construction as Guidance, but the flow runs on its own.
* An **Explain** Skill covers what Custom Answers could not: instead of a fixed Q\&A pair, it frames a topic around a specific interface. \
\
Custom Answers stay: they are the right tool for wording you must control word for word, and the only way to launch an existing experience from the chat.
Your Tours and Actions still exist as experiences and can be launched from CTAs and triggers. They are simply no longer triggered directly from the chat.
{% endhint %}
### The Skills list
Two cards sit at the top of the page: **Skill usage**, the number of runs over the last 30 days with its variation, and **Completion rate**, week by week.
Below, every Skill in the project appears in one table:
| Column | What it tells you |
| ------------------- | ------------------------------------------------------------------------------------------------- |
| **Name** | The Skill's name, with the first line of its description underneath. |
| **Last updated** | When the Skill was last edited. |
| **Usage** | How many times it ran. |
| **Completion rate** | Share of runs that reached the end of the flow. A Skill that has never run shows **No runs yet**. |
**Search skills**, a sort selector and an **All Skills** filter narrow the list. **Add Skill**, top-right, opens the creation flow.
### Where Skills live
Skills exist in two views of the same thing:
* **This page** lists every Skill in the project.
* **Each scanned page** shows its own Skills in the [Page details](/docs/experiences/agent/knowledge/interface/page-details.md) panel, because a Skill runs on the elements of a page. The Interface list even shows a Skills counter per page.
That link is why scanning comes first: a Skill can only click, fill or reference what the Agent can [read](/docs/experiences/agent/knowledge/interface.md#two-ways-the-agent-can-learn-a-page).
### What a Skill is made of
Click a Skill, from this list or from a page's panel, to open it. Its panel has two tabs, **Usage** and **Settings**, an **Active** toggle in the header, and a menu with **Delete**.
The **Settings** tab holds the three things that define the Skill:
* **Description for the agent**: what the Skill covers, and above all *when* the Agent should use it. This is what decides whether the Skill fires on a given question, so it is written around the questions users actually ask.
* **Instructions for the agent**: the goal, the **inputs needed from the user**, and the numbered steps the Agent follows.
* **Mode**: the type, switchable after creation.
The **Active** toggle controls whether *end users can trigger it*. A Skill stays invisible to your users until you turn it on, so you can draft and test it in peace. **Try this skill** runs it in a test chat on the real page.
{% hint style="warning" %}
**The description does the routing.** Two Skills with vague, overlapping descriptions will compete for the same questions. Write each one around a distinct user intent, in the words users use.
{% endhint %}
### How a Skill is offered and started
A Skill never starts by itself. When a user's message matches one, the Agent offers it, and the user confirms.
1. **The user asks.** The Agent compares the message with every active Skill: its name, its description and the start of its instructions. Those are the only trigger phrases; the recorded steps and the page itself are not searched.
2. **The Agent offers.** With the eye on, a clearly matching Guide or Execute Skill comes back as a short answer and a **Start** button. When several Skills could fit, the Agent decides, usually a text answer with a button for the best one.
3. **The user confirms.** On tap, or on a "yes", the Skill starts. An Execute Skill first asks for any missing values in a form.
4. **The Skill runs on what the Agent can see.** A Guide points at the elements kept on the scanned page (or anything visible on a Read all page). If the user is on another page, or the target was hidden in curation, the Agent tries, then asks the user in text to open the right page.
| Skill matched | Eye | What the user gets |
| ------------------------ | --- | ----------------------------------------------------------------------------------------- |
| None | Any | A text answer. Outside a running Skill, the Agent cannot point at or touch the page. |
| Answer complex questions | Any | A text answer, after reading the page when the eye is on. |
| Guide or Execute | Off | The steps described in text, plus an invitation to turn on the eye. No button. |
| Guide or Execute | On | A short answer and a Start button. On confirmation, the on-screen guide or the execution. |
{% hint style="warning" %}
**Guide and Execute Skills need the eye on.** The eye is off by default for every end user, and only the user can switch it on, from the chat widget. With the eye off, the Agent receives the page URL only, so it can describe a Skill but not run it. See [the eye](/docs/experiences/agent.md#the-eye-letting-the-agent-see-the-page).
{% endhint %}
{% hint style="info" %}
**The dashboard test chat always behaves as eye on.** Test Knowledge and Try this skill show you what a user with the eye on gets. A user with the eye off gets the text version. To see what most of your users see, test live in your product, in a new chat, and compare both states.
{% endhint %}
Starting a Skill costs one Agent request on top of the message itself. "Show me", "guide me" or "walk me through" in the user's message push the Agent toward offering a Skill, but it is the matched Skill that decides.
#### **Why phrasing changes the result**
The Agent first reads the message as a task and labels it a question or an instruction. "How do I create a service?" is a question, answered from your knowledge; "Create a service" is an instruction, which is where Skills get offered. One word more or less can move a message from one side to the other, and the Agent is not fully deterministic: the same message can be handled slightly differently twice. Writing Skills in the users' language matters too: a French question against an English-only Skill scores lower.
#### **What you can do to make the right Skill fire**
* **Open each description with the exact object and action.** "Create a service (prestation) in Services and Products", never "Helps with…". The Agent reads the name and the first lines of the description first.
* **Write the name, description and first instructions in your users' language**, or in both languages. They are the only trigger phrases.
* **Merge or deactivate overlapping Skills.** Two Skills that both say "create" compete; when only one "create" Skill exists, it may get offered for the wrong object. Inactive Skills are never matched.
* **Cover near misses.** One Skill per common object, or a [Custom Answer](/docs/experiences/agent/knowledge/custom-answers.md) stating what the product does not do.
* **Keep the active list focused.** Above 40 active Skills, the Agent stops reading the Skill cards up front and relies on search alone.
* **Configure** [**Escalation**](/docs/experiences/agent/escalation.md) so an uncovered question becomes a hand-off instead of a guess.
### How a Skill performs
The **Usage** tab of a Skill is where its own numbers live: **Usage** over a period you choose, a chart of runs over time, and the **conversations** where the Skill fired, filterable by response. Flow Skills (Execute and Guidance) add a **Completed** counter with its rate; an Explain Skill has nothing to complete, so it only counts usage.
{% hint style="info" %}
#### **Skill statistics and Analyze are two different reads.**
[Analyze](/docs/experiences/agent/analyze.md) covers **every** conversation the Agent had, at project level.
It does not break them down by Skill or by scanned page: each Skill, and each Skill attached to a page in [Interface](/docs/experiences/agent/knowledge/interface.md), keeps its own Usage tab, and that is where the link to the conversations it drove is made.
Neither view shows *which* Skill or source a given answer used. If a Skill was offered where it should not have been, note the conversation, the exact message and whether the eye was on: the Jimo team can retrieve the routing of that turn.
{% endhint %}
A Guide Skill answered in text instead of guiding. Why?
1. Was the eye on? The dashboard test chat hides this, since it always behaves as eye on.
2. Did the user tap Start, or say yes to the offer?
3. Is the page scanned, with the Skill's target elements kept, or set to Read all?
4. Is the Skill a Guide or Execute Skill, not Answer complex questions?
5. Does your app register its own tools through the SDK? They take priority over Skills.
6. Did an escalation trigger fire first?
### Creating one
**Add Skill** opens the creation flow, with two methods: describe it in words, or do the task once and let the Agent capture it. See [Create a skill](/docs/experiences/agent/skills/create-a-skill.md).
### Related pages
* [Create a skill](/docs/experiences/agent/skills/create-a-skill.md): Describe it, or Show me
* [Interface](/docs/experiences/agent/knowledge/interface.md): the pages Skills run on
* [Knowledge](/docs/experiences/agent/knowledge.md): the four kinds of Agent knowledge
* [Agent](/docs/experiences/agent.md): what the Agent can do today, and the eye
* [Escalation](/docs/experiences/agent/escalation.md): what happens when no Skill or source can answer
* [Analyze](/docs/experiences/agent/analyze.md): every conversation the Agent had, at project level
