Pixel Perfect

Generate pixel-perfect, design-system-aware frontend components with distinctive aesthetics, full interactivity, and accessibility. This skill handles every frontend code generation request -- from screenshot reproduction to text-described UIs -- producing framework-matched, responsive, production-grade output.

Workflow

Follow these six steps for every frontend generation request:

1. Context Detection -- Identify the project's framework, styling approach, and existing design system
2. Input Analysis -- Process the provided input (screenshot, text, code, tokens, or a combination)
3. Ambiguity Check -- Identify unclear or insufficient input and ask targeted clarification questions before proceeding
4. Design System Resolution -- Use existing tokens or create a new token set
5. Code Generation -- Produce framework-matched, responsive, interactive, accessible code
6. Quality Verification -- Before presenting output, confirm: responsive CSS is present, all interactive states are handled, semantic HTML is used, ARIA attributes are on elements lacking visible text labels, no hardcoded token values exist when a token system is in scope, and the aesthetic is intentional and distinctive

Context Detection

Detect the project's technology stack by reading specific indicator files. Do not scan the entire project tree; target these files directly:

Framework detection -- Check package.json dependencies for React (react, next, gatsby, remix), Vue (vue, nuxt), Svelte (svelte, @sveltejs/kit), or Angular (@angular/core). Check for config files: next.config.*, nuxt.config.*, svelte.config.*, angular.json, vite.config.*, tsconfig.json. Examine existing component files for framework-specific syntax (JSX/TSX, .vue SFCs, .svelte files, Angular decorators). If no framework indicators exist, generate plain HTML/CSS/JavaScript. If the developer explicitly specifies a framework, use it regardless of detected indicators.

Styling detection -- Check for tailwind.config.* or tailwind.config.ts, CSS module file naming (*.module.css, *.module.scss), styled-components or emotion imports in existing component files, CSS files containing custom property blocks (:root { --* }), SCSS/SASS files. Match the detected approach in generated output. When multiple styling approaches coexist, prefer the one used most recently in the project's component files.

Design system detection -- First, check for a DESIGN.md or design.md file in the project root. If found, parse its YAML front matter as the canonical token source — this format takes precedence over all other detection methods. Then look for theme files (theme.ts, theme.js, tokens.json), CSS custom property definitions in global stylesheets, Tailwind theme configuration in tailwind.config.*, or component library config (chakra-ui, shadcn, radix). If found, these tokens govern all generated output. Read the token values to understand the existing palette, spacing scale, and typography before generating any code.

Security constraint -- Never read .env files, credential files, or directories containing secrets (.aws/, .gcp/). Never make external network requests. Never execute generated code.

Input Handling

Process each input type with specific strategies:

Screenshot or mockup image -- Analyze the visual composition: layout structure, spacing relationships, color values, typography sizing, border treatments, shadow characteristics, and component hierarchy. Extract specific measurements and proportions from the image rather than approximating with generic values. Identify the grid system or layout approach used (e.g., 12-column grid, asymmetric layout, centered single-column). Note font weights, letter-spacing, and line-height ratios visible in the design. When the image is blurry, partially obscured, or has ambiguous spacing or alignment, ask the developer to clarify the specific ambiguous elements before generating code.

Text description -- Generate code implementing the described UI. Make intentional creative design decisions for unspecified visual details. When the description is vague or insufficient to produce accurate output, ask targeted clarification questions.

Existing code -- Analyze the current implementation, identify areas for improvement, and generate refined code preserving the original structure where it serves the design.

Design tokens or style guide -- Incorporate provided tokens as the foundation for all generated code.

Mixed inputs -- Synthesize all provided inputs into a coherent implementation. Text annotations on screenshots take precedence over visual ambiguity.

Figma links or external URLs -- Acknowledge inability to access external URLs directly. Ask the developer to provide a screenshot or describe the relevant design details.

Design System Strategy

Follow a detect-first approach:

Existing system found -- Use those tokens for all generated code. Never introduce values that conflict with the established system.

No system found, visual input provided -- Extract design tokens from the visual input: colors (primary, secondary, accent, neutral palettes), spacing scale, typography scale (families, sizes, weights, line heights), border-radius values, shadow definitions, and transition timing. Codify them as a DESIGN.md file following the YAML front matter schema in references/design-tokens.md, with markdown sections explaining the design rationale. Output the DESIGN.md alongside the component code. For Tailwind projects, note that npx @google/design.md export --format tailwind DESIGN.md generates a ready-to-use theme config.

No system found, text-only input -- Generate a coherent token set matching the described aesthetic. Output it as a DESIGN.md file (YAML front matter + markdown rationale) alongside the component so subsequent generations can reference it.

Cross-component consistency -- When generating multiple components in the same session, always reference the token set established by the first generation. Never introduce conflicting one-off values.

Hard rule -- Never use hardcoded color values, spacing values, or typography sizes inline when a token system exists or has been created in the current session. Always reference tokens.

Code Generation Standards

Responsiveness

Generate responsive CSS for every component. Default to mobile-first breakpoints unless the project uses desktop-first. Use clamp() for fluid typography and spacing. Use container queries for component-scoped responsiveness. Use CSS Grid for two-dimensional layouts and Flexbox for one-dimensional flow. Never generate fixed-width layouts unless the developer explicitly requests non-responsive output.

Interactivity

Include complete state management using the framework's standard patterns: React useState/useReducer, Vue ref()/reactive(), Svelte reactive declarations and stores, Angular signals, or plain JavaScript event handling. Implement all interaction states for every interactive element: hover, focus, active, disabled, loading, error, and empty/zero states as each applies. For forms, include input validation, error display, and submission handling. For animated or transitioning elements, prefer CSS transitions and animations first; use framework animation libraries (Framer Motion, Vue Transition, Svelte transitions) only when CSS alone is insufficient. Focus on high-impact animation moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more impact than scattered micro-interactions. Design hover states that go beyond color changes -- use scale, shadow shifts, reveals, or morphs to create tactile feedback.

Keyboard Navigation

Implement focusable elements in logical tab order. Activate buttons and toggles with Enter and Space. Close overlays with Escape. Navigate menus and lists with arrow keys. Never create interactive elements that are only mouse-accessible.

Accessibility

Use semantic HTML elements (nav, main, article, section, aside, header, footer, button, form) instead of generic div/span containers wherever semantically fitting. Include ARIA labels on interactive elements that lack visible text labels (icon buttons, image links, toggle controls). Include ARIA roles and states for custom interactive widgets (tabs, accordions, dialogs, comboboxes) following WAI-ARIA Authoring Practices. Ensure color contrast meets WCAG 2.1 AA minimums: 4.5:1 for normal text, 3:1 for large text. Include alt text on images: empty alt="" for decorative, descriptive text for informational. When visual fidelity and accessibility conflict, prioritize the visual design but document the tradeoff in a code comment.

Aesthetic Direction

When no existing design system constrains the output, commit to a bold, intentional aesthetic direction. Choose a distinct visual identity -- brutally minimal, maximalist, retro-futuristic, organic, luxury, editorial, brutalist, art deco, soft/pastel, industrial, or another distinctive style -- and execute it with precision. Select distinctive typography that matches the chosen direction: pair a characterful display font with a refined body font. Construct a cohesive color palette with dominant-accent relationships where one hue leads and accents punctuate. Create atmosphere through contextual textures and effects: gradient meshes, noise, geometric patterns, layered transparencies, dramatic shadows, or grain overlays matched to the overall theme.

Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and layered effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision fully, not from hedging between styles.

Every generation must feel distinct; never converge on the same fonts, colors, or layouts across different requests. Vary between light and dark themes, different font personalities, different spatial compositions, and different aesthetic categories.

For detailed aesthetic guidance including typography pairing strategies, color palette construction, motion design, spatial composition techniques, background textures, and anti-pattern catalogs, read references/aesthetic-guide.md. Extraordinary creative work is the standard -- commit fully to a distinctive vision.

Anti-Patterns

Never do the following:

• Use generic font families (Inter, Roboto, Arial, system-ui) as the sole typographic choice when no existing design system specifies them
• Generate cliched color schemes: purple gradients on white backgrounds, default blue links, generic gray palettes
• Produce fixed-width, non-responsive layouts
• Output static mockups without state management for inherently interactive components
• Hardcode color, spacing, or typography values when a token system exists or has been established
• Converge on the same aesthetic choices (e.g., Space Grotesk) across different generations
• Read .env files, credential files, or secrets directories during context detection
• Make external network requests or attempt to access Figma URLs, CDNs, or external APIs
• Execute generated code or run build tools

Additional Resources

Load these reference files on-demand when the specific condition applies: