> For the complete documentation index, see [llms.txt](https://docs.avonnicomponents.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.avonnicomponents.com/experience-cloud/build-with-ai/using-the-ai-assistant.md).

# Using the AI Assistant

{% hint style="warning" %}
🚧 **Early access.** Build with AI is rolling out gradually and improving with every release. Something unclear, missing, or broken? [Tell us](/experience-cloud/help/how-do-i-contact-support.md): your feedback directly shapes what we improve next.
{% endhint %}

You don't invoke skills or MCP tools yourself. Describe the outcome in plain language, and the assistant activates the right skill and looks up real component knowledge through the MCP server.

## The right skill activates for you

| You're working on…                                                | Skill that activates           |
| ----------------------------------------------------------------- | ------------------------------ |
| Avonni components on a Digital Experience site page               | `avonni-experience-components` |
| Avonni Flow Screen Components in a screen flow                    | `avonni-flow-components`       |
| An Avonni Dynamic Component                                       | `avonni-dynamic-components`    |
| Avonni components in LWC code (HTML/JS/CSS)                       | `avonni-lwc-components`        |
| Anything spanning multiple artifact types, or a business use case | `avonni-architect`             |

{% hint style="info" %}
**Rule of thumb:** a single artifact of a known type goes to its specific skill. A request that spans artifact types or describes an end-to-end use case goes to `avonni-architect`. When in doubt, just describe the goal: the skills' activation rules make this decision for you.
{% endhint %}

## Prompt ideas

Copy any of these, adapt the object names to your org, and send. Refer to components by the names used in this documentation: "Data Table", "Kanban", "Gallery", "Banner". The assistant resolves each name to the right component through the MCP server.

{% tabs %}
{% tab title="🆕 Add a component" %}

> Add an Avonni Kanban of Cases grouped by status to my support portal page.

> Add an Avonni Data Table of the customer's open Orders to the account page.

> Add an Avonni Gallery of product images to the home page.

**What happens:** the `avonni-experience-components` skill activates, looks up each component's real properties and interactions through the MCP server, and adds the configured component to your site page. Data visibility still follows your org's sharing rules: portal users only see records they have access to.
{% endtab %}

{% tab title="✏️ Update a page" %}

> Change the Kanban grouping from status to priority.

> Show only open Cases in the Data Table.

> Change the Banner's title and background image.

**What happens:** the skill reads your page's content file, checks the component's options through the MCP server, and applies the change.
{% endtab %}

{% tab title="⚡ Wire interactions" %}
Interactions connect a component event to an action, right from the page.

> Open a screen flow in a dialog when the user clicks the button.

> Navigate to the record page when a row is clicked.

> Let portal users download the attached file.

**What happens:** the skill wires the right interaction types (Open Flow Dialog, Navigate, Download, Show Toast) with their settings, using the real interaction catalog from the MCP server.
{% endtab %}

{% tab title="🧩 Complete use case" %}

> Add a case list to my support portal page, and a screen flow for creating a case that opens from a button.

This spans two artifact types, so `avonni-architect` activates. It plans the architecture, builds the flow first, then adds the components to the page with the button wired to open that flow.

**What happens:** one request, several artifacts, all wired together in dependency order.
{% endtab %}
{% endtabs %}

## What to expect

A typical session runs in three steps:

{% stepper %}
{% step %}

### Lookup

The assistant queries the MCP server for the components involved, with their properties, interactions, and styling options.
{% endstep %}

{% step %}

### Plan

It proposes an approach and may ask clarifying questions. For multi-artifact requests, it lays out the artifacts in dependency order.
{% endstep %}

{% step %}

### Generate

It creates or updates your site page's content file. Review it, deploy it with your usual process, then open the page in Experience Builder to check the result and publish the site.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Nothing is deployed to your org: deployment and publishing stay in your hands. See Limitations & FAQ.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.avonnicomponents.com/experience-cloud/build-with-ai/using-the-ai-assistant.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.