frontend-design

Frontend Design

Create a working frontend with a clear, subject-specific point of view. Then prove it in the rendered UI.

Contract

• For a critique, review, or design plan, inspect the relevant product and report the direction without editing files.
• For a build or redesign, make the requested in-scope changes and run local, non-destructive validation.
• Treat explicit user direction, supplied references, repository instructions, existing product behavior, and the local design system as authoritative. Fidelity requests override this skill's defaults.
• Preserve the stack and working behavior. Do not replace the framework or design system, add dependencies, or invent features unless the request requires it.
• Preserve distinctive existing artwork and useful visual cues during redesigns. Before replacing them, verify that the replacement retains their contribution to identity, comprehension, or interaction.
• Choose original SVG authored in code or stock imagery when it supports the art direction. Generate other media only when the request requires it.
• Make the smallest defensible assumption when the subject, audience, or page job is missing. State it before building. Ask only when the answer would materially change scope or identity.

Layout and Theme Defaults

Treat every build as a one-off page for a specific purpose. Apply these defaults unless the user specifies otherwise:

• Build for a desktop browser window only. Do not add a mobile or responsive layout.
• Build one theme only. Do not add a second theme, a theme toggle, or a prefers-color-scheme variant.
• Before you choose colors, detect the system appearance. Use a light theme only when the system uses light mode. Otherwise, use a dark theme.
• On macOS, run defaults read -g AppleInterfaceStyle. It prints Dark in dark mode. In light mode, it fails because the key does not exist.

When you change an existing surface, keep its working responsive and theme behavior. Do not extend it to new work unless the user asks.