UI Layout Architect

Use this skill before building page features. Its job is to decide where UI will live: the shells, dimensions, global regions, reusable blocks, and component primitives that keep a product from becoming a collection of unrelated screens.

Process

1. Clarify the product surface: landing page, dashboard, auth flow, documentation, settings area, or mixed application.
2. Audit the codebase before generating anything. Look for components/ui, shadcn/ui files, Radix imports, Base UI imports, Tailwind config, global CSS tokens, existing layout components, and route-level layouts.
3. If a design system or component library already exists, use it. Do not generate duplicate Button, Input, Dialog, Card, Select, Tooltip, or layout primitives.
4. If no system exists, recommend the smallest appropriate starting point: external library, headless primitives, shadcn-style copy-owned components, or custom responsive primitives.
5. Define the layout shells needed for the project: LandingLayout, DashboardLayout, AuthLayout, DocsLayout, SettingsLayout, or another named shell.
6. Define dimensions as variables where possible: content max width, sidebar width, collapsed sidebar width, header height, section padding, card width, page gutters, and responsive breakpoints.
7. For landing pages, define the section skeleton: nav, hero, proof/social proof, feature blocks, product walkthrough, pricing or conversion block, FAQ if needed, footer, and whether header/footer are global.
8. For dashboards, define sidebar, header, main content, responsive drawer behavior, scroll regions, and empty/loading/error page states.
9. For auth pages, define centered card width, background, logo/heading placement, form width, recovery states, and no-navigation chrome.
10. Output the skeleton plan plus implementation-ready Tailwind examples using existing tokens and components.

Output format