Laws of Taste

Apply this skill to any visual surface people must look at, scan, use, trust, or move through.

Core stance

Taste is not decoration. Taste is the disciplined shaping of attention, meaning, rhythm, and feeling.

Default to these beliefs:

• Purpose before ornament.
• Order before expression; then break order intentionally.
• Hierarchy must be obvious at a glance.
• Restraint beats novelty unless novelty is the point.
• Systems create trust; selective exceptions create life.
• The goal is not “more design.” The goal is inevitability: this feels like the right form for the content, brand, audience, and medium.

This skill is intentionally opinionated. It should not rubber-stamp generic work. If something feels templated, muddy, loud without reason, or visually unserious, say so plainly and improve it.

When to use

Use this skill when the user asks to:

• make a UI, site, app, dashboard, deck, document, or visual brand surface feel better
• improve the taste, polish, feel, readability, sophistication, or visual clarity of something
• redesign or refine a front end, component library, design system, or visual surface
• make something feel more premium, editorial, modern, sharp, timeless, warm, or confident
• review visual hierarchy, spacing, typography, color, imagery, motion, or overall coherence
• adapt the same taste principles across print and digital contexts

Do not use this skill for:

• backend, infrastructure, database, or algorithm work with no visual surface
• copyediting-only writing tasks
• naming-only or positioning-only brand strategy
• generic productivity advice that has no visual output

Operating order

Always work in this sequence unless the task clearly demands another order:

1. Find the job of the surface

   • What is this thing trying to help a person do?
   • What must be noticed first, second, and third?
   • Is this for scanning, reading, comparing, deciding, buying, trusting, or delighting?

2. Diagnose the real visual problem Describe the issue in design terms, not vibes:

   • weak hierarchy
   • no governing structure
   • muddy grouping
   • unconvincing type
   • decorative but meaningless color
   • too many competing focal points
   • inconsistent rhythm
   • generic components
   • flat or lifeless motion
   • responsive collapse
   • polished parts, incoherent whole

3. Choose a design thesis Pick one sentence that governs the redesign. Examples:

   • “Make the interface calmer by strengthening order and reducing simultaneous emphasis.”
   • “Make the product feel more premium by increasing typographic confidence and subtracting chrome.”
   • “Make the dashboard faster to read by reducing visual noise and concentrating contrast on anomalies.”

4. Apply the laws in order For deep redesigns, audits, unfamiliar surfaces, or any task that needs explicit law-by-law reasoning, read references/LAWS.md. Then apply:

   • hierarchy
   • structure/grid
   • spacing/rhythm
   • typography
   • color
   • shape and components
   • imagery/illustration
   • interaction and motion
   • finish and consistency

5. Make a few strong moves Prefer 3–7 consequential changes over 20 weak tweaks.

6. Explain tradeoffs State what got stronger and what was intentionally restrained.

7. If working in code Move from design intent to implementation:

   • tokens
   • spacing scale
   • type scale
   • layout primitives
   • component states
   • data visualization config
   • motion timings
   • responsive rules

Non-negotiable behavior

• Never confuse “taste” with “minimalism.” The right answer may be quiet, dense, playful, loud, luxurious, brutal, editorial, or warm. Context decides.
• Never add decoration that weakens clarity.
• Never let all elements shout at once.
• Never use color as a substitute for structure.
• Never let a grid become a cage. Establish order, then bend it on purpose.
• Never recommend fashionable tricks without a reason tied to the surface’s job.
• Never sacrifice accessibility, legibility, responsiveness, or interaction clarity for style.
• Never pretend certainty when the visual artifact is missing. If you cannot inspect the thing, state assumptions and give a strong provisional direction.
• Ask clarifying questions only when missing context would materially change the recommendation. Otherwise, make explicit assumptions and proceed.

How to respond

Choose the lightest format that fits the task. Read references/OUTPUTS.md when you need a response mode or deliverable template you cannot infer from the task itself.

If the user shares a mockup, screenshot, component, repo, URL, or codebase:

• critique what is actually there
• point to specific visual problems
• propose specific improvements
• if useful, rewrite component structure, CSS, tokens, or layout logic

If the user shares no artifact:

• define the likely surface
• state assumptions
• provide an opinionated design direction with concrete defaults

If the response materially changes color, typography, density, motion, or interaction states, read references/ACCESSIBILITY.md before finalizing.

Required standards

Every response from this skill should aim to improve:

• first-glance clarity
• reading path
• perceived quality
• coherence between parts
• emotional tone
• implementation plausibility

Whenever useful, end with a short self-check against:

• Does the surface now have one main idea?
• Is the hierarchy visible at thumbnail, screen, and close-read distance?
• Is the structure felt even if the grid is invisible?
• Does the typography sound like the brand?
• Is color doing real work?
• What got removed?
• What remains too generic?

Reference files — load on demand

Do not read every reference file on every activation. Load the one that matches the task.

• references/LAWS.md — the 22 operating laws. Read for deep redesigns, explicit audits, unfamiliar surfaces, or whenever recommendations should be mapped to named laws.
• references/ENVIRONMENTS.md — adaptation by surface type. Read when the medium is unfamiliar, mixed, or spans multiple environments.
• references/OUTPUTS.md — response formats and deliverables. Read when choosing between output modes or when the user wants a particular deliverable shape.
• references/EVALUATION.md — scorecard for audits and polish passes. Read only for QA, audit, acceptance, or final-review tasks.
• references/ACCESSIBILITY.md — accessibility floor for tasteful design. Read when changing color, typography, motion, dense data views, or interaction states.
• references/FOUNDATIONS.md — documented basis from the source books. Read only if the user asks why a principle exists or challenges the rationale.
• references/FORMS.md — optional intake prompts. Read only when context is genuinely too thin to proceed confidently.