Skip to content
Flow Like logo Flow Like Docs

FlowPilot UI Generation

FlowPilot can create a new A2UI page or widget and modify the interface currently open in the builder. It uses the live component catalog and current surface state, validates the generated component tree, and stages the result for review.

For workflow, data, provider, approval, and global-assistant features, see the main FlowPilot guide.

What it can generate

Section titled “What it can generate”

FlowPilot UI generation supports:

  • Complete pages and one-off layouts
  • Reusable widgets for repeated or dynamic elements
  • Changes scoped to selected components
  • Responsive, mobile-first layouts
  • Theme-aware Tailwind classes and canvas settings
  • Custom CSS for effects that need more than standard classes
  • Literal values and JSON-path data bindings
  • Forms, navigation, tables, charts, lists, and other documented A2UI components

FlowPilot generates a complete component tree rather than editing application source files. The available elements and properties are defined by the A2UI component reference.

Open the right surface

Section titled “Open the right surface”

There are two current ways to request UI work:

  • From a page or widget builder: Open FlowPilot in the builder. It receives the existing component tree and any selected component IDs, so prompts such as "make this card more compact" refer to the visible surface.
  • From global FlowPilot: Ask it to create a page in an app or edit the builder you currently have open. The global assistant delegates the request to its UI specialist and opens the resulting builder for review.

Selecting one or more components before opening FlowPilot is the most reliable way to target a local change. You can also attach a reference image or include a builder screenshot where that control is available.

Generate, review, and apply

Section titled “Generate, review, and apply”
  1. Describe the complete layout, content, data, and important states.
  2. FlowPilot generates and validates the A2UI component tree.
  3. Review the rendered preview, component list, and any reported auto-fixes.
  4. Select Apply to replace the current generated surface, or dismiss the review to leave it unchanged.
  5. Continue the conversation to refine the applied design.

With Auto mode enabled, a completed UI review is applied automatically after generation. Keep Auto mode off when you want to inspect every preview first.

Prompt examples

Section titled “Prompt examples”

Create a page

Section titled “Create a page”
Create a responsive customer dashboard with:
- a compact mobile header and desktop sidebar
- four summary cards
- a revenue line chart bound to $.data.revenue
- a recent-orders table bound to $.data.orders
- loading, empty, and error states

Modify selected components

Section titled “Modify selected components”

Select the relevant components, then ask:

Turn the selected section into a two-column layout on desktop,
keep it stacked on mobile, and make the primary action more prominent.

Create a reusable widget

Section titled “Create a reusable widget”
Create a reusable project-card widget for the projects grid.
Each instance should bind its title, owner, status, and progress
from the current list item. Expose the accent style as a widget property.

Bind data

Section titled “Bind data”
Create an invoice table bound to $.data.invoices.
Show customer, due date, total, and status. Add an empty state and
use a destructive status style only when an invoice is overdue.

UI versus workflow behavior

Section titled “UI versus workflow behavior”

The UI specialist owns the page, widget, components, styling, and bindings. It does not build the workflow that fetches data or handles actions.

If the page also needs behavior, ask global FlowPilot for both parts in one outcome-oriented prompt. It can coordinate the UI specialist with the board specialist, create or update the necessary App Event, and connect page-load behavior. For example:

Build a customer dashboard and the workflow that loads its chart and table data.
Expose it as a page event and include useful error handling.

Prompting tips

Section titled “Prompting tips”
  • Describe hierarchy and responsive behavior, not just visual style.
  • Name the data paths the interface should use.
  • Include loading, empty, error, disabled, and validation states when relevant.
  • Ask for a widget when an element is genuinely reused or repeated from data.
  • Reference the selected component for a focused edit.
  • Review generated bindings and interactions with representative data before release.
Section titled “Related guides”