UI Designing test

Prompt

# PROJECT: CHATGPT PRO — HIGH-FIDELITY SUBSCRIPTION UI RECREATION ## ROLE Act as a senior frontend engineer, UI/UX reverse-engineer, and pixel-precision design specialist. Build a production-quality frontend that faithfully recreates the visual experience of ChatGPT's Pro subscription and plan-selection interface. ## PRIMARY OBJECTIVE Create an exceptionally accurate visual recreation of the ChatGPT subscription UI using the provided screenshots or other authorized visual references. Prioritize visual fidelity over creative redesign. Do not invent a new layout, change the visual hierarchy, or add unnecessary features. ## 1. REFERENCE ANALYSIS Before coding: - Inspect every supplied screenshot carefully. - Identify the layout, container widths, margins, padding, typography, line heights, colors, borders, radii, shadows, and alignment. - Reproduce the plan cards, pricing hierarchy, feature lists, buttons, separators, navigation elements, and modal behavior visible in the references. - Match text wrapping and component dimensions as closely as possible. - Identify responsive behavior where mobile and desktop references are available. - If no screenshots are provided, use publicly accessible, authorized reference material where available. Do not pretend to have inspected unavailable pages. ## 2. DESIGN REQUIREMENTS ### Overall appearance - Minimalist, premium, polished interface. - Accurate typography and restrained color palette. - Precise spacing and consistent alignment. - Clean borders, subtle shadows, and appropriate corner radii. - Correct visual hierarchy between page title, plan names, pricing, descriptions, features, and calls to action. - No unnecessary gradients, decorative backgrounds, oversized headings, or generic AI-dashboard aesthetics. ### Subscription plan cards Reproduce the exact structure shown in the supplied references, including: - Plan name and description. - Pricing and billing interval, where applicable. - Plan-specific feature lists. - Primary and secondary action buttons. - Dividers and highlighted plan treatments. - Plan comparison sections, if present. - Footnotes, eligibility notices, and billing disclaimers, if present. Do not invent current prices, usage limits, or benefits. Treat reference screenshots as the visual source and verify current plan information separately if it will be displayed as factual information. ### Interactive behavior Implement working frontend interactions for: - Selecting or switching between available plans. - Monthly/yearly billing toggles, only if shown in the reference. - Expandable feature details, if shown. - Dialogs and menus visible in the reference. - Hover, focus, active, and disabled states. - Responsive navigation and mobile layouts. Use realistic demonstration behavior. Do not connect the demo to real billing or imply that a subscription has been purchased. ## 3. TECH STACK Use: - React - Vite - TypeScript - Tailwind CSS - Lucide React for icons when suitable - Reusable, strongly typed components Use the existing project's framework if a repository is already provided. Do not replace a working project architecture without a compelling reason. ## 4. COMPONENT ARCHITECTURE Create reusable components such as: - SubscriptionPage - PlanCard - PlanHeader - PricingDisplay - FeatureList - FeatureItem - BillingToggle, if required - PlanComparison, if required - SubscriptionDialog, if required - ResponsiveNavigation, if required Keep the code modular and maintainable. Separate plan data from presentation so the interface can be updated without rewriting components. ## 5. PIXEL-PRECISION REQUIREMENTS - Reproduce the reference's page dimensions and content positioning. - Match horizontal and vertical spacing systematically. - Use the correct font family where legitimately available; otherwise choose the closest appropriate fallback. - Match font weights, letter spacing, line heights, and text sizes. - Reproduce card widths, heights, padding, and internal alignment. - Use consistent icon dimensions and stroke weights. - Avoid arbitrary CSS values when a shared spacing or sizing token would be more accurate. - Prevent layout shifts and unintended text wrapping. - Ensure the design looks correct at desktop, tablet, and mobile widths. If screenshots are available, compare the implementation against them and iterate until the remaining differences are minimal. ## 6. FUNCTIONAL AND ACCESSIBILITY REQUIREMENTS - Every visible button must perform its intended demo action. - All interactive elements must be keyboard accessible. - Add clear focus indicators and appropriate ARIA attributes. - Use semantic HTML. - Ensure readable contrast and reduced-motion support. - Handle loading and error states where relevant. - Avoid dead links, placeholder click handlers, and fake payment-success screens. ## 7. SECURITY AND BRANDING - Do not collect payment-card information, passwords, or other sensitive user data. - Do not imitate authentication in a way that could capture real credentials. - Do not represent this project as an official OpenAI product. - Do not use private APIs, stolen assets, or unauthorized internal source code. - Keep the implementation frontend-only unless a backend is explicitly necessary. - Clearly identify the result as an unofficial UI recreation or design demo. ## 8. IMPLEMENTATION WORKFLOW Follow this sequence: 1. Inspect the existing repository and identify the current framework and dependencies. 2. Analyze the available screenshots and extract a visual specification. 3. Establish typography, spacing, color, and sizing tokens. 4. Implement the page structure and reusable components. 5. Add interactions and responsive behavior. 6. Run the application and inspect the rendered output. 7. Test at desktop and mobile viewport sizes. 8. Fix visual inconsistencies, console errors, accessibility issues, and broken interactions. 9. Run the available lint, type-check, build, and test commands. 10. Summarize the files changed, features implemented, tests performed, and any remaining limitations. ## 9. ACCEPTANCE CRITERIA The project is complete only when: - The interface closely matches the supplied visual references. - Typography, spacing, alignment, cards, and buttons have been checked against the references. - Responsive layouts work without horizontal overflow. - All visible interactive elements behave correctly. - The project starts using the documented commands. - The production build succeeds. - No critical console errors or TypeScript errors remain. - No real payment or credential collection is implemented. - No completion claims are made for tests that were not actually executed. ## FINAL INSTRUCTION Build the actual working application, not a mockup description or a tutorial. Make implementation decisions independently when the references provide sufficient information. Ask questions only when a missing asset or essential requirement prevents accurate implementation. Visual accuracy is the highest priority. Do not redesign the reference. Inspect, implement, render, compare, correct, and verify.

A system prompt was added to support web rendering