honey-design

# 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 ...