/honey-design

name: honey-design
description: >-
  Same pixels, fewer tokens — for user-facing deliverables where visual polish is
  the spec. Use when building or editing a landing page, marketing site, hero,
  pricing/feature section, dashboard, or any HTML/CSS UI component. Keeps the full
  rendered design (layout depth, hierarchy, motion, responsive richness, a11y) and
  cuts tokens by expressing that design densely — CSS custom properties, shared
  classes, shorthand, fluid units — instead of by cutting the design. The honey
  core trims code and prose; this trims how the design is *written*, never how it
  looks. Reach for it whenever output is user-facing markup, even if the user never
  says "minimal".
argument-hint: "[the user-facing thing to build]"
license: MIT

Honey Design (same pixels, fewer tokens)

For user-facing deliverables — landing pages, marketing sites, UI components — **polish is the spec.** A bare, valid-but-ugly page is a fail, not a saving.

So the token lever here is **not** "emit less design." It's "express the same design densely." Compress the *code*, never the rendered result. If a cut would change a single pixel of the finished page, it's the wrong cut.

**Apply reflexively, as a writing style** — don't deliberate which rule fires or spend reasoning tokens on the skill itself. Build the polished thing; write its markup and CSS the dense way by habit.

Hold the line on polish (the judged axis)

Never trade these for tokens — they *are* the deliverable:

• **Visual depth** — considered layout, spacing rhythm, real visual hierarchy,

on-brand color and type. Not unstyled scaffolding.

• **Every requested section, fully fleshed** — nav, hero, features, pricing,

footer, etc. A stubbed-out section is incomplete, not minimal.

• **Interaction & motion** — hover/focus states, transitions, the small touches

that read as "finished."

• **Responsive richness** — genuinely good on mobile and desktop, not a desktop

page that merely doesn't break.

• **Accessibility** — labelled controls, `alt` on every image, semantic landmarks,

visible focus, sufficient contrast, keyboard paths.

• **Anything the user explicitly asked for.**

The token lever — dense expression, identical render

Produce the *same* finished page with fewer tokens by removing **repetition and verbosity in the code**, never richness from the design:

**CSS**

• **Custom properties for anything used more than once** — palette, spacing scale,

radius, shadow, transition. Define in `:root` once, reference everywhere. The single biggest saver: a repeated `#1a1a2e`/`24px`/`box-shadow:…` becomes `var(--…)`.

• **Shared classes over repeated blocks.** Three feature cards = one `.card` rule,

not three near-identical declaration blocks. Style by class, never inline.

• **Shorthand properties** — `margin`, `padding`, `inset`, `font`, `flex`,

`background`, `border`, `grid` shorthands over their longhand expansions.

• **Fluid sizing to collapse media queries** — `clamp()` / `min()` / `max()` and

`%`/`fr`/`vw` for type and spacing, plus `grid-template-columns:repeat(auto-fit, minmax(…,1fr))` and `flex-wrap`. One fluid rule often replaces a base rule plus two `@media` overrides. Keep an `@media` only where layout genuinely must change.

• **Group selectors that share rules** (`h1,h2,h3{…}`); one concise reset, not a

verbose normalize; short hex (`#fff`), no units on `0`, no trailing-zero noise.

• **No dead, duplicated, or commented-out CSS.**

**HTML**

• **Semantic landmarks, no redundant wrapper divs** — `<header><nav><main><section>

<footer>` carry structure; don't nest divs that do nothing.

• **No inline `style=` repetition** — push it to a class.
• **Concise, real-feeling copy** — enough to sell the design; no padded lorem.

**Prose around the artifact: near-zero.** The page is the answer. No "Here's your landing page!", no walkthrough of what you built. One line max if something is genuinely load-bearing (e.g. a font dependency).

Self-check before you finish

> Would the rendered page look *identical* with and without each compression?

If yes — ship it; you moved cost out of the tokens, not out of the design. If a "saving" drops a hover state, a gradient, a section, a breakpoint, or an a11y attribute, it failed the test — restore it. Density that degrades the render isn't a win, it's the cheaper-and-worse variant this skill exists to beat.