AI Design System Prompt Architect for Web UI

Project name: NovaPilot AI Workspace

Product type: Multi-tenant B2B AI automation SaaS platform

Target users: Operations managers Marketing teams Customer success teams Agency teams Startup founders

Primary user roles: Workspace Administrator Automation Builder Reviewer Team Member Executive Viewer

Core user jobs: Create AI-powered workflows Connect business tools Review generated outputs Approve or reject high-risk actions Monitor workflow performance Investigate failures Manage team access Track usage and plan limits

Business model: Subscription SaaS with multiple plans and usage-based limits

Product maturity: MVP moving toward commercial launch

Brand attributes: Intelligent Calm Precise Premium Trustworthy Efficient

Brand personality: Professional and technologically advanced without appearing cold, intimidating, excessively futuristic, or visually noisy

Desired visual direction: Premium AI operations workspace Dark graphite foundation Deep indigo surfaces Electric blue primary actions Restrained cyan accents High-contrast typography Controlled glass effects Subtle depth Implementation-believable components

Avoided visual styles: Excessive neon Heavy glassmorphism Random gradients Overly playful illustration Generic cryptocurrency styling Dense cyberpunk aesthetics Unrelated 3D objects Decorative charts Inconsistent card designs

Primary theme: Dark primary theme Light theme also required

Accent colors: Electric blue Cyan Deep indigo

Typography preference: Modern geometric sans-serif Readable at high data density Clear numeric forms Strong support for international characters

Data density: Mixed Comfortable default mode Compact mode for operational tables

Required components: Button Icon Button Link Card KPI Card Chart Card Form Field Text Field Text Area Select Combobox Checkbox Radio Group Switch Date Picker Search Field File Upload Sidebar Top Bar Breadcrumbs Tabs Pagination Command Palette Data Table Data Grid Status Badge Avatar Alert Toast Progress Skeleton Empty State Error State Permission State Modal Drawer Popover Tooltip Dropdown Menu Accordion Step Indicator Pricing Card

Required product patterns: Application shell Workspace switcher Workflow builder Human review queue Filter toolbar Bulk actions Activity feed Usage panel Integration status Onboarding checklist Settings sections Billing selector Permission gate Upgrade flow File upload workflow AI generation status

Required dashboard layouts: Executive overview AI operations dashboard Workflow performance dashboard Usage dashboard Admin dashboard

Required landing-page sections: Header Hero Trust section Problem Product demonstration Feature system Use cases Workflow explanation Security and control Testimonials with verified placeholders Pricing FAQ Final CTA Footer

Responsive targets: Wide desktop Desktop Laptop Tablet Mobile Portrait and landscape

Accessibility target: WCAG 2.2 AA implementation review

Frontend stack: Next.js React TypeScript

Styling system: Tailwind CSS Semantic CSS variables

Component foundation: shadcn/ui Radix UI

Design tool: Figma

Documentation environment: Storybook Markdown documentation

Localization: English initially Future Spanish, German, and French Allow at least 30% text expansion Future RTL support

Browser support: Current and previous major versions of Chrome, Safari, Firefox, and Edge

Need AI image prompts: Yes

Need Figma guidance: Yes

Need frontend guidance: Yes

Need JSON output: Yes

Need variations: Three controlled visual directions: Conservative Enterprise Premium AI Operations Innovative Intelligent Workspace

Special constraints: Do not copy proprietary design systems. Do not invent licenses. Do not use customer data. Do not use fake logos or testimonials. Use semantic tokens. Control component variants. Include loading, empty, error, success, permission, offline, and plan-limit states. Define light and dark themes. Preserve keyboard access and visible focus. Avoid untested accessibility or compatibility claims.

=== AI DESIGN SYSTEM FOR WEB UI ===

Project: NovaPilot AI Workspace

Product Category: Multi-tenant B2B AI automation SaaS

Primary Users: Operations managers, marketing teams, customer success teams, agencies, and startup teams

Primary Product Jobs:

• Build AI workflows
• Connect business systems
• Review AI outputs
• Approve high-risk actions
• Monitor workflow health
• Investigate failures
• Manage permissions
• Track usage

=== EXECUTIVE SUMMARY ===

NovaPilot requires a coherent product system that communicates intelligence and technical capability without creating visual noise or operational ambiguity.

The recommended system should combine:

• Dark graphite foundations
• Deep indigo working surfaces
• Electric-blue primary actions
• Restrained cyan accents
• High-contrast typography
• Semantic status colors
• Medium corner radii
• Subtle borders
• Limited elevation
• Restrained glass effects
• Clear data hierarchy
• Accessible focus
• Predictable interaction behavior

The system should be structured in six layers:

1. Product and brand principles
2. Foundations and tokens
3. Layout primitives
4. Reusable components
5. Product patterns
6. Page templates

=== BRAND ATTRIBUTES ===

Intelligent: The interface should reveal useful context and next actions without appearing mysterious.

Calm: System states, alerts, and AI activity should remain understandable without excessive motion or visual urgency.

Precise: Data, status, permissions, and operational actions should use consistent alignment, labels, and state communication.

Premium: Typography, spacing, surfaces, and motion should feel refined but restrained.

Trustworthy: Risk, confidence, permissions, automation status, and human review should remain visible and explainable.

Efficient: Frequent actions should be direct, predictable, and reusable across screens.

=== DESIGN PRINCIPLES ===

Principle 1: Clarity Before Intelligence Theater

Meaning: AI capability should be demonstrated through useful workflows rather than decorative futuristic effects.

Application: Show status, confidence, review requirements, sources, and outputs clearly.

Anti-Pattern: Excessive glow, abstract AI symbols, and unexplained automation.

Principle 2: Exceptions Deserve Priority

Meaning: Failures, review requests, usage limits, and permission problems should be visible and actionable.

Application: Use operational queues, alerts, and explicit recovery states.

Anti-Pattern: Hiding exceptions beneath decorative analytics.

Principle 3: Semantic Tokens Before Raw Styling

Meaning: Components should use purpose-based tokens.

Application: Use color.action.primary instead of raw electric-blue values.

Anti-Pattern: Hard-coded visual values across screens.

Principle 4: Accessibility Is Part of the Component Contract

Meaning: Every interactive component must define semantics, keyboard behavior, focus, states, and error recovery.

Principle 5: One System Across Product and Marketing

Meaning: The application and landing page may use different compositions but should preserve the same brand foundations.

=== VISUAL DIRECTION ===

Direction Name: Premium AI Operations

Page Background: Deep graphite

Primary Surface: Dark neutral with restrained indigo influence

Elevated Surface: Deep indigo panel

Primary Action: Electric blue

Secondary Accent: Cyan

Typography: High-contrast modern geometric sans-serif

Borders: Subtle cool-gray and indigo borders

Radii: Medium and consistent

Elevation: Restricted to overlays, sticky surfaces, and high-priority cards

Glass: Limited to selected floating overlays and hero visuals

Charts: High-contrast, restrained, non-decorative

Motion: Short, purposeful, explainable

Avoid:

• Neon cyberpunk appearance
• Uncontrolled glow
• Excessive transparency
• Random gradients
• Decorative charts
• Inconsistent cards
• Mixed icon families
• Unreadable microtext

=== TOKEN ARCHITECTURE ===

Primitive Tokens:

• Raw colors
• Spacing values
• Font values
• Radius values
• Shadow values
• Motion values
• Breakpoint values

Semantic Tokens:

• Background
• Surface
• Text
• Border
• Action
• Focus
• Feedback
• Status
• Overlay
• Disabled

Component Tokens: Use only when a shared component requires a stable exception.

Example Relationship:

Primitive: color.blue.600

Semantic: color.action.primary

Component: button.primary.background.default

=== PRIMITIVE COLOR TOKENS ===

Neutral:

• neutral.0
• neutral.50
• neutral.100
• neutral.200
• neutral.300
• neutral.400
• neutral.500
• neutral.600
• neutral.700
• neutral.800
• neutral.900
• neutral.950

Indigo:

• indigo.100 through indigo.900

Blue:

• blue.100 through blue.900

Cyan:

• cyan.100 through cyan.900

Feedback:

• green scale
• amber scale
• red scale
• informational blue scale

Exact values require contrast validation in both themes.

=== SEMANTIC COLOR TOKENS ===

Background:

• color.background.page
• color.background.surface
• color.background.elevated
• color.background.subtle
• color.background.inverse

Text:

• color.text.primary
• color.text.secondary
• color.text.muted
• color.text.disabled
• color.text.inverse
• color.text.link

Border:

• color.border.default
• color.border.subtle
• color.border.strong
• color.border.focus
• color.border.error

Action:

• color.action.primary
• color.action.primary-hover
• color.action.primary-pressed
• color.action.secondary
• color.action.destructive

Feedback:

• color.feedback.success
• color.feedback.warning
• color.feedback.error
• color.feedback.info
• color.feedback.neutral

AI Status:

• color.ai.running
• color.ai.review-required
• color.ai.failed
• color.ai.paused
• color.ai.complete

AI statuses must remain understandable without color alone.

=== THEME ARCHITECTURE ===

Dark Theme: Primary operational theme

Light Theme: Required for customer preference, print-oriented contexts, and selected marketing use

Theme Rules:

• Preserve semantic token names.
• Validate each theme independently.
• Do not mechanically invert every color.
• Preserve hierarchy.
• Preserve visible focus.
• Preserve status meaning.
• Tune shadows independently.
• Validate charts independently.

=== TYPOGRAPHY SYSTEM ===

Display: Marketing and launch surfaces only

Heading 1: Page title and major landing-page sections

Heading 2: Primary product sections

Heading 3: Cards, panels, and grouped content

Body Large: Introductory explanations

Body: Default application text

Body Small: Secondary descriptions

Label: Form fields and controls

Caption: Metadata

Data Value: KPIs and operational metrics

Table Header: Column headings

Code: Workflow payloads, identifiers, and technical values

Typography Rules:

• Use readable body sizes.
• Preserve line height.
• Use tabular numeric forms where useful.
• Avoid tiny secondary text.
• Support text expansion.
• Limit font families.
• Verify font licenses.

=== SPACING SYSTEM ===

Base Scale: 4-pixel system

Primitive Tokens:

• space.0 = 0
• space.1 = 4
• space.2 = 8
• space.3 = 12
• space.4 = 16
• space.5 = 20
• space.6 = 24
• space.8 = 32
• space.10 = 40
• space.12 = 48
• space.16 = 64
• space.20 = 80
• space.24 = 96

Semantic Spacing:

• spacing.page.inline
• spacing.page.block
• spacing.section
• spacing.card
• spacing.panel
• spacing.form.field
• spacing.control.inline
• spacing.table.cell
• spacing.modal
• spacing.navigation
• spacing.hero

=== DENSITY MODES ===

Comfortable: Default for most screens

Compact: Tables, operational queues, and high-density administrative workflows

Spacious: Marketing pages, onboarding, and selected executive views

Accessibility Rule: Compact mode must preserve usable targets, readable text, visible focus, and sufficient control separation.

=== RADIUS SYSTEM ===

• radius.none
• radius.small
• radius.control
• radius.card
• radius.panel
• radius.round

Recommended Usage:

• Controls: radius.control
• Cards: radius.card
• Large panels: radius.panel
• Pills and circular controls: radius.round

Avoid: Unique radius values for individual pages.

=== ELEVATION SYSTEM ===

Elevation 0: Flat application surfaces

Elevation 1: Cards and low-priority panels

Elevation 2: Sticky surfaces, dropdowns, and popovers

Elevation 3: Drawers and modals

Elevation 4: Critical temporary overlays only

Rules:

• Elevation must communicate layering.
• Borders may replace shadows.
• Dark-theme shadows require dedicated tuning.
• Avoid making every card appear floating.

=== MOTION SYSTEM ===

Durations:

• motion.duration.instant
• motion.duration.fast
• motion.duration.normal
• motion.duration.slow

Easing:

• motion.easing.standard
• motion.easing.enter
• motion.easing.exit

Use Cases:

• Component state change
• Overlay entrance and exit
• Workflow progress
• Feedback
• Spatial continuity

Reduced Motion: Remove nonessential spatial movement and preserve all information.

=== BREAKPOINT SYSTEM ===

Small: 0–639 px

Medium: 640–1023 px

Large: 1024–1439 px

Extra Large: 1440 px and above

Rule: These values are a starting model. Final transitions should be validated against content pressure, shell behavior, tables, navigation, and component minimum widths.

=== LAYOUT PRIMITIVES ===

Container: Controls maximum width and page gutters.

Stack: Controls vertical layout and spacing.

Inline: Controls horizontal groups with wrapping.

Grid: Controls repeated responsive modules.

Split: Controls two-region layouts.

Sidebar: Controls main and secondary content.

ScrollArea: Contains deliberate overflow.

PageShell: Defines sidebar, top bar, content, and overlays.

Section: Defines semantic page regions and section spacing.

=== COMPONENT INVENTORY ===

Actions:

• Button
• IconButton
• Link
• SplitButton
• MenuButton

Forms:

• FormField
• TextField
• TextArea
• Select
• Combobox
• Checkbox
• RadioGroup
• Switch
• DatePicker
• SearchField
• FileUpload
• ErrorSummary

Navigation:

• Sidebar
• TopBar
• Breadcrumbs
• Tabs
• Pagination
• CommandPalette
• WorkspaceSwitcher
• AccountMenu

Data:

• KPICard
• ChartCard
• DataTable
• DataGrid
• StatusBadge
• Avatar
• Progress
• Timeline
• ActivityFeed

Feedback:

• Alert
• Toast
• Banner
• Skeleton
• Spinner
• EmptyState
• ErrorState
• OfflineState
• PermissionState

Overlays:

• Modal
• Drawer
• Popover
• Tooltip
• DropdownMenu
• ConfirmationDialog

Commercial:

• PricingCard
• BillingSelector
• UpgradePanel
• PlanLimitBanner

=== BUTTON SYSTEM ===

Variants:

• Primary
• Secondary
• Tertiary
• Destructive
• Ghost
• Link
• Icon

Sizes:

• Small
• Medium
• Large

States:

• Default
• Hover
• Focus-Visible
• Pressed
• Loading
• Disabled

Rules:

• Preserve width during loading.
• Use native button semantics.
• Prevent duplicate activation.
• Require accessible labels for icon-only controls.
• Avoid adding visual variants for page-specific styling.

=== FORM SYSTEM ===

FormField Anatomy:

• Label
• Required or optional indicator
• Control
• Prefix
• Suffix
• Helper text
• Error text
• Character count

Rules:

• Use persistent labels.
• Associate errors programmatically.
• Preserve entered values.
• Provide an error summary for complex forms.
• Use mobile-appropriate input behavior.
• Do not rely on placeholders as labels.

=== NAVIGATION SYSTEM ===

Desktop: Persistent sidebar with top utility bar

Tablet: Collapsed navigation rail or drawer, depending on content pressure

Mobile: Accessible navigation drawer

Required Behavior:

• Active state
• Current-page state
• Keyboard access
• Focus management
• Escape behavior
• Focus restoration
• Long-label support
• Internal scrolling
• Safe-area support

=== TABLE SYSTEM ===

Desktop: Full data table or grid

Tablet: Prioritized columns with contained horizontal scrolling where necessary

Mobile: Card transformation, expandable rows, or separate detail view based on user task

Required States:

• Loading
• Empty
• Filtered Empty
• Error
• Permission Restricted
• Partial Data
• Offline

Accessibility:

• Semantic headers
• Sorting state
• Selection state
• Keyboard access
• Responsive relationships
• Screen-reader validation for complex grids

=== FEEDBACK SYSTEM ===

Toast: Brief noncritical confirmation

Alert: Contextual message inside a workflow

Banner: Persistent page-level notice

Skeleton: Structural loading state

ErrorState: Explains failure and recovery

PermissionState: Explains access requirements

OfflineState: Explains unavailable actions and preserved work

PlanLimitState: Explains the limit, reset condition, available options, and upgrade path without false urgency

=== DASHBOARD ARCHITECTURE ===

Dashboard Types:

• Executive Overview
• AI Operations
• Workflow Performance
• Usage
• Administration

AI Operations Dashboard:

• Workflow health KPIs
• Performance trend
• Human review queue
• Failed-run queue
• AI confidence distribution
• Usage summary
• Integration health
• Recent activity

Rule: Every module must support a user decision or action.

=== DASHBOARD PROMPT ===

Create a premium AI operations dashboard for NovaPilot, designed for operations managers who need to monitor workflow health, investigate failures, review uncertain outputs, and coordinate human approval.

Use the approved NovaPilot design system with dark graphite page backgrounds, deep indigo surfaces, electric-blue primary actions, restrained cyan accents, high-contrast typography, semantic status colors, medium radii, subtle borders, limited elevation, and controlled motion.

Include a persistent sidebar, top utility bar, four KPI cards, workflow performance chart, human review queue, failed-run queue, AI confidence panel, usage summary, integration health, and recent activity.

Use realistic fictional data, explicit loading and error states, responsive behavior, accessible contrast, visible focus, non-color status labels, and implementation-believable components.

Do not introduce unapproved colors, random radii, unrelated shadows, mixed icon families, duplicated controls, decorative charts, fake logos, private data, illegible text, excessive glassmorphism, or uncontrolled glow.

=== LANDING PAGE ARCHITECTURE ===

Section Sequence:

1. Header
2. Hero
3. Trust
4. Problem
5. Product Demonstration
6. Feature System
7. Use Cases
8. Workflow
9. Human Control And Security
10. Verified Testimonials
11. Pricing
12. FAQ
13. Final CTA
14. Footer

System Rule: The landing page may use more generous spacing and stronger brand expression, but it must preserve the same typography, colors, radii, icons, status language, and interaction principles as the application.

=== LANDING PAGE PROMPT ===

Create a premium responsive landing page for NovaPilot, an AI automation platform designed for business teams that need to build, monitor, and control AI-powered workflows.

Use the approved NovaPilot design system with intelligent, calm, precise, premium, trustworthy, and efficient brand characteristics.

Include a product-led hero, verified trust placeholders, problem explanation, workflow demonstration, feature system, use cases, human review and permission controls, pricing, FAQ, final CTA, and footer.

Maintain one coherent visual system across every section. Use realistic fictional content, one dominant CTA hierarchy, accessible contrast, semantic section structure, responsive behavior, and implementation-believable components.

Avoid random styles between sections, fake testimonials, fake logos, unapproved colors, arbitrary cards, inconsistent buttons, excessive gradients, private data, and illegible text.

=== INTERACTION STATE MODEL ===

Every interactive component should define:

• Default
• Hover
• Focus-Visible
• Pressed
• Selected
• Disabled
• Loading
• Success
• Warning
• Error
• Empty
• Read-Only
• Permission Restricted
• Offline
• Partial Data
• Plan Limited

For each state, document:

• Trigger
• Visual change
• Content change
• Interaction
• Announcement
• Recovery
• Test requirement

=== ACCESSIBILITY REQUIREMENTS ===

• Use semantic HTML.
• Maintain logical heading hierarchy.
• Provide accessible names.
• Support keyboard interaction.
• Preserve visible focus.
• Maintain logical focus order.
• Use sufficient contrast.
• Avoid color-only status communication.
• Use persistent field labels.
• Associate errors with fields.
• Manage modal and drawer focus.
• Provide responsive reflow.
• Support browser zoom.
• Respect reduced-motion preferences.
• Provide drag-and-drop alternatives.
• Use sufficient touch-target sizes.
• Validate complex widgets with assistive technology.

=== RESPONSIVE REQUIREMENTS ===

Desktop: Persistent shell and full data views.

Tablet: Reduced shell, stacked analysis panels, prioritized columns.

Mobile: Navigation drawer, stacked content, simplified charts, deliberate table transformation, full-width forms, and reduced decorative density.

Responsive Rule: Preserve user tasks, content priority, semantics, keyboard behavior, and status meaning across widths.

=== LOCALIZATION REQUIREMENTS ===

• Allow at least 30% text expansion.
• Avoid fixed-width text regions.
• Support long navigation labels.
• Support long CTA labels.
• Support different date and number formats.
• Prepare mirrored layouts for future RTL.
• Avoid directional icons without RTL adaptation.
• Test German and French expansion.
• Use Unicode-capable licensed fonts.

=== MASTER DESIGN SYSTEM PROMPT ===

Create a complete web UI design system for NovaPilot AI Workspace, a multi-tenant B2B AI automation platform designed for operations managers, marketing teams, customer success teams, agencies, and startup teams.

The system must express these brand attributes: intelligent, calm, precise, premium, trustworthy, and efficient. The visual direction should use dark graphite foundations, deep indigo surfaces, electric-blue primary actions, restrained cyan accents, high-contrast typography, subtle borders, medium radii, limited elevation, and controlled motion.

Define the system in six layers:

1. Product and brand principles
2. Foundations and design tokens
3. Layout primitives
4. Reusable components
5. Product patterns
6. Page templates

Create primitive, semantic, and justified component tokens for color, typography, spacing, sizing, borders, radii, elevation, shadows, motion, breakpoints, grids, density, iconography, imagery, and data visualization.

Specify every component with purpose, anatomy, required and optional elements, variants, sizes, states, content rules, keyboard behavior, accessibility, responsive behavior, Figma notes, frontend notes, and tests.

Include the approved component inventory, application shell, workflow builder, human review queue, filter toolbar, bulk actions, activity feed, usage panel, integration status, onboarding checklist, settings, billing selector, permission gate, upgrade flow, dashboards, and landing-page sections.

Use Next.js, React, TypeScript, Tailwind CSS, shadcn/ui, Radix UI, Figma, Storybook, light and dark themes, responsive layouts, future localization, and WCAG 2.2 AA implementation review.

Maintain one coherent design language. Use realistic fictional content. Prefer semantic controls. Favor composition over excessive variants.

Do not copy proprietary design systems, invent licenses, fabricate customer proof, use private data, create inaccessible contrast, rely on color alone, remove keyboard access, hide focus, mix icon families, introduce arbitrary colors, add arbitrary radii, create random shadows, or drift away from the approved visual system.

=== COMPONENT PROMPT ===

Using the approved NovaPilot design system, create a complete specification for the Human Review Queue component.

Define:

• Purpose
• Anatomy
• Required elements
• Optional elements
• Variants
• Density modes
• States
• Props
• Content rules
• Interaction behavior
• Keyboard behavior
• Accessibility
• Responsive behavior
• Tokens
• Figma properties
• React implementation notes
• Storybook stories
• Tests
• Anti-patterns
• Acceptance criteria

Do not introduce new visual tokens unless the need is documented and approved. Preserve semantic behavior, non-color status communication, keyboard access, visible focus, and review-risk clarity.

=== SCREEN PROMPT ===

Using the approved NovaPilot design system, create an AI Operations Dashboard for an operations manager focused on monitoring workflow health, investigating failures, and assigning human review.

Use:

• Persistent desktop sidebar
• Top utility bar
• Page header
• Four KPI cards
• Workflow performance chart
• Human review queue
• Failed-run queue
• AI confidence panel
• Usage summary
• Integration health
• Recent activity

Include realistic fictional content and explicit loading, empty, error, success, permission, offline, partial-data, and plan-limit states.

Preserve the approved colors, typography, spacing, radii, elevation, iconography, component rules, responsive behavior, and accessibility requirements.

=== AI IMAGE PROMPT ===

Create a premium professional web application UI mockup for NovaPilot, a B2B AI automation SaaS platform.

Use the approved design system: intelligent, calm, precise, premium, trustworthy, and efficient; dark graphite page backgrounds; deep indigo surfaces; electric-blue primary actions; restrained cyan accents; high-contrast typography; medium radii; subtle borders; controlled depth; and minimal glow.

Show an AI operations dashboard with a persistent sidebar, refined top bar, workflow health KPIs, performance chart, human review queue, failed-run queue, AI confidence panel, usage summary, integration health, and recent activity.

Use realistic fictional data, concise labels, reusable components, clear states, precise alignment, and an implementation-believable responsive structure.

Avoid gibberish text, duplicated controls, unapproved colors, random radii, unrelated shadows, malformed tables, impossible charts, distorted icons, broken alignment, excessive glow, fake logos, private data, watermarks, and any styling that conflicts with the approved NovaPilot system. Wide desktop 16:9 composition.

=== NEGATIVE CONSTRAINT LIBRARY ===

• No unapproved colors
• No arbitrary gradients
• No inconsistent radii
• No unrelated shadows
• No mixed icon families
• No random card styles
• No duplicated controls
• No inaccessible contrast
• No color-only status
• No hidden focus
• No illegible microtext
• No gibberish text
• No impossible charts
• No malformed tables
• No fake logos
• No fake testimonials
• No private data
• No watermarks
• No proprietary design-system copying
• No excessive glassmorphism
• No excessive glow
• No broken grids
• No inconsistent perspective

=== FIGMA ARCHITECTURE ===

Pages:

• Cover
• Foundations
• Tokens
• Components
• Patterns
• Templates
• Accessibility
• Documentation
• Deprecated

Variable Collections:

• Primitive Colors
• Semantic Colors
• Typography
• Spacing
• Sizing
• Radius
• Border
• Elevation
• Motion
• Light Theme
• Dark Theme
• Density

Component Naming: Button / Primary / Medium / Default Input / Text / Medium / Error Card / KPI / Default Modal / Standard / Large

Avoid: Blue Button Rounded Card Dark Input

=== FRONTEND ARCHITECTURE ===

Recommended:

• React
• Next.js
• TypeScript
• Semantic CSS variables
• Tailwind CSS
• shadcn/ui
• Radix UI
• Storybook
• Testing Library
• Playwright
• Visual regression
• Automated accessibility checks
• Manual accessibility review

Implementation Rules:

• Preserve accessible primitive behavior.
• Use semantic token variables.
• Avoid uncontrolled arbitrary values.
• Create composable component APIs.
• Separate loading, error, empty, and permission states.
• Document responsive behavior.
• Test overlays and focus management.
• Align code and Figma naming.

=== STORYBOOK PLAN ===

Every component should include:

• Overview
• Default
• Variants
• Sizes
• States
• Light theme
• Dark theme
• Responsive examples
• Long content
• Localization expansion
• Accessibility notes
• Keyboard behavior
• API documentation
• Token references
• Usage examples
• Anti-patterns
• Migration notes

=== TESTING STRATEGY ===

Unit Tests:

• Props
• Rendering
• State
• Events
• Content

Interaction Tests:

• Keyboard
• Pointer
• Focus
• Overlay dismissal
• Form validation
• Responsive interactions

Accessibility Tests:

• Names
• Roles
• Labels
• Relationships
• Focus
• Keyboard
• Contrast review
• Screen-reader review for complex widgets

Visual Regression:

• Variants
• States
• Themes
• Breakpoints
• Density
• Localization
• Long content
• Loading
• Error

End-To-End:

• Onboarding
• Authentication
• Workflow creation
• Human review
• Settings
• Billing
• Error recovery

=== GOVERNANCE MODEL ===

Contribution Process:

1. Define the user problem.
2. Demonstrate repeated need.
3. Identify existing alternatives.
4. Propose anatomy.
5. Define variants and states.
6. Define accessibility.
7. Define responsive behavior.
8. Add tests.
9. Add documentation.
10. Obtain design and engineering approval.

New Component Criteria:

• Repeated use
• Shared structure
• Shared behavior
• Shared accessibility requirements
• Clear ownership
• Maintenance justification

=== VERSIONING POLICY ===

Patch: Backward-compatible fixes

Minor: Backward-compatible features and variants

Major: Breaking API, behavior, token, or visual changes

Every release should document:

• Added
• Changed
• Fixed
• Deprecated
• Removed
• Migration requirements

=== MIGRATION PLAN ===

Phase 1: Audit current screens, styles, tokens, and components.

Phase 2: Map duplicate patterns.

Phase 3: Approve principles, foundations, and tokens.

Phase 4: Implement high-frequency controls.

Phase 5: Implement navigation, forms, feedback, and overlays.

Phase 6: Implement tables, charts, and product patterns.

Phase 7: Migrate dashboard and landing-page templates.

Phase 8: Remove deprecated components.

Phase 9: Validate responsive behavior, accessibility, and themes.

Phase 10: Establish governance and release ownership.

=== ACCEPTANCE CRITERIA ===

Theme Consistency:

Given either light or dark mode is active, when any supported component renders, then it uses approved semantic tokens, preserves hierarchy, maintains visible focus, and communicates state without relying only on color.

Component Consistency:

Given a new dashboard screen is generated, when the screen uses buttons, cards, fields, tables, and alerts, then every component follows the approved anatomy, variants, states, tokens, spacing, typography, and responsive rules.

Prompt Consistency:

Given an AI model generates a new screen from the approved prompt system, when the output is reviewed, then it preserves the approved brand attributes, token logic, component language, layout principles, state model, and negative constraints.

Responsive Consistency:

Given the viewport changes from desktop to mobile, when the AI Operations Dashboard reflows, then navigation becomes accessible, primary tasks remain available, tables use an approved mobile strategy, and content does not create page-level horizontal scrolling.

Accessibility:

Given a keyboard user navigates the product, when focus reaches interactive controls, then focus remains visible, the order is logical, names are meaningful, overlays manage focus correctly, and status meaning remains understandable without color alone.

=== QA CHECKLIST ===

Brand:

• Verify attributes.
• Verify visual direction.
• Verify avoided styles.
• Verify product and marketing consistency.

Tokens:

• Verify primitive tokens.
• Verify semantic tokens.
• Verify component-token necessity.
• Verify theme mapping.
• Verify contrast.

Components:

• Verify anatomy.
• Verify variants.
• Verify states.
• Verify content rules.
• Verify responsive behavior.
• Verify accessibility.
• Verify tests.

Prompts:

• Verify product context.
• Verify user role.
• Verify screen purpose.
• Verify layout.
• Verify components.
• Verify states.
• Verify negative constraints.
• Verify output format.

Figma:

• Verify variables.
• Verify component names.
• Verify variants.
• Verify Auto Layout.
• Verify documentation.
• Verify deprecated components.

Frontend:

• Verify semantic tokens.
• Verify component APIs.
• Verify responsive rules.
• Verify focus management.
• Verify Storybook.
• Verify tests.

=== KNOWN LIMITATIONS ===

• AI outputs may still drift and require review.
• Final Figma components must be constructed and validated.
• Final source code requires engineering review.
• Accessibility requires implementation testing.
• Browser and framework compatibility require validation.
• Package and asset licensing require independent verification.
• Migration effort depends on the existing system.
• The design system does not guarantee complete adoption, faster delivery, lower cost, or commercial success.

=== FINAL PROFESSIONAL NOTE ===

Validate component behavior, accessibility, licensing, browser support, framework compatibility, performance, and product-specific requirements before production release.

Verify the licenses and usage rights of all fonts, icons, illustrations, UI libraries, code packages, and third-party assets before distribution or commercial use.