frontend-design

name	frontend-design
description	Applies UI design patterns, typography, color, and component styling for M8.Industries. Use when: adding/modifying components, changing layout, styling new sections, touching globals.css, working with primitives, or any visual change to the site.
allowed-tools	Read, Edit, Write, Glob, Grep, Bash

Frontend Design — M8.Industries

Industrial dark-tech marketing site for a CNC/3D-print shop. The aesthetic is deliberate: blueprint-grid background, tight negative letter-spacing on headings, JetBrains Mono for all metadata/labels, a single steel-blue accent (#6f8aa8), and spark-particle animation on the hero. Every visual decision reinforces the precision-manufacturing identity. Do not dilute it.

Before You Code (REQUIRED)

This skill's content was captured at generation time and MAY be stale. For ANY non-trivial change involving frontend-design, verify against current docs FIRST:

Then:

1. Match the installed version. Cross-reference against the version installed in this repo. APIs change across minor versions; do not assume.
2. Discover provider best practices. If the task touches a production-sensitive capability, inspect the provider service catalog, official docs, and project docs before choosing an implementation.
3. Respect explicit direction. If the user explicitly asks for a specific mechanism, follow it. If project docs clearly mandate a mechanism, follow the project. In both cases, mention the provider-recommended alternative and make the chosen path safe.
4. Prefer provider-native primitives by default. If no explicit user/project override exists and the change involves caching, rate limiting, background work, scheduled jobs, shared state, queues, or secrets, use the provider-recommended binding/API. Do not hand-roll an in-memory or polyfill solution that "works" locally but breaks under the provider's execution model — derive the need→native-primitive mapping yourself from this provider's docs.

Skill Advantage Protocol

Using this skill should produce a meaningfully better result than an unskilled baseline. Apply this loop before and during implementation:

1. Clarify only when it changes the outcome. Ask the smallest useful set of questions when the request is ambiguous, preference-heavy, or could change architecture, user-visible behavior, data shape, security posture, analytics, or external side effects. If the safe assumption is obvious, state it and proceed. When asked to surface data that no existing code path captures, state up front the assumption that capture starts now (no backfill) or ask if a backfill source exists — do not silently build net-new storage without surfacing this.
2. Inspect the nearest real patterns. Read adjacent files, routes, components, tests, schema, infra, copy, and analytics surfaces before inventing structure. Treat local conventions as the starting point.
3. Optimize the task's highest-leverage axis. Identify what would make the result win a review: user-visible correctness, integration quality, accessibility, security, reliability, maintainability, operability, or speed of future change.
4. Reuse before reimplementing. Prefer existing components, hooks, helpers, formatting/utility functions, data registries, metadata builders, analytics, pricing, checkout, auth, routing utilities, and API procedures/endpoints/data sources over local one-off clones. Before adding a new API procedure, query, or data fetch, search for one that already returns this data and extend it in place — a surface that fetches data and only logs or partially uses it is a reuse target, not an absent one; never author a parallel endpoint or leave the original orphaned. Before importing for a data fetch, grep the screen for the call it already makes and reuse that exact client/singleton import path and endpoint/procedure name; never create a second client, transport, or parallel endpoint for data an existing call returns, and confirm every imported path and symbol actually exists in the repo before writing it.
5. Use semantic structures. Tables, lists, forms, buttons, links, headings, and disclosure controls should use native/project accessible primitives instead of div-only lookalikes.
6. Prevent drift by construction. Centralize repeated facts, labels, claims, product defaults, and shared table cells in registries or helpers when multiple surfaces need the same answer.
7. Synthesize, do not merely comply. Combine this skill's guidance with repo evidence and the user's goal. When two good approaches exist, borrow the strongest parts of each instead of blindly choosing one.
8. Check claims against code. Product copy, docs, and comments must not imply automation, integrations, performance, security, refresh cadence, counts, or data flow that the implementation does not actually provide. Any claim that one component writes, records, updates, calls, or is the source of truth for another is allowed only if the edit performing it is in this same change; before finishing, check each such cross-component claim against the actual edits and downgrade unbacked ones to an explicit TODO or implement them now.
9. Ship the complete slice. Include every adjacent artifact needed for the change to be usable and maintainable: wiring, state handling, validation, analytics, tests, docs, migrations, or infra when those surfaces are part of the behavior. When the task shows, displays, or lists user data, deliver the full vertical slice and do not stop at an internal/API/CLI layer: the data-model/schema change AND its migration (a schema change without a migration is incomplete), the path that writes or populates the data, an authenticated endpoint scoped to the current user, and the primary user-facing surface wired through the project's typed data client. Before declaring done, trace one record end-to-end (triggering event → write → read → render); if any hop exists only in a comment or docstring rather than edited code, the slice is NOT done. Shipping only the persistence layer (a schema/migration with no writer, reader, or surface) is an incomplete slice, not a milestone.

Capability Contract

Use this section when the user prompt touches production risk, even if the prompt does not name this technology explicitly.

Required wiring surfaces:

• provider/runtime configuration discovered during implementation
• nearest typed request/context boundary
• handler/procedure boundary before external side effects

Side-effect barrier:

• Place guards before external APIs, auth mutations, email sends, analytics events, storage writes, and database mutations.

Fallback policy:

• Prefer provider-native/platform-managed primitives by default when no explicit override exists.
• Follow clear user/project overrides, but mention the native alternative and tradeoff.
• Fallbacks must be durable, multi-instance safe, and atomic under concurrency.

Verification rules:

• [error] native-or-explicit-override: Use the provider-native primitive first unless the user/project explicitly overrides it.
• [error] atomic-fallback: Fallback counters must be atomic under concurrency.

Design Direction

Pick a clear visual direction from the product context before writing styles. The direction must fit the target surface (unknown) and the repo's actual UI vocabulary, not a generic AI-looking template. A SaaS dashboard should usually feel dense, quiet, and fast to scan; a marketing page can be more memorable; an Ink/CLI view should prioritize stable layout, truncation, and keyboard clarity.

Interface Quality Bar

• Make the interface feel intentionally designed for this repo, not assembled from interchangeable cards and gradients.
• Use distinctive choices only when they serve the surface; restraint is a design choice when the product is operational or data-heavy.
• Avoid AI slop: random purple/blue gradients, unrelated glass panels, oversized hero typography inside tools, fake depth, decorative noise with no product meaning, and one-note color palettes.
• Keep text, icons, states, and layout aligned with the user's actual workflow.

Component System Fit

• Styling system: the styling system discovered in this repo.
• Component primitives/libraries: the existing component primitives.
• Real UI surfaces to inspect first: the nearest real screen, component, or interactive surface.
• Reuse local tokens, spacing, border radii, density, icons, and interaction patterns before creating new primitives.

Responsive + State Coverage

• Cover loading, empty, error, disabled, pending, success, and recovery.
• Keep layouts stable for long labels, long data values, narrow mobile widths, and wide desktop.
• For interactive elements, verify labels, focus states, keyboard flow, semantics, and contrast.

Visual Anti-Patterns

• Do not copy a generic design-skill template or repeat the same aesthetic across projects.
• Do not introduce a new brand palette, font stack, shadow system, animation language, or card style unless it matches repo evidence or the user explicitly asks.
• Do not make dashboards look like landing pages, or landing pages look like admin tables.

Verification Checklist

• Nearby components/screens were inspected.
• Visual direction matches the target surface and product context.
• Responsive behavior, overflow, empty/loading/error/disabled states, and accessibility basics were checked.
• Any generated example uses real repo files/symbols from the evidence pack or is labeled as new code to add.

Quick Start

Using Design Tokens

/* GOOD — uses token system */
.panel {
  background: var(--bg-card);
  border: 1px solid var(--line);
  color: var(--ink-dim);
}

/* BAD — hardcoded hex breaks theming and drift-checks */
.panel {
  background: #141a21;
  color: #9aa6b2;
}

New Section Structure

// new code to add — matches section pattern across the codebase
export default function MySection() {
  return (
    <section>
      <div className={styles.section}>  {/* 1280px max-width, 80px 32px padding */}
        <SectionTag n={4} total={4} label="LABEL" />
        <h2 className={styles.h2}>Heading</h2>
      </div>
    </section>
  );
}

Key Concepts

Concept	Rule	Source
Color	Always var(--token) — never raw hex	app/globals.css
Display font	var(--font-display) = Space Grotesk	app/layout.tsx
Mono labels	.mono utility class = JetBrains Mono, 11px, uppercase	app/globals.css
Component styles	CSS Modules — Component.module.css co-located	per component
Single breakpoint	@media (max-width: 860px) — in globals, not per-module	app/globals.css
Fluid headings	clamp() on h1/h2/h3 — never fixed px on headings	per module

Common Patterns

Spec Row

<SpecRow k="Spindle" v="24 000 rpm" />
<SpecRow k="Travel" v="300 × 200 × 45 mm" last />

Section Counter

<SectionTag n={2} total={3} label="CAPABILITIES" />

Mono Chip

/* from Capabilities.module.css — capability tags */
.chip {
  padding: 5px 10px;
  border: 1px solid var(--line-strong);
  border-radius: 3px;
  font-family: var(--font-mono);
  font-size: 11px;
  color: var(--ink-dim);
}

See Also

• aesthetics — color tokens, typography, visual identity
• components — CSS Modules, primitives, composition
• layouts — grid, spacing, breakpoints
• motion — CSS animations, SparkField, reduced-motion
• patterns — DO/DON'T pairs, anti-patterns

Related Skills

For React patterns, see the react skill. For Next.js static export behavior, see the nextjs skill. For strict TypeScript usage, see the typescript skill.