Dev-Frontend — Domain-Correct Frontend Engineering

Build production-grade frontend implementations from an established product/design direction. This skill owns HTML/CSS/component/runtime implementation, responsive behavior, accessibility wiring, visual verification, and frontend platform rules.

Role separation: For design judgment — typography/color/layout direction, UX decision gates, product personalities, or vague visual briefs — load dev-uiux-design first. This skill implements the chosen direction; dev-uiux-design makes the design decisions. Implementation anti-slop tell detection and enforcement stays here (concrete rendered tells in UI); design-level concept/taste judgment lives in dev-uiux-design.

Role boundary (canonical — identical in dev and dev-uiux-design): dev owns universal process, evidence, and safety rules. dev-uiux-design owns design intent, direction, and concept judgment. dev-frontend owns concrete frontend implementation and rendered tell enforcement. Anti-slop has three layers: dev = output/process hygiene (FAMILY-SLOP-01), dev-uiux-design = concept/taste judgment (is this direction generic or domain-wrong?), dev-frontend = rendered implementation tell detection and removal (FE-AI-TELL-01).

C0/C1 work (small local patches): See dev §0.0 Work Classifier + §0.1 Patch Fast-Path before reading references.

Modular References

File	When to Read	What It Covers
references/core/crud-ui.md	C2 list/detail/form product screens	State coverage (loading/empty/error/permission), forms, objective UX gates
references/core/anti-slop.md	New/redesigned visual surfaces, visual audits, and variant generation	2026 AI slop patterns, Korean slop, oversized text, fake assets, default UI smells
../dev-uiux-design/references/design-trends.md	Calibrating a dated design example	Source provenance, surface-specific exceptions, and re-verification before promoting a sample to a default
../dev-uiux-design/references/design-trends.md	Implementing a dated trend or checking whether a technique is stable	2026-07-14 axis prevalence, technique maturity, signature status, risks, and re-crawl/promotion rules
references/core/aesthetics.md	Implementing an established visual direction	Domain-correct typography, color, composition constraints, serif three-role system, expressive/functional layers, AI-brand grammar
references/core/product-density.md	Apps, tools, dashboards	Density profiles for landing, consumer app, SaaS, ops, finance, devtools
references/core/asset-requirements.md	Any public/product/visual surface	Required screenshots, images, diagrams, charts, generated bitmaps, or 3D assets, mockup production pipeline
references/core/visual-verification.md	Changes affecting rendered layout	Screenshot, viewport, text fit, state, asset, and motion verification
references/core/token-source-divergence.md	Changing colour, type, spacing, or breakpoint values in a repo that declares the same tokens in two or more places	Source inventory, authority and sync arrangement, one-sided-change gate, literal classification, rendered parity
references/core/content-surface-pipeline.md	Speeding up or changing a surface produced repeatedly by a content-design-development chain; read alongside layout-discipline.md (layout grammar) and asset-requirements.md (asset production), which own different questions about the same pages	Mapping the handoff, locating the constraining step, multi-path render resolution, data-injected style, preview fidelity, per-block QA, release coupling
../dev-uiux-design/references/conversational-ai.md	Implementing a turn-based AI surface with streaming, interruption, regeneration, or uncertain results	Turn-state contract the frontend must preserve before wiring rendering and a11y
references/core/korea-2026.md	Korean-first or Korea-facing UI	Korean service patterns, CJK typography, formats, mobile flows, Korean serif/myeongjo display
references/core/ux-writing-ko.md	Korean UI copy	Natural Korean labels, error messages, tone, spacing, punctuation
references/core/soft-3d-asset-gates.md	3D/miniature/character-like visuals	Toss-style soft 3D vs generic cute asset slop, domain gates
references/core/motion.md	Motion/animation needed	CSS animations, Framer Motion, CSS scroll-driven timelines, pointer-proximity chip motion (magnetic/dock), View Transitions, domain gates, organic bg + capsule label, product-led hero motion
references/core/liquid-glass.md	Translucent materials, glass chrome, pill-chip surfaces	Liquid Glass layer discipline, named material states (pill-at-top/pill-scrolled/media-overlay/clear), FE-PILL-NEST-01, blur-free pill alternative, perf + a11y gates
references/core/top-bar.md	Top/nav bar composition, sticky chrome	Top-bar grammar: geometry, slots, scroll-state contract (FE-TOPBAR-STATE-01), hover-surface contract (FE-TOPBAR-HOVER-01), domain gate, mobile collapse
references/core/iterative-design.md	Multi-round design	LLM convergence problem, Diverge→Kill→Mutate process, upgrade techniques
references/core/prototype-variants.md	Runnable design variants	?variant= switchers, structurally distinct options, cleanup after winner selection
references/core/typography-wrapping.md	Heading/descriptor text changes	text-wrap: balance/pretty, natural phrase breaks at any width, dynamic-viewport verification, ch units, Korean keep-all/orphan rules (verified 2026-07-07)
references/core/logo-sections.md	Integration/partner logo display	Marquee CSS, static grid, orphan cell fix, grayscale treatment, no individual hover
references/core/brand-asset-sourcing.md	Brand logos in UI	Simple Icons/SVGL sourcing, AI agent strategy, placeholder hierarchy, legal guide
references/core/reference-capture.md	Cloning/analyzing other sites	HTML+asset capture mechanics (pageAssets/curl), analysis-only legal line, provenance manifest, never-ship gate
references/core/dropdown-layer.md	Dropdowns, selects, menus, pickers	Unified dropdown design layer (FE-DROPDOWN-LAYER-01): one skin over headless primitives, DS-detection precedence, scope table, mobile sheet
references/core/layout-discipline.md	Landing/marketing pages	Hero, eyebrow, section repetition, bento, zigzag, per-section responsive transforms, hero composition grammar (2026)
references/core/section-level-sourcing.md	Section-level design work (hero, pricing, testimonials, etc.)	Per-section-type reference sources from Land-book, One Page Love, Lapa.ninja
references/core/consistency-locks.md	Any multi-section page	Color, shape, theme consistency per page
references/core/responsive-viewport.md	Layout or breakpoint changes	Canonical breakpoints, page containment, container queries, responsive images, safe area, split-screen
references/core/mobile-ux.md	Consumer/landing pages with mobile traffic	Thumb zone, touch targets, sticky CTA, mobile section composition, bottom sheet, portrait media
references/core/seo-baseline.md	Public-facing sites, SSR/SSG	SEO meta, JSON-LD, robots.txt, GEO strategies, OG/Twitter cards
references/core/a11y-patterns.md	Interactive widgets, modals, forms	ARIA patterns, focus management, keyboard nav, screen reader testing
references/core/performance-budget.md	Launch / audit	CWV targets, bundle budgets, font loading, image optimization, build gates
references/core/theme-switching.md	Dark mode / theme	CSS custom properties toggle, FOWT prevention, transition, component checklist
references/core/color-system.md	Color tokens, palettes wiring, theme-ready CSS	Token layering, oklch() + fallback discipline, color-mix(), light-dark(), Tailwind v4/shadcn wiring, contrast gates (verified 2026-07-07)
references/core/i18n-global.md	Multi-language / RTL	RTL layout, pluralization, Intl API, locale switching, content expansion
See also: dev-uiux-design skill	Vague requests, onboarding, UX states	Intent discovery, design isms, product personalities, onboarding/empty/error patterns
references/stacks/react.md	React projects	Server Components, hooks, state, TanStack Query, shadcn/ui, performance
references/stacks/nextjs.md	Next.js projects	App Router, RSC, image optimization, data fetching, middleware
references/stacks/vanilla.md	HTML+CSS+JS (no framework)	Zero-dependency, viewport fitting, responsive CSS, progressive enhancement
references/stacks/svelte.md	Svelte/SvelteKit projects	Svelte 5 Runes, SvelteKit 2 routing/actions, snippets, migration from Svelte 4
references/stacks/mobile-native.md	Native mobile app development	RN/Expo current pairing, Flutter 3.44, KMP, Swift 6, framework selection
references/stacks/astro.md	Astro projects	Islands architecture, multi-framework shell, content collections, SSG/SSR/hybrid

Start with anti-slop.md, aesthetics.md, responsive-viewport.md, and visual-verification.md. Add domain/locale/stack references only when relevant. For C2 ordinary app screens (form/table/list/detail), crud-ui.md alone suffices; add the style references above for marketing/visual surfaces or C3+ work.

• UI/rendering bug RCA: load dev-debugging.
• Build pipeline, bundle config, or deployment: load dev-devops.
• Project setup or file placement conventions: load dev-scaffolding.
• Data-driven dashboards, reporting views, or data format expectations: load dev-data.

When frontend choices depend on current framework, design-system, browser API, library behavior, or package/source freshness, follow dev §External Evidence and Recall Routing and load the search skill for current/external lookups.

Verification grounding

STRICT: For render/executable artifacts (HTML, SVG, games, UI, charts), run the real renderer: headless browser, screenshot, canvas check, or equivalent. Observe the actual output yourself, fix what observation reveals, then re-run. Static parsing confirms well-formed files; it does not prove the artifact is visually or interactively correct. One clean observation is enough for unchanged state; do not re-render unchanged output just to repeat evidence.

---

0. Frontend Routing

Before designing or coding, classify the work:

Decision	Options	Why It Matters
Product surface	landing, app, dashboard, AI tool, public service, education, game, creative	Sets density, typography scale, asset requirements
Locale	Korean-first, global/i18n, English-only	Sets CJK typography, copy, date/number formats
Density	campaign, consumer app, productivity, SaaS, ops, finance, developer console	Prevents landing-page composition inside repeated-work tools
Asset need	none, screenshot, product photo, diagram, chart, illustration, soft 3D, game asset	Prevents asset-free gradient/card UI
Soft 3D/character gate	not allowed, subtle, primary	Prevents generic cute 3D/mascot slop
Motion intensity	static, feedback-only, expressive, cinematic	Prevents cinematic motion in utility workflows

Default rules:

• For apps/tools/dashboards, build the actual working surface first, not a marketing hero.
• For Korean-first work, read korea-2026.md and ux-writing-ko.md.
• For any soft 3D miniature, mascot, chibi, toy-like object, or character-like asset, read soft-3d-asset-gates.md.
• For product/brand/object/place/person pages, use concrete visual assets in the first viewport.
• For finance, government, B2B, admin, auth, security, and developer tools, keep visual warmth restrained and subordinate to clarity.
• Every user-facing decision point must justify its existence — defaults first, one primary action per screen, choices demoted to progressive disclosure (cxc-dev-uiux-design UX-LAZY-01 owns the gate).
• For text-heavy surfaces (landing, marketing, editorial, public service), apply typography wrapping defaults — see typography-wrapping.md. Dashboard table cells are excluded.

---

1. Component Identification

When the user describes UI in vague terms (e.g. "접히는 거", "팝업 같은 거"):

1. Recommend the best-fit component with reasoning: <Name> — <what it does, why it fits>
2. Confirm, then proceed

If the user already names a specific component, skip this step. Reference: component.gallery/components

For new React/Vue/Svelte/Next UI source files, prefer .tsx or typed component files when the repo supports TypeScript. Inherit dev TypeScript strict-compatibility rules. If frontend structure is unclear, read existing source-of-truth docs first, then document pages, components, routes, state stores, and build commands in the repo's existing docs before broad implementation.

---

1.5 Objective Gates vs Style Samples

Two different kinds of rules live in this skill (see dev §0.2):

• Objective UX gates (STRICT/DEFAULT) — accessibility baseline (§7, §11), state coverage (loading/empty/error/permission), keyboard operability, visible focus, contrast. Missing these are review findings.
• Style direction (STYLE_SAMPLE) — design direction intake (§2), aesthetics, density profiles, product personalities, preset tokens, and the concrete values in §4-§5 (palettes, font choices, pixel max-widths). These illustrate acceptable choices; they are NOT requirements, must not override an existing design system (Design System Detection stays MANDATORY), and must never be enforced as universal taste (UX-STYLE-01).

2. Design Direction Intake

When the user cannot articulate a clear design direction, load dev-uiux-design first — it owns intent discovery and direction selection. This section validates and implements the chosen direction; it does not choose independently.

Before coding, validate the design direction from dev-uiux-design (or a concrete brief):

• Purpose: What problem does this interface solve? Who uses it?
• Surface: Is this a working tool, dashboard, public service, AI workflow, game, landing page, or editorial surface?
• Tone: Confirm the direction. For product tools this often means quiet, dense, trustworthy, and fast rather than loud.
• Constraints: Framework, performance budget, accessibility requirements.
• Signature: What ONE visual signature will make this unforgettable? (the signature moment; supporting scroll reveals may exist alongside it per motion.md FE-MOTION-BUCKET-01)

When user intent is vague ("깔끔하게", "모던하게", "just make it look good"), read the dev-uiux-design skill and run the User Intent Discovery Protocol before making routing decisions. If the user cannot answer these questions, use the dev-uiux-design skill's structured preference elicitation flow. Offer product references ("Notion 느낌? Linear 느낌?") and visual comparisons.

Concept pass before code (pointer — canonical: dev-uiux-design §2.5 UX-CONCEPT-GEN-01): for C2+ expressive or brand-visible surfaces, load dev-uiux-design §2.5 before implementation. It owns direction discovery, concept branching (open direction: 5 distinct isms → lock one → refine; concrete direction: 3-5 contextual variants), synthesis, and direction lock. Resume here after DESIGN.md is locked.

Intentionality over intensity. Bold maximalism, refined minimalism, dense utility, and friendly consumer UI can all work when they match the domain.

---

3. Baseline Configuration

Adjust these dials based on what's being built. Present to user if unclear.

Dial	Default	Range	Meaning
DESIGN_VARIANCE	5	1-10	1=symmetric utility, 10=asymmetric art
MOTION_INTENSITY	4	1-10	1=static, 10=cinematic choreography
VISUAL_DENSITY	5	1-10	1=art gallery airy, 10=cockpit dense

After Design Read, set dials per dev-uiux-design §2 Dial Setting.

Product density profile (D1-D8 in references/core/product-density.md) sets component class; VISUAL_DENSITY (1-10) sets spacing within that class. These are orthogonal axes.

Adapt dynamically based on user requests. Dashboard → density up. Portfolio → variance up. Data tool → motion down. Korean app/tool surfaces usually need higher density and clearer hierarchy, not oversized hero text.

---

4. Implementation

Read references/core/aesthetics.md for full guidelines. Summary:

• Typography: Use domain-appropriate typography. For Korean-first UIs, prioritize CJK-safe stacks before Latin display fonts. Apply text-wrap: balance on all headings AND short descriptors (hero subtitle, card description, caption — anything 1-3 lines). Use text-wrap: pretty only on body paragraphs (4+ lines). pretty has no effect on short text and will leave Korean orphans like "합니다." or "화." on a line alone. See typography-wrapping.md for full rules.

• Color: Max 1 accent. Use neutral bases (Zinc/Slate) with singular high-contrast accent — avoid purple-on-white. One-note means the ENTIRE page is dominated by variations of a single hue family. One accent color with neutral bases is correct, not one-note.

• Layout: Match the product surface. Avoid centered-card/hero patterns in repeated-use tools.

• Motion: See references/core/motion.md. One signature moment + a few supporting reveals > 10 scattered effects; landing-bucket floor/ceiling per FE-MOTION-BUCKET-01.

• Assets: Use screenshots, product images, diagrams, charts, illustrations, generated bitmaps, or soft 3D only when they add product meaning. Never ship a placeholder. Prefer real/generated image or video assets over CSS gradient washes. Read any design reference or captured screenshot back into context with view_image before matching it. Third-party captures follow reference-capture.md (analysis-only, provenance manifest).

  1. Probe: ima2 status → ima2 serve if down → recheck.
  2. Generate: ima2 gen with explicit long prompts; --ref for style anchors.
  3. Inspect: view_image every candidate.
  4. Synthesize: element ledger per FE-ASSET-SELECT-01.
  5. Iterate: ima2 edit for targeted fixes.
  6. Verify: browser screenshot of rendered result.

  Fallback: $imagegen only when ima2 is truly unavailable.

  ima2 supports multi-candidate generation (-n N, multimode, and independent CLI parallel; FE-ASSET-PARALLEL-01), prompt builder, session style sheets, and provider routing (GPT/Grok/Gemini; FE-ASSET-PROVIDER-01). Monitor parallel jobs with ima2 ps --json and cancel unwanted jobs with ima2 cancel <id>. For motion assets, use ima2 video under FE-MOTION-VIDEO-01. Prompts must specify subject, composition, palette, lighting, style, and aspect per asset-requirements.md.

  Concept mockups guide implementation and are not shipped; production assets require candidate inspection and selection; cutout assets additionally follow FE-ASSET-BG-01.

• Visual verification: exercise the changed flow using the available capability selected by dev/references/browser-routing.md and dev-testing §4.7. Read rendered output and verify the interaction; no single optional browser is mandatory.

Icon Implementation (FE-ICON-01, DEFAULT)

• Library route: install @phosphor-icons/react by default. Use iconoir-react, @untitledui/icons, @hugeicons/react, or lucide-react only when the Design Read selects Iconoir, Untitled UI, Hugeicons, or Lucide respectively; confirm the exact package and license before installation.
• Custom route: generate the approved icon artwork with ima2 icon, trace it with vtracer, optimize the SVG with svgo, then convert it with svgr when a React component is required. Preserve an editable source asset and inspect both the SVG and rendered component before shipping.
• Layer consistency: use one library per icon layer. Do not mix Phosphor navigation with Lucide content icons; a separate custom/premium domain layer is allowed only when it is deliberately art-directed as a layer.
• Weight semantics: regular is the default state, fill indicates selected or active state, and duotone is reserved for empty states or illustrative emphasis. Keep size, optical weight, color behavior, and accessible labels consistent.

Cutout Asset Generation (FE-ASSET-BG-01 surface — STRICT)

Every cutout asset MUST follow references/core/asset-requirements.md § Asset Background Strategy; load it with ima2 skill front ref asset-requirements when ima2 is available.

5. Anti-Slop Enforcement

Rule classes (dev §0.2): items below are DEFAULT — deviate with a stated reason; concrete values and palettes are STYLE_SAMPLE (§1.5); the emoji-as-UI-icon ban is the only STRICT item.

Read references/core/anti-slop.md for full rules. Key standards:

Award examples do not establish universal taste rules. Use the shipped design-trends reference and reopen its sources; explain the product-specific role and preserve accessibility. No private goalplan is required to justify a design decision.

Hero discipline (FE-HERO-01)

• First viewport must fit: hero content leaves a hint of the next section on mobile and desktop.
• Keep hero copy to ~4 text elements max: headline, subhead, primary CTA, one proof/context line.
• Do not put trust strips, pricing teasers, feature bullets, or mini dashboards inside the hero.
• Logo walls belong below the hero, not as hero filler.
• Plan font scale with image/product scale so neither crushes the other.

Before delivery, run the second-order reflex test (FE-REFLEX-TEST-01, anti-slop.md) against both the obvious category default and its fashionable opposite. Audit composite convergence tells under FE-CONVERGENCE-01 (anti-slop.md): hairline border+shadow, icon-tile-above-heading, italic-serif-hero, hero-metric template, and other multi-element compositions.