Skip to main content

Build with a coding agent

ZUI has two AI workflows. Choose the one you actually need:

GoalStart here
Ask Codex, Claude Code, or another coding agent to add ZUI to your repositoryUse a focused development prompt from this page.
Let people generate or edit views inside your productUse registryPrompt, JSON Schema, validation, and patches from AI generation and editing.
Put an assistant, tool calls, approvals, or citations inside your productUse the AI interface components.

These are complementary, but they solve different problems.

Give the agent focused context

For the first analytics screen, open or download /prompts/analytics-view.md. Replace the bracketed business question and data contract, then give the complete prompt to the agent inside your repository.

The prompt requires the agent to:

  • inspect and preserve your existing application conventions;
  • use only APIs that ZUI currently exports;
  • choose a front-end- or backend-owned dataset contract and keep it in source-controlled code;
  • keep fetching, credentials, authoritative access control, routing, and side effects in host code;
  • distinguish automatic client-side filtering from server filtering through onFiltersChange, serverDatasetNames, and onDataRequest;
  • connect filters, metrics, charts, and the grid through one dataset;
  • validate the ViewSpec; and
  • run your repository's checks before returning the work.

Point the agent at https://zuilib.com/llms.txt when it needs to discover the wider library. Use llms-full.txt only when it needs detailed component APIs; the focused task prompt should remain the primary instruction.

Useful follow-up prompts

Add a domain component

Add our existing [COMPONENT NAME] to the ZUI view registry as a domain view
type. Reuse the component without rewriting it. Describe every supported prop
with defineViewType so the renderer, inspector, validator, and registryPrompt
all receive the same contract. Include one small canonical example node and a
test that validates it inside a ViewSpec.

Make an analytics view operational

Extend this ZUI analytics view with the smallest useful operational workflow.
Register workflowViewTypes from @zuilib/workflows/view-types, declare named
actions and policies, and keep their executable handlers in host code. Add no
new application platform unless the workflow requires it. Validate the final
view and identify every backend callback that remains for the team to connect.

Make an existing view customizable

Wrap this ViewSpec in the ZUI view editing flow. Preserve the base spec and
store user changes as ViewPatch operations. Wire preview, apply, undo, and
discard behavior. If AI editing is included, use editPrompt and
patchJsonSchema, validate proposed patches before apply, and never regenerate
the whole view for a local change.

Generate views inside your product

The runtime path uses your actual registry as model context:

import {
parseViewSpec,
registryPrompt,
validateViewSpec,
viewJsonSchema,
} from '@zuilib/apps'

const system = registryPrompt(registry, {
datasets: [accountsSchema],
actions,
footer: [
'## Assignment',
'Create a renewal-risk analytics view for customer-success leaders.',
'Start with filters, then 2–4 KPIs, one useful chart, and a data grid.',
'Return exactly one ViewSpec JSON object.',
].join('\n'),
})

const outputSchema = viewJsonSchema(registry)

export function acceptGeneratedView(modelText: string) {
const spec = parseViewSpec(modelText)
const issues = validateViewSpec(spec, registry, {
datasets: [accountsSchema],
actions,
})

if (issues.some((issue) => issue.severity === 'error')) {
throw new Error(JSON.stringify(issues, null, 2))
}

return spec
}

Prompt, structured-output schema, validator, editor, and renderer all derive from the same registry. The model can bind only the data you declare and compose only components the application can render.

For incremental changes, use editPrompt and patchJsonSchema. Human and AI edits then share one reviewable, undoable patch history.

Next