Overview

Connect your AI assistant to the Avonni MCP server and install the Avonni Skills to build and update Avonni Flow Screen 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) adds real, working Avonni components to your screen flows. Two tools make that possible:

🧠 Avonni MCP server

A hosted documentation service that gives the assistant accurate, always up-to-date knowledge of all 75 Flow Screen Components: their properties, interactions, and styling.

🛠️ Avonni Skills

Step-by-step workflows that teach the assistant how to add Avonni components to a screen flow and configure them correctly.

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 interaction types, and produce flow markup that Flow Builder rejects. 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, interactions, and styling for the flow package, plus the dynamic, lwc, and experience packages.	No more invented properties or interaction names. The assistant looks up the real configuration 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 produces valid flow markup and follows the correct order of operations instead of improvising.

Fast today, maintainable tomorrow

An AI assistant could also build your data entry screen as a custom LWC, fast. The difference shows up after the demo: custom code is yours to maintain forever. Flow Screen Components avoid that trap:

✍️ Configuration, not code	A prompt produces screen elements in your flow file: which components, which properties, which interactions. Everything stays declarative, and editable in Flow Builder afterwards.
🛡️ The complexity is Avonni's to maintain	Data Table, Calendar, Lookup, and the other 70+ live in the managed package: tested, versioned, updated with every release. Update the package, and what the AI built keeps working.
🧩 Your admins stay in control	What the AI builds is a normal screen flow, using the same components your team already configures by hand. Anyone can open it, understand it, and evolve it.

What the assistant produces

The avonni-flow-components skill works on your flow file. It adds the Avonni component to a screen element and configures its properties, data, and interactions. Nothing is deployed: you review the file, deploy it with your usual process, then open the flow in Flow Builder to check the screen and activate it.

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 screen flow for booking appointments, and a Dynamic Component with a button that launches it." The architect builds the flow first, then the Dynamic Component with its button wired to launch that flow.

Set it up in minutes

In this section