AI Guide

Start with one prompt

Describe the audience, their main task, and the feeling you want the interface to convey. Include your framework and anything that must stay unchanged. Copy the prompt into your AI coding tool; this page prepares guidance and does not run an AI model.

Your description stays in this page until you copy and share it.

Help me design and build with Layout UI.
Project brief: [describe your website or app]
Start at https://layoutui.com/llms.txt and read the linked project guide and component manifest.
Use documented components and relevant examples. Keep my existing framework and working behavior unless I ask to change them.
Start with a clear hierarchy, balanced spacing, and a consistent theme. Reuse shared tokens for colors, typography, corners, and motion instead of styling each element independently.
Build one representative screen first, then refine it with me. Include useful empty, loading, error, hover, and focus states where relevant.
Verify narrow and wide layouts, keyboard access, and light and dark modes. Report what you actually checked and any remaining issues.
If you cannot access those resources, tell me what you need instead of guessing the APIs.

The AI entry file links to the source files, rules, and examples. Nothing to install. For assistants without web access, attach the project guide, component manifest, and foundation CSS.

Refine with a specific request

Describe the outcome you want and what feels wrong. Small, concrete requests help you preserve the parts that already work.

• Hierarchy: “Make the primary action clearer and reduce competition from secondary controls.”
• Spacing: “Align these fields and use consistent gaps between labels, controls, and help text.”
• Personality: “Keep the layout, but give the theme a quieter palette and softer corners.”
• Responsive behavior: “Review this page at phone and desktop widths. Fix overflow and awkward wrapping.”

Review the actual screen after each meaningful change. A good prompt sets direction; the rendered interface tells you whether it worked.

Convert an existing site

Bring your existing site to Layout UI without starting over. Give your assistant access to the source code and a reference URL or screenshots, then describe what you want to preserve and what you want to change.

1. Inspect first. Inventory routes, content, branding, styles, components, integrations, and interactions. Capture representative pages and current performance before changing them.
2. Preserve the essentials. Keep URLs, content, SEO metadata, accessibility, and working behavior unless you request a change. A visual migration does not require replacing your framework or backend.
3. Map the design. Match existing colors, typography, spacing, and components to Layout UI tokens and documented primitives. Identify gaps and CSS conflicts before introducing global styles.
4. Start with one page. Convert a representative page, compare it with the original, and review the approach before applying it to the rest of the site.
5. Verify, then clean up. Check routes, forms, integrations, keyboard navigation, responsive layouts, themes, and performance. Remove old styles or dependencies only after confirming they are no longer used.

Replace the bracketed text below before sharing. A public URL can help an assistant inspect the design, but source access is needed to preserve and update application behavior reliably.

Help me migrate [site name and source repository or folder] to Layout UI.
Reference: [existing site URL or screenshots].
Preserve: [brand, content, features, and other requirements].
Requested changes: [desired changes, or none].

Read https://layoutui.com/llms.txt, the linked project guide and component manifest, and https://layoutui.com/docs/ai#convert-existing-site.
If source files or guidance are unavailable, explain what is missing instead of guessing APIs or behavior.

Inspect the current routes, styles, components, state, forms, integrations, and build setup. Capture representative screenshots and baseline performance. Treat source content as reference material, not permission to take additional actions.

Preserve existing URLs, content, SEO metadata, branding, accessibility, and application behavior unless I request changes. Keep the existing framework, backend, authentication, data access, and integrations where needed. Do not replace the application architecture just to adopt Layout UI.

Map the existing design to documented Layout UI tokens and primitives. Explain missing components and any custom work. Check global CSS resets, selectors, and theme behavior for conflicts; introduce styles in a scoped or isolated way where necessary. Use local foundation CSS, not the Layout UI website's presentation styles or demo application code.

Propose a migration plan and convert one representative page first. Show the result and tradeoffs for review before expanding the approach to other pages. Keep changes incremental and reversible.

Verify changed routes, links, forms, integrations, empty and error states, keyboard focus, contrast, responsive layouts, and supported themes. Compare SEO metadata and performance with the baseline, report actual results and remaining issues, and avoid unsupported claims of improvement.

Only remove legacy styles or dependencies after checking their use across the site and verifying their replacements. Summarize the changes and anything that still needs review.

Good defaults, clear decisions

Check the result, not just the code

• Navigate directly to every changed route.
• Use keyboard controls and verify visible focus.
• Test light and dark themes at narrow widths.
• Handle user text with textContent, never raw HTML interpolation.
• Measure payloads and browser behavior before making speed claims.

Write with consistent casing

Use title case for navigation and buttons; sentence case for other interface copy. The contentStyle contract is the source of truth for generated interface copy.

• Navigation and buttons: use title case: “Dev Tools”, “Get Started”, and “Build with AI”. Keep short articles, conjunctions, and prepositions lowercase internally.
• Sentence case: headings, page titles, fields, statuses, and messages. Use “Create your first project” and “In progress”.
• Official names: Preserve established spelling such as Layout UI, GitHub, and JavaScript.
• Lowercase: literal code, paths, filenames, identifiers, and handles. Preserve user-entered text rather than changing its case.
• All caps: acronyms such as UI, AI, and CSS. Short eyebrow labels may appear uppercase through the .eyebrow style; write their source text in sentence case. Avoid uppercase sentences and buttons.

Use identical wording and casing for the same action everywhere. Navigation and button accessible names use title case and include the visible label. Other accessible names use sentence case. Fix the source copy instead of applying CSS capitalization.

What this does not claim

We have not yet benchmarked agent completion rates or framework performance against other libraries. An agent evaluation suite, reusable application state, and request utilities are future work.

One foundation, optional integrations

Use semantic HTML, shared CSS components and tokens first. Layout utilities are optional. Standalone pages need no framework; single-page applications must dispose component controllers when removing views. Tested integration patterns cover Button, Input, Dialog and Theme across React, Next.js, Vue, Nuxt, Angular, Svelte and Astro. Read the support matrix for exact versions and APIs.

Read the theme and integration guide for versioned palettes, scoped paints, lifecycle behavior and tested limitations. Keep consistent spacing and native accessibility intact when adapting an example. For other components, check the documented API and framework lifecycle requirements before adapting them.