> 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/dynamic-components/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](/dynamic-components/resources/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           |
| ----------------------------------------------------------------- | ------------------------------ |
| An Avonni Dynamic Component                                       | `avonni-dynamic-components`    |
| Avonni components in LWC code (HTML/JS/CSS)                       | `avonni-lwc-components`        |
| Avonni Flow Screen Components in a screen flow                    | `avonni-flow-components`       |
| Avonni components on a Digital Experience site page               | `avonni-experience-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", "Chat"): the assistant resolves them to the right component through the MCP server.

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

> Create an Avonni Dynamic Component that shows a Kanban of Opportunities grouped by stage, with a card action that opens the record.

> Build a Dynamic Component with a Data Table of open Cases for the current user, with a search bar.

> Create a Dynamic Component that displays a Map of my Accounts.

**What happens:** the `avonni-dynamic-components` skill activates, looks up each component's real properties and interactions through the MCP server, and generates the component's metadata file.
{% endtab %}

{% tab title="✏️ Update an existing one" %}

> Add a search bar and pagination to the case list in my Dynamic Component.

> Change the Kanban grouping from stage to owner.

> Reorder the Data Table columns and hide the Amount column.

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

{% tab title="🎨 Style and branding" %}

> Restyle the Kanban to match our brand colors.

> Round the corners and increase the spacing on the card list.

**What happens:** the skill looks up the component's real styling hooks through the MCP server, so the styling lands on supported hooks instead of guessed CSS.
{% endtab %}

{% tab title="🧩 Use case" %}

> Create a dynamic component with a button that launches a screen flow for booking an appointment.

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 interaction 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, styling hooks, and interactions.
{% 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 the files: Dynamic Component metadata, flow XML, or site content. Review the generated files as you would any code.
{% endstep %}
{% endstepper %}

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