# Futurism Design > Apply the Futurism Design System — a Paper-Futurist web aesthetic (bold italic display type, a single red accent, square corners, solid offset shadows, and fast directional motion) with paired light and dark themes. Use this skill whenever the user asks to build, style, or restyle any web UI — a page, component, landing hero, dashboard, form, or full app — AND wants it to follow the Futurism look, OR invokes /futurism-design, OR references "futurism", "futurist", "paper futurism", "the red/cream design", or "our design system" in this repo. Trigger it even when the user only says "make a page" or "build a component" in a project that has adopted this system, so the output stays on-brand instead of defaulting to generic styling. This is an explicit, web-only design language — do not use it for terminal/CLI output. - Skill: `stoica-mihai/futurism-design` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add stoica-mihai/futurism-design` - Raw SKILL.md: https://api.skillmd.com/api/skills/stoica-mihai/futurism-design/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: Stoica-Mihai (https://skillmd.com/u/stoica-mihai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/stoica-mihai/futurism-design --- # Futurism Design System A web design language: **Italian-Futurist energy, restrained editorial execution.** Motion, diagonals, one red, bold italic display — on warm paper (light) or warm carbon (dark). Use this skill to produce UI that obeys the system instead of generic AI styling. The look is fully specified; your job is to apply it faithfully. ## How to apply 1. **Reuse the stylesheet — do not re-derive it.** The complete kit lives in `assets/futurism.css`. Link or inline it; never hand-rewrite the tokens or component CSS. Behaviour for interactive parts is in `assets/futurism.js`. 2. For a single self-contained file (artifact, demo), inline both assets. 3. For a project, copy `assets/futurism.css` + `assets/futurism.js` in and import them once at the root. Both headers carry a **version stamp** — keep it in the vendored copy. To check for or apply an upgrade, compare that stamp against the plugin's `CHANGELOG.md` (one line per version) and read only the newer entries — don't diff the kit files; a kit update is a wholesale re-vendor either way. 4. When you need exact values or component markup, read the references: - `references/tokens.md` — color/spacing/type/motion tokens + the `:root` and `[data-theme="dark"]` blocks. - `references/components.md` — copy-paste HTML for every component, with the classes and the small JS hooks they need. 5. Default theme is **light**. Enable dark by setting `data-theme="dark"` on the root element (``); call `fdTheme()` to flip it. ## The eight laws These are what make output read as *this* system rather than a red-tinted generic site. Break one and the aesthetic collapses, so hold them unless the user explicitly overrides: 1. **Square corners always.** `border-radius: 0`. The system has no rounding — the tension between hard rectangles and skewed type is the point. 2. **Solid offset shadows, never blur.** `box-shadow: 6px 6px 0 var(--shadow)`. A blurred shadow instantly reads as Material/SaaS, not Futurism. *Gotcha 1:* the offset shadow is **clipped by any `overflow:auto/hidden` ancestor**. Keep the shadowed element's scroll container at `overflow:visible` and move the scroll inward (this is why the modal sets `dialog{overflow:visible}` and scrolls inside `.modal`). *Gotcha 2:* in dark, `--shadow` follows the accent, so an **accent-filled control must throw an ink shadow, not `--shadow`** — an accent shadow under an accent fill is the same hue and smears into one blob. Surfaces (cards/modals on `--surf`) are fine with `--shadow`; only same-hue fills need the override (see `.btn-primary:hover`). *Density & scale:* the offset follows surface weight — **10px** hero (modal), **6px** default (card, popovers), **4px** dense/stacked (already kit vocabulary: `.btn.ok`, `.tip`). Color scales with density too: the dark accent shadow is right for a *singular* surface but a scrolling stack of repeated shadowed cards floods the screen red and buries the one legitimate accent moment (an error card) — so **repeated siblings in a list use `4px 4px 0 var(--shadow-mute)`** (ink in light, true carbon in dark); the accent shadow stays reserved for singular surfaces. 3. **2px ink borders** on surfaces and controls — structure is drawn, not implied by elevation. 4. **One accent only.** Red (`--accent`) carries links, CTAs, rules, highlights. Adding a second hue dilutes the manifesto. If you need differentiation, use ink vs. red vs. outline, not new colors. To show a **scale or ordinal range** (DPI low→high, weak→strong), use a single-hue **intensity ramp** (`linear-gradient(90deg, var(--muted), var(--accent))`) — never a rainbow blue→red gradient or a set of multi-hue swatches. And don't hand-roll multi-color "category" chips: a single-select set is `.seg`, a static tag is `.badge.out`. Status follows the same discipline: **ink = done/committed, accent = error/attention/live, muted = idle/disabled** — never a green success or an amber warning (success rides the label: "SAVED ✓"; urgency rides blink rate, see `.dot.warn`). Budget the accent per view: **one accent-filled CTA per bar or view region** — when everything points red, nothing does. *Two-step confirm is a **state**, not just the `.row-act` widget.* The idle → armed → confirmed flow (auto-disarm on timeout, Esc, or outside-click) rides this same discipline — **ink/muted at rest → accent when armed**, the armed step being the attention moment — and is reusable independent of the row chrome. `fdConfirm` is the row-bound realization; for a destructive **toolbar button, menu item, or keyboard-triggered action**, drive the same arm-state and swap the label (armed = accent "sure?"/"Confirm X") rather than misusing `.row-act` or firing a bare native `confirm()`. 5. **Motion is machine, not toy.** Fast (`--fast: .12s`), medium (`--med: .2s`), easing `cubic-bezier(.2,.9,.1,1)`, and always **directional** — things slide, dart, lurch, march. Never spring, bounce, or fade-puff. Respect `prefers-reduced-motion` (the CSS already does). *Narrow carve-out:* `--ease` is for **discrete state transitions** (open/close, hover, armed/refreshing). A value **live-tracked to a pointer every frame** — not a state transition — is exempt: `.pull-fill`'s width uses `transition:width 60ms linear` because a cubic-bezier visibly lags a 1:1 finger-tracked drag (and `.pull`'s height gets the same treatment via the `.pulling` class fdPull toggles during the drag — `--ease` resumes on release). Don't generalize this to anything that isn't following a pointer in real time. 6. **Skewed CTAs.** Primary actions use `transform: skewX(-8deg)` with the label counter-skewed (`skewX(8deg)`) so it stays upright. This is the speed cue. *Reserve the skew for standalone/hero CTAs and rows of skewed siblings* (a confirm+cancel pair, a button group) — there the parallel slants read as deliberate. A lone skewed button sitting **flush against a square element** (an input+action group, one action in a square toolbar) makes an awkward wedge gap against the straight edge: use a **square affordance** there — `.btn-square` (un-skewed `.btn`), `.iconbtn`, or a welded group — so edges align. 7. **Never trust native form popups.** ``s, and the modal is a real `