Overview

Connect your AI assistant to the Avonni MCP server and install the Avonni Skills to build and update Dynamic Components from plain-language prompts.

🚧 Early access

Build with AI is rolling out gradually and improving with every release. Something unclear, missing, or broken? Tell us: your feedback directly shapes what we improve next.

Describe what you want in plain language, and your AI assistant (Claude, Cursor, or GitHub Copilot) builds real, working Dynamic Components.

Two tools make that possible:

🧠 Avonni MCP server

A hosted documentation service that gives the assistant accurate, always up-to-date knowledge of every Dynamic Component: properties, interactions, and styling hooks.

🛠️ Avonni Skills

Step-by-step workflows that teach the assistant how to create and update Avonni artifacts, including the Dynamic Component metadata format.

In short: skills tell the agent what to do; the MCP tells it what's true. Using one without the other gives worse results. Install both.

Why you need both

AI assistants are trained on public data, so their knowledge of Avonni is incomplete and out of date. Left on their own, they invent property names, guess at styling hooks, and misunderstand the metadata format. The result looks plausible but doesn't work.

The two tools solve different halves of the problem:

	What it provides	What it fixes
Avonni MCP	Knowledge. Accurate component documentation, styling hooks, and interactions for the dynamic package, plus the lwc, flow, and experience packages.	No more invented properties or styling hooks. The assistant looks up the real API instead of guessing.
Avonni Skills	Process. Workflows for creating and updating each Avonni artifact type, plus avonni-architect, which coordinates multi-artifact use cases.	The assistant follows Avonni's artifact formats and the correct order of operations instead of improvising.

Fast today, maintainable tomorrow

An AI assistant could also build what you're asking for as custom code, fast. The difference shows up after the demo: custom code is yours to maintain forever. Dynamic Components avoid that trap:

✍️ Configuration, not a codebase	A prompt produces a compact metadata file: which components, which data, which interactions. No custom JavaScript to inherit.
🛡️ The complexity is Avonni's to maintain	Data Table, Kanban, Charts, and the rest live in the managed package: tested, versioned, updated with every release. Update the package, and what the AI built keeps working.
🧩 Consistent with everything else	The AI uses the same components as the Dynamic Component builder, so it all looks, behaves, and evolves together.

From a single component to a complete use case

Real requirements rarely stop at one artifact. The avonni-architect skill turns a business outcome into a plan, then invokes the right skills in dependency order so every piece is wired to the others correctly.

Example: "Create a dynamic component with a button that launches a screen flow." The assistant builds both the Dynamic Component and the flow in one pass, with the component's interaction correctly pointing at the flow.

In this section