> 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/flow/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](/flow/help/support-and-troubleshooting.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 Flow Screen Components in a screen flow                    | `avonni-flow-components`       |
| An Avonni Dynamic Component                                       | `avonni-dynamic-components`    |
| Avonni components on a Digital Experience site page               | `avonni-experience-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", "Calendar", "Date Picker". The assistant resolves each name to the right component through the MCP server.

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

> Add an Avonni Kanban of Opportunities grouped by stage to my screen flow, with a card action that opens the record.

> Create a screen flow with an Avonni Calendar showing Events for the current user.

> Add an Avonni Data Table of open Cases with a search bar to my screen.

**What happens:** the `avonni-flow-components` skill activates, looks up each component's real properties and interactions through the MCP server, and adds the configured component to your flow file.
{% endtab %}

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

> Change the Kanban grouping from stage to owner.

> Add pagination to the Data Table on my second screen.

> Set the Date Picker's default value to today.

**What happens:** the skill reads your flow 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, with no extra flow logic.

> Move the user to the next screen when they pick a record.

> Open a confirmation modal before deleting the selected records.

> Fire confetti when the user submits the final screen.

**What happens:** the skill wires the right interaction types (Flow Navigation, Open Confirmation Modal, Fire Confetti) with their settings, and it knows the prerequisites, for example that Fire Confetti requires the Interaction Service component on the same screen.
{% endtab %}

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

> Create a screen flow for booking appointments, and a Dynamic Component with a button that launches it.

This spans two artifact types, so `avonni-architect` activates. It plans the architecture, builds the flow first, then builds the Dynamic Component with its button wired to launch 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 flow file. Review it, deploy it with your usual process, then open the flow in Flow Builder to check the screen and activate it.
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
Nothing is deployed to your org: deployment and activation 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/flow/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.