Use this skill when the user needs to design, refine, or implement a distinctive production-ready frontend: define visual direction, build or restyle components and pages, improve responsive behavior, strengthen accessibility, and translate design intent into maintainable code without defaulting to generic AI-generated UI patterns.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Use this skill when the user needs to design, refine, or implement a distinctive production-ready frontend: define visual direction, build or restyle components and pages, improve responsive behavior, strengthen accessibility, and translate design intent into maintainable code without defaulting to generic AI-generated UI patterns.
strengthen accessibility, semantics, keyboard support, motion behavior, or touch usability
convert design intent into maintainable HTML, CSS, and component structure
Do not use this skill as the primary workflow when the task is mainly:
backend logic, APIs, authentication internals, or database design
brand strategy without implementation expectations
one-off image generation or purely visual mockups with no production path
generic refactoring unrelated to UI behavior or design quality
Workflow
Clarify the interface goal
Identify the user task, primary content, success state, and constraints.
Determine whether the work is new UI, redesign, polish, or remediation.
Capture brand signals: tone, density, contrast, shape language, motion style, and what should feel distinctive.
Inspect the current system before changing it
Review existing layout structure, components, tokens, CSS organization, and interaction states.
Look for hidden constraints: framework primitives, design system rules, SSR/CSR boundaries, existing breakpoints, dialog patterns, and form handling.
If working from screenshots or vague requests, infer the minimum stable information before coding.
Define the design direction in implementation terms
Choose the intended hierarchy, spacing rhythm, type scale, surface treatment, and interaction tone.
Decide what should remain restrained so the distinctive elements have contrast.
Convert abstract design language into concrete component decisions: card structure, navigation pattern, empty states, forms, tables, overlays, and feedback states.
Build semantic structure first
Start with HTML or component structure that expresses landmarks, headings, lists, buttons, links, forms, tables, and dialogs correctly.
Prefer native elements before ARIA-heavy custom widgets.
Ensure the tab order, labels, headings, and reading order make sense before visual styling.
Make responsiveness component-first
Favor intrinsic sizing, flexible layouts, and container-query thinking over viewport-only breakpoint stacking.
Check what happens when components live in narrow sidebars, wide content columns, dense dashboards, and zoomed layouts.
Treat text wrapping, truncation, target sizing, and control grouping as first-class design decisions.
Apply CSS architecture deliberately
Use tokens, variables, and predictable naming or layering instead of ad hoc overrides.
Use cascade layers when they reduce specificity conflicts between reset, tokens, base, components, utilities, and overrides.
Avoid brittle selectors, !important escalation, and one-off styles that encode accidental layout dependencies.
Design interaction states and accessibility together
Define hover, focus, active, disabled, loading, error, success, and empty states.
Keep visible focus appearance, keyboard reachability, and reduced-motion handling non-negotiable.
Ensure dialogs, disclosures, menus, and forms have predictable behavior and semantics.
Treat performance as a design acceptance criterion
Avoid visual decisions that create heavy runtime cost without product value.
Watch for large DOMs, expensive shadows or filters, layout thrash, unnecessary observers, and animation tied to expensive properties.
Consider containment, content-visibility, asset sizing, and rendering cost where the UI is dense or repeated.
remove outlines without providing a stronger focus treatment
rely only on viewport breakpoints when components can appear in multiple container widths
build custom buttons, links, selects, dialogs, or menus when native elements solve the problem
use ARIA to patch incorrect structure that should be fixed in markup
accept inaccessible target sizes, low-contrast focus states, or motion-heavy transitions as polish
solve CSS conflicts primarily with specificity escalation or !important
ignore responsiveness and input latency until after the visual direction is finalized
Troubleshooting
Symptoms: The UI looks polished at one screen size but breaks when the same component is placed in a narrower column or sidebar.
Solution: Rework the component using intrinsic layout rules and container-aware behavior. Reduce dependence on page-level breakpoints. Verify wrapping, control grouping, and media sizing inside the component itself.
Symptoms: The design feels generic even though colors and spacing changed.
Solution: Adjust structural signals, not just surface styling. Revisit type scale, spacing rhythm, edge treatment, density, contrast strategy, and interaction tone. A distinctive frontend usually comes from consistent system choices, not isolated decoration.
Symptoms: Keyboard users can reach controls, but focus is hard to see or disappears on branded surfaces.
Solution: Add a visible, high-contrast focus treatment that survives all themes and states. Test with keyboard only across links, buttons, form controls, dialogs, and composite components.
Symptoms: A custom widget needs many ARIA attributes and still behaves inconsistently.
Solution: Step back and ask whether a native element or simpler pattern can replace it. If not, implement the full keyboard and state model intentionally instead of partial ARIA decoration.
Symptoms: CSS changes keep causing regressions or require repeated overrides.
Solution: Introduce clearer layering and ownership boundaries. Separate reset/base/component/utility/override concerns, reduce selector brittleness, and move repeated values into tokens or variables.
Symptoms: The interface becomes sluggish after adding visual richness or dense repeated cards.
Solution: Audit expensive rendering decisions. Simplify deep shadows, large blur effects, continuous animations, and unnecessary DOM depth. Consider containment or content-visibility where repeated offscreen content is involved.
Symptoms: A modal, menu, or disclosure looks correct but behaves unpredictably with keyboard or screen readers.
Solution: Re-check semantics, focus management, labeling, and escape/close behavior. Use a native or well-understood pattern before inventing interaction rules.
Examples
Example 1: Redesign request with implementation direction
Input
Make this analytics dashboard feel premium and less template-like. Keep it production-ready and accessible.
Expected approach
- Identify what currently makes the dashboard feel generic: flat card repetition, weak type hierarchy, uniform spacing, and framework-default controls.
- Propose a design direction: sharper data emphasis, stronger typography contrast, restrained accent usage, and more deliberate panel grouping.
- Preserve semantic structure for navigation, tables, filters, and chart regions.
- Improve responsiveness by letting summary cards and filter groups adapt to container width rather than only viewport breakpoints.
- Define visible focus styles, larger click targets, and reduced-motion-safe transitions.
- Explain CSS architecture changes needed to avoid override sprawl.
Example 2: Existing component polish without breaking semantics
Input
Restyle this settings form so it feels more modern, but do not sacrifice usability.
Expected approach
- Keep labels, descriptions, validation, and field grouping explicit.
- Improve spacing rhythm, control sizing, and section hierarchy.
- Ensure form actions remain obvious and keyboard reachable.
- Add strong focus treatment and error/success states.
- Check long labels, helper text, and mobile stacking behavior before finalizing the visual treatment.
references/domain-notes.md — Open this during implementation when you need compact decision rules for container queries, cascade layers, semantic-first accessibility, focus appearance, target sizing, reduced motion, dialog behavior, and performance-sensitive UI choices.
examples/worked-example.md — Open this when you want a concrete prompt-to-output pattern showing how to transform a generic request into a production-grade frontend design response.
Related Skills
No verified related local skills were provided in the source context.
