design

Invoke when building any UI, component, page, or visual interface. Produces distinctive design with a committed aesthetic, not generic defaults. Not for backend logic or data pipelines.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "design" with this command: npx skills add tw93/waza/tw93-waza-design

Design: Build It With a Point of View

Prefix your first line with 🥷 inline, not as its own paragraph.

If it could have been generated by a default prompt, it is not good enough.

Lock the Direction First

Before writing any code, use AskUserQuestion:

  1. Who uses this, and in what context? Analyst dashboard differs from landing page or onboarding flow.
  2. What is the aesthetic direction? Name it precisely: dense editorial, raw terminal, ink-on-paper, brutalist grid, warm analog. "Clean and modern" is not a direction.
  3. What is the one thing this leaves in memory? A typeface, color system, unexpected motion, asymmetric layout. Pick one and make it obvious.
  4. What are the hard constraints? Framework, bundle size, contrast minimums, keyboard accessibility.

Do not proceed until all four are answered. State the chosen direction in one sentence. Then load references/design-reference.md and check the tech stack conflicts table. Name the single CSS strategy before writing the first component.

Before writing any code, write three things:

  • Visual thesis: one sentence describing mood, material, and energy (e.g. "warm brutalist editorial with high-contrast ink type and rough paper texture")
  • Content plan: hero → support → detail → final CTA, one line each
  • Interaction thesis: 2-3 specific motion ideas that change how the page feels (e.g. "hero text slides in on load, section headers pin while content scrolls beneath, CTA pulses on hover")

For app/dashboard surfaces (not landing pages): skip the marketing structure. Default to utility mode: orient the user, show status, enable action. No hero section unless explicitly requested. Every heading should name what the user can do or see, not what the product promises.

Non-Negotiable Constraints

  • Typography: no Inter, Roboto, or system-ui as the primary display typeface. They are invisible and communicate nothing. Pick something with personality.
  • Color: one color owns the page, one or two accents that cut against it. Spreading evenly across the palette is the undesigned choice.
  • Motion: entrance 200-400ms ease-out, exits 150-250ms ease-in. Ship at least 2-3 intentional motions for visually led work: one entrance in the hero, one scroll-linked or sticky effect, one hover or reveal that sharpens affordance. If removing the animation changes nothing about how the page feels to use, remove it.
  • Layout: default to cardless sections. If removing border, shadow, and background from a container doesn't hurt understanding or interaction, it is not a card.
  • Backgrounds: mesh gradients, subtle noise, geometric texture, layered depth. Flat white or flat black is rarely the right choice.
  • Spatial composition: asymmetry, overlap, diagonal flow, or grid-breaking elements. Symmetric center-stacked layouts are the undesigned default.
  • Variety: never repeat the same typeface, palette direction, or layout pattern across projects. If the last design was dark with Space Grotesk, this one cannot be.
  • Accessibility baseline: honor prefers-reduced-motion, visible focus states on all interactive elements, alt on all images.
  • Complexity match: maximalist visions need elaborate animation code; minimalist ones need precision in spacing and typography. Do not apply the same level of effort to both.

Gotchas

What happenedRule
Used Inter as the display fontIt communicates nothing. Pick something with a personality.
Three cards, identical shadows, identical padding -- a templateIf swapping content doesn't require layout changes, redo it.
Claimed it looked right without opening a browserCode correct in your head can look broken in the browser. Open it.
Chose glassmorphism, ignored the mobile constraintbackdrop-filter is expensive on low-power devices. Name the tradeoff.
Colors that "go with everything" go with nothingCommit to a dominant color plus one sharp accent.
State transitions jittered because element sizes changed per stateAll states must occupy the same layout footprint; use min-height or fixed dimensions.
Brand disappeared when the nav was hiddenBrand test: if the first viewport could belong to another brand after removing the nav, the branding is too weak.
Copy-heavy hero that nobody readsIf deleting 30% of the copy improves the page, keep deleting. Each section gets one job: explain, prove, deepen, or convert.
Dashboard built like a marketing pageApp/dashboard surfaces need utility copy and a working surface first. No hero section by default.
Every project ended up with the same lookVary light/dark, serif/sans, dense/spacious. If it could have been the last project, it is not designed for this one.

Handoff

Run these litmus checks before writing the handoff summary:

  • Is the brand or product unmistakable in the first screen?
  • Is there one strong visual anchor (real imagery, not a decorative gradient)?
  • Can the page be understood by scanning headlines only?
  • Does each section have one job?
  • Are cards actually necessary, or just default styling?
  • Does motion improve hierarchy or atmosphere, or is it ornamental?
  • Would the design still feel premium if all decorative shadows were removed?

If any check fails, fix it first. Then reload references/design-reference.md and check the common traps list. Then ask the user to open the result in a browser and confirm it looks right at full width. Also check at 375px width: resize the browser or use DevTools device emulation. If the layout breaks, content overflows, or text is unreadable at mobile width, fix it before handing off. Do not hand off until both checks pass.

End with:

  • Aesthetic direction, named and justified in 2-3 sentences
  • Non-obvious choices explained: typeface, color decisions, layout logic
  • Instructions for replacing placeholder content with real content

After handoff, stop. Do not iterate unless the user requests changes.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

health

No summary provided by upstream source.

Repository SourceNeeds Review
2K-tw93
General

write

No summary provided by upstream source.

Repository SourceNeeds Review
386-tw93
General

think

No summary provided by upstream source.

Repository SourceNeeds Review
385-tw93
General

read

No summary provided by upstream source.

Repository SourceNeeds Review
382-tw93