| 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 — `
` 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.
