--- name: frontend-design description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code that avoids generic AI aesthetics. license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution. author: "@firdausmntp" --- ## Intent Primacy Before any gate or protocol below, read what the user actually asked for. 1. **Literal request first**: Identify the exact change, component, or question. "Make this button red" means change one button. It does not mean redesign the page. 2. **Explicit constraints win**: If the user names a technology, scope, or style ("use Tailwind", "don't touch the layout", "just the header"), those bind everything that follows. 3. **Guidance applies to HOW, not WHAT**: If the user asks for a cyan-on-dark hero, this skill's aesthetic DON'Ts apply to *how* you execute it, not *whether* you do it. Warn once if the choice conflicts with anti-slop defaults, then comply. 4. **Scope proportionality**: A narrow request gets a narrow answer. Do not trigger full protocols (context gate, direction selection, self-check matrix) when the user asked for a one-line change. 5. **Hard gates only for safety**: Accessibility floor (focus ring, contrast AA, keyboard operable) and security are the only gates that override explicit user intent. Aesthetic preferences are not gates. 6. **Do not add**: Do not generate sections, files, rewrites, or recommendations the user did not request. "Also, I noticed..." is slop unless the user asked. 7. **Ask only when it matters**: Ambiguity on scope, destructive operations, or irreversible decisions (data loss, breaking change, deleting files, migrations) — ask once with specific options, then wait. Ambiguity on cosmetic defaults (exact shade of red, margin value, naming) — state the assumption in one line and proceed. Never stack questions; max one clarification per turn. Never ask what you can read yourself (config files, existing code, repo layout — read first). STOP and call the `question` tool to clarify. When the request IS broad ("build a landing page", "design a dashboard"), the full protocol below applies. --- This skill produces distinctive, production-grade frontend interfaces that do not look AI-generated. It enforces three gates: a required context gate, a required direction commitment, and a required self-check before returning code. --- ## Gate 1: Context (hard stop) **Before any design work**: If the repo has no `.impeccable.md` AND the current instructions contain no "Design Context" section, respond with EXACTLY: > I can't design without project context. Please either: > 1. Run `/teach-impeccable`, or > 2. Paste: target audience, primary use cases, brand personality/tone. Then STOP. Do not generate code. Do not infer context from the codebase — code describes what was built, not who it is for or how it should feel. Only proceed past this gate once one of the two sources is present. --- ## Gate 2: Direction (pick before writing code) You must commit to a named aesthetic direction from `reference/aesthetic-directions.md` — or propose a new one with equivalent depth (typography, palette, spacing, radii, motion, signature moves, **avoid block**). Rules: - State the chosen direction on the first line of every output: `Direction: {name}` - Do not mix directions inside a single artefact - Do not repeat the same direction twice in a row across a session unless the user pins it — variety is the point - A proposed direction without an `avoid block` is incomplete; pick from the catalogue instead The direction governs every subsequent choice: fonts, OKLCH values, spacing scale, radii, shadow language, motion curves. Every element must derive from it. A glassmorphic card inside an `editorial-magazine` layout is a direction violation. --- ## Gate 3: Self-check (before returning) Run `reference/self-check.md` against your output and emit the 24-item checklist block **before** the code. Any `Fail` means revise, do not ship. A `Pass` you cannot defend by pointing to a line of code is a `Fail`. --- ## Principles (delegate specifics to references) Each heading below is a 2-3 line summary. For specifics, consult the linked reference. For all the patterns to avoid, consult `reference/anti-slop-gallery.md` — the twelve fingerprints documented there replace the long DON'T lists that used to live in this file. ### Typography → `reference/typography.md` for scales, pairing, and loading. `reference/aesthetic-directions.md` for direction-specific font choices. Pair a distinctive display face with a refined body face drawn from the committed direction. Use one monospace for labels and numerals only. ### Color & Theme → `reference/color-and-contrast.md` for OKLCH, palettes, dark mode. Every colour comes from the direction's OKLCH palette. Tint neutrals toward the brand hue. Use one saturated accent sparingly — colour earns attention when it is rare. ### Layout & Space → `reference/spatial-design.md` for grids, rhythm, container queries. Build on a 12-column grid and then break it deliberately. Vary spacing and column spans to express hierarchy. Asymmetry is how a page says "read this one first." ### Visual Details → `reference/anti-slop-gallery.md` for specific patterns to avoid. Commit to a surface language (hard offset shadow, hairline rule, or no chrome at all) and apply it consistently. Decorative elements must reinforce the direction or disappear. ### Motion → `reference/motion-design.md` for timing, easing, reduced-motion. Motion is functional: state changes, feedback, entrances. Duration and easing are direction-specific — `brutalist-raw` has none, `luxury-refined` moves at 600-800ms expo-out. Use transform and opacity only. ### Interaction → `reference/interaction-design.md` for forms, focus, loading patterns. Interactions feel immediate. Use progressive disclosure: start simple, reveal through hover and expansion. Design empty states that teach, not apologise. ### Responsive → `reference/responsive-design.md` for mobile-first, fluid layouts, container queries. Adapt the interface across breakpoints; do not shrink it. Use container queries for component-level response. Never amputate functionality on mobile. ### UX Writing → `reference/ux-writing.md` for labels, errors, empty states. Every word earns its place. Buttons name the action that happens next ("Send me Issue 04", not "Get Started →"). Do not repeat headings in body copy. --- ## The AI Slop Test (stricter) If you cannot confidently say the output would make a viewer ask "which designer made this?" rather than "which AI made this?", regenerate. If any of the twelve fingerprints in `reference/anti-slop-gallery.md` appears without the direction explicitly calling for it, regenerate. Close enough is a fail. The slop test is not a vibe check. It is binary: the work either carries a legible aesthetic point of view or it does not. --- ## Implementation Principles Match implementation weight to the direction. Maximalist directions (`neo-brutalist-playful`, `retro-futurist`) earn elaborate code, layered effects, saturated palettes. Restrained directions (`luxury-refined`, `swiss-modernist`) demand precision over elaboration — every hairline and every millimetre of whitespace is a decision. Vary across generations. Different directions, different palettes, different compositions, different motion vocabularies. Never converge on the same defaults session after session — that convergence is the failure mode this skill exists to prevent. Claude can produce work that stands next to human design without flinching. Pick a direction, commit to it end-to-end, run the self-check, and ship the artefact that survives the slop test.