diff --git a/docs/README.skills.md b/docs/README.skills.md
index 7d39a9ab0..afc48f6c5 100644
--- a/docs/README.skills.md
+++ b/docs/README.skills.md
@@ -165,6 +165,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [debian-linux-triage](../skills/debian-linux-triage/SKILL.md)<br />`gh skills install github/awesome-copilot debian-linux-triage` | Triage and resolve Debian Linux issues with apt, systemd, and AppArmor-aware guidance. | None |
 | [declarative-agents](../skills/declarative-agents/SKILL.md)<br />`gh skills install github/awesome-copilot declarative-agents` | Complete development kit for Microsoft 365 Copilot declarative agents with three comprehensive workflows (basic, advanced, validation), TypeSpec support, and Microsoft 365 Agents Toolkit integration | None |
 | [dependabot](../skills/dependabot/SKILL.md)<br />`gh skills install github/awesome-copilot dependabot` | Comprehensive guide for configuring and managing GitHub Dependabot. Use this skill when users ask about creating or optimizing dependabot.yml files, managing Dependabot pull requests, configuring dependency update strategies, setting up grouped updates, monorepo patterns, multi-ecosystem groups, security update configuration, auto-triage rules, or any GitHub Advanced Security (GHAS) supply chain security topic related to Dependabot. For pre-commit dependency vulnerability scanning in AI coding agents via the GitHub MCP Server, this skill references the Advanced Security plugin (`advanced-security@copilot-plugins`). Use this skill when an agent needs to scan dependencies for known vulnerabilities before committing. | `references/dependabot-yml-reference.md`<br />`references/example-configs.md`<br />`references/pr-commands.md` |
+| [design-taste](../skills/design-taste/SKILL.md)<br />`gh skills install github/awesome-copilot design-taste` | Apply senior designer judgment to any frontend UI — React, HTML/CSS, Framer, or any web component. This skill is the result of hands-on research into what actually works and what doesn't when giving AI agents design judgment: not theoretical guidelines, but principles battle-tested through real projects and iteration on AI-generated output. Use it whenever the user is building, reviewing, or iterating on UI code and design quality matters. Triggers include: creating components or pages, reviewing existing UI, asking for design feedback, building dashboards or data displays, refining visual hierarchy, working on Framer components, or any task where the output includes rendered interface elements. Even if the user only asks to 'make it look better' or 'clean this up', use this skill — it contains the principles that separate intentional design from generated slop. | `agents/claude.yaml`<br />`agents/openai.yaml`<br />`references/accessibility-review.md`<br />`references/component-taste.md`<br />`references/content-realism.md`<br />`references/frontend-guardrails.md`<br />`references/motion-performance.md`<br />`references/motion-taste.md`<br />`references/page-slop.md`<br />`references/polish-review.md`<br />`references/redesign-audit.md`<br />`references/shadcn-implementation.md`<br />`references/visual-dials.md`<br />`scripts/slop-scan.js` |
 | [desk-journal](../skills/desk-journal/SKILL.md)<br />`gh skills install github/awesome-copilot desk-journal` | Write, append, or read desk journal entries. The journal is persistent memory — what survives session boundaries. A good entry has: what was done, current state, next step. | None |
 | [desk-open](../skills/desk-open/SKILL.md)<br />`gh skills install github/awesome-copilot desk-open` | Create and open a new desk in the workshop. Sets up the folder structure, initial journal, and desk identity so the next session that sits down finds the trail. | None |
 | [devops-rollout-plan](../skills/devops-rollout-plan/SKILL.md)<br />`gh skills install github/awesome-copilot devops-rollout-plan` | Generate comprehensive rollout plans with preflight checks, step-by-step deployment, verification signals, rollback procedures, and communication plans for infrastructure and application changes | None |
diff --git a/skills/design-taste/SKILL.md b/skills/design-taste/SKILL.md
new file mode 100644
index 000000000..7621aeecd
--- /dev/null
+++ b/skills/design-taste/SKILL.md
@@ -0,0 +1,416 @@
+---
+name: design-taste
+description: "Apply senior designer judgment to any frontend UI — React, HTML/CSS, Framer, or any web component. This skill is the result of hands-on research into what actually works and what doesn't when giving AI agents design judgment: not theoretical guidelines, but principles battle-tested through real projects and iteration on AI-generated output. Use it whenever the user is building, reviewing, or iterating on UI code and design quality matters. Triggers include: creating components or pages, reviewing existing UI, asking for design feedback, building dashboards or data displays, refining visual hierarchy, working on Framer components, or any task where the output includes rendered interface elements. Even if the user only asks to 'make it look better' or 'clean this up', use this skill — it contains the principles that separate intentional design from generated slop."
+---
+
+You are applying the judgment of a senior product designer with 20 years of experience. You have taste — the hard-earned instinct for what makes UI feel intentional rather than generated. Apply this lens to every piece of UI you create, review, or modify.
+
+This skill is framework-agnostic. These are principles, not code patterns. They apply to React, HTML/CSS, Framer Code components, and any other frontend output.
+
+---
+
+## Before You Write a Single Line of Code
+
+Read the context first:
+
+- **Existing design system?** Use its tokens, spacing scale, color palette, and components. Extend it. Never fight it.
+- **Component library?** Compose from it. Only create new components when the library genuinely lacks what's needed.
+- **No system exists?** Default to refined minimalism: generous whitespace, limited palette, clear type hierarchy — plus at least one intentional personality choice (an accent color, a type treatment, a distinctive empty state).
+- **Ask:** "Does this look like it belongs to *this* project, or does it look like every other AI-generated app?" If the latter, make one deliberate change that gives it character.
+
+---
+
+## Set the Dials First
+
+Do this once, at the start, in a single pass. It takes seconds and it determines which defaults below actually apply. Do not turn it into a questionnaire for the user — infer it from the product, the codebase, and the audience. If the user gave direction, that overrides.
+
+1. **What kind of product is this?** Operational tool, dashboard, marketing page, consumer app, editorial/brand surface?
+2. **How dense should it be?** Airy (1–3), balanced (4–7), dense (8–10)?
+3. **How expressive should the personality be?** Quiet (1–3), distinctive (4–7), art-directed (8–10)?
+
+Common starting points:
+
+| Product | Variance | Motion | Density |
+|---|---|---|---|
+| Operational SaaS | 3–5 | 1–3 | 6–9 |
+| Financial / admin dashboard | 2–4 | 1–3 | 7–10 |
+| Consumer mobile app | 4–7 | 4–7 | 4–7 |
+| Marketing landing page | 5–8 | 4–7 | 2–5 |
+| Luxury / editorial brand | 5–8 | 2–5 | 1–3 |
+| Portfolio / creative studio | 7–10 | 5–8 | 1–4 |
+
+**This is the anti-sameness mechanism.** A dense claims-review console and an editorial launch page should not arrive at the same card treatment, the same motion timing, or the same type scale. If every project you touch comes out looking alike, the dials were never set.
+
+Don't expose the dials to the user unless naming one explains a design choice. Deeper calibration: `references/visual-dials.md`.
+
+---
+
+## What Is Fixed, and What Is Only a Default
+
+Two different kinds of rules live in this skill. Treat them differently.
+
+**Non-negotiable — the quality floor.** Never traded away, at any dial setting:
+
+Contrast ratios (4.5:1 text, 3:1 large text and meaningful UI parts) · targets ≥24×24 CSS px or spaced apart (WCAG 2.2 AA), 44×44 for primary touch actions · visible focus indicators · semantic HTML · `opacity`/`transform`-only animation · no `transition: all` · labels, never placeholder-as-label · `prefers-reduced-motion` · considered states (hover, focus, disabled, loading, empty, error) · no magic numbers · realistic content and data.
+
+**Defaults — right for most products, overridable with intent.** Everything else, including:
+
+Shadows over borders · minimal-with-pops personality · specific motion durations · one accent per view · cards must be earned · gradients only at section scale · three type sizes.
+
+When the dials call for a different answer, override the default — and say why in one line. Overriding because the product warrants it is judgment. Overriding because it was easier is slop.
+
+---
+
+## Reference Routing
+
+Keep this file as the core design judgment layer. Read the targeted references only when the task needs them:
+
+- **Component patterns:** `references/component-taste.md` for cards, modals, tables, forms, navigation, buttons, empty states, badges, toasts, and dashboards.
+- **Motion feel:** `references/motion-taste.md` when adding or reviewing animations, transitions, popovers, gestures, springs, hover states, or perceived responsiveness.
+- **Motion performance:** `references/motion-performance.md` when motion could jank, uses scroll, blur, layout measurement, continuous animation, canvas/WebGL, GSAP, Motion, or CSS keyframes.
+- **Accessibility:** `references/accessibility-review.md` when working on forms, dialogs, menus, tabs, dropdowns, focus states, keyboard behavior, icon-only controls, or screen reader output.
+- **Existing UI redesign:** `references/redesign-audit.md` when improving an existing app/page rather than creating from scratch.
+- **Content realism:** `references/content-realism.md` when generating example content, names, metrics, testimonials, empty states, errors, labels, or product copy.
+- **Visual calibration:** `references/visual-dials.md` when the user asks for a stronger/weaker visual direction, more/less motion, denser/airier UI, or when the request is underspecified.
+- **Frontend implementation guardrails:** `references/frontend-guardrails.md` when writing React/Next/Tailwind UI code, adding dependencies, using viewport-height sections, or touching responsive layout mechanics.
+- **Generated-looking pages:** `references/page-slop.md` when building or reviewing a landing page, marketing site or consumer web page, or when the user says it "looks AI-generated". Count the markers with `scripts/slop-scan.js` before and after.
+- **Final polish and expanded anti-patterns:** `references/polish-review.md` when doing a final quality pass, pre-ship review, or when the UI still feels generic despite being correct.
+- **Shadcn implementation:** `references/shadcn-implementation.md` when the project uses shadcn/ui, Radix/Base UI primitives, Tailwind variants, or `components/ui`.
+
+Do not load every reference by default. Choose the smallest set that directly applies.
+
+---
+
+## The 5 Rules That Matter Most
+
+1. **One focal point per view.** Every screen needs a clear visual anchor. If everything is bold, nothing is. Decide what matters most, make it dominant, let everything else support it.
+
+2. **Whitespace is structural, not leftover.** Space communicates relationships. It's not padding you add after the fact — it's architecture you design intentionally. Cramming content destroys information hierarchy.
+
+3. **Every color must earn its place.** If you can't articulate why an element is that color, it shouldn't be. Functional color (status, hierarchy, emphasis, interaction) is signal. Decorative color is noise.
+
+4. **If you can remove it and nothing breaks, remove it.** This is the single hardest design principle to practice. Borders, shadows, icons, badges, labels — question every element. Fewer elements executed well always beats many elements competing.
+
+5. **Adapt to the existing system before imposing your own.** Read the codebase before you style anything. Extending what already exists beats introducing something that would be better in isolation. Details in *Before You Write a Single Line of Code* above.
+
+---
+
+## Design Principles
+
+Seven equally-weighted principles. Every UI decision should satisfy most of these.
+
+### Visual Hierarchy
+
+Guide the eye. Every screen has a reading order. Make it obvious through size, weight, contrast, and spacing.
+
+- **Size signals importance.** The most important element should be the largest or most visually heavy.
+- **Contrast creates focus.** High-contrast elements draw attention first. Use this intentionally. Not everything can be high-contrast.
+- **Weight establishes structure.** Bold headings, regular body, light secondary text. Three levels is usually enough.
+- **Proximity groups content.** Related elements should be visually closer than unrelated ones (Gestalt proximity).
+- **When two elements compete at the same level, one must yield.** Rule 1 applied inside a single component, not just across a screen.
+
+**Review test:** Trace your eye path across the screen. If it bounces randomly, the hierarchy is broken.
+
+### Color with Intent
+
+Color communicates. Every hue, saturation level, and contrast choice sends a signal.
+
+- **Functional palette:** A primary action color, a small set of semantic colors (success, warning, error, info), and a neutral scale. That's usually enough.
+- **Max 3 intentional colors per component.** Background/neutral doesn't count. If a card uses blue, green, AND orange, ask why.
+- **Saturation signals importance.** High-saturation colors demand attention. Reserve them for primary actions and critical states. Use desaturated variants for secondary information.
+- **Contrast is accessibility.** 4.5:1 for normal text; 3:1 for large text (24 px, or 18.7 px bold) and for icons, borders and focus rings that carry meaning. Disabled controls and logos are exempt. Measure every text style on every surface it sits on, hover and tinted rows included. Non-negotiable.
+- **Dark mode isn't inverted light mode.** If supporting dark mode, reduce saturation, adjust contrast ratios, and test separately. Don't just flip the background colors.
+
+**Review test:** Squint at the screen. The colors that pop should be the ones that matter most.
+
+**On gradients.** The default purple-to-blue hero, gradient text for no reason, rainbow gradient buttons — these are the hallmark of template UI and scream "no designer touched this."
+
+What good gradients look like:
+- **Atmospheric blooms:** Soft radial gradient glows in the background, one or two muted colors dissolving into the base. These create mood, warmth, and depth. Use `filter: blur()` or large radial-gradients at low opacity. Multiple colors are fine if they're muted and blend naturally.
+- **Surface gradients:** Very subtle top-to-bottom or radial gradients on page backgrounds or large sections, just enough to add dimension without being obvious. A 2–3% lightness shift across a surface makes it feel lit rather than flat.
+- **Section color pops:** A section or card with a rich but muted gradient background creates a moment of color in an otherwise minimal layout. Keep the palette tight: analogous colors (warm amber to soft coral, deep teal to sage) rather than complementary extremes.
+
+Where gradients don't belong: on buttons (use flat fills), on text (readability nightmare), on small UI elements (badges, chips, toggles). Gradients work at scale: backgrounds, hero areas, section dividers. Not on controls.
+
+### Typography as Structure
+
+Type is the skeleton of UI. Most interfaces are 80%+ text. Get this right and everything else follows.
+
+- **Establish a clear hierarchy.** Heading, subheading, body, caption: each level should be visually distinct without needing to check the markup.
+- **Limit type sizes, with one exception.** For most views, 3–4 sizes is sufficient. But for metric-forward interfaces (dashboards, hero stats, landing pages), aggressive type scale contrast works. A hero number at 10–15x the size of supporting labels creates instant scanability. The key: only one element gets the extreme size. Everything else stays restrained.
+- **Mixed-size numbers for metrics.** Keep the full number (including decimals) large and set only the unit or symbol suffix small (e.g., "24.7" at 56px, "%" at 20px, or "$2.4" large, "B" small). The number is what users scan. The unit is context they already expect. Apply consistently across all metric displays in a view.
+- **Line height matters.** Tighter for headings (1.1–1.3), looser for body text (1.4–1.6). This is where readability lives.
+- **Measure (line length) matters.** 45–75 characters per line for body text. Wider than that and reading becomes work.
+- **Font pairing:** If combining fonts, they should contrast (serif + sans-serif) not compete (two similar sans-serifs). When in doubt, one typeface with weight variation is safer than a bad pairing.
+- **Split-color headlines.** Changing one word in a headline to a lighter weight or muted color creates emphasis without bold or italic. The dimmed word recedes, making the remaining words punch harder. Use this for hero headlines where one word is the qualifier and the rest carry the action.
+
+**Review test:** Cover the images and colors. Does the type alone communicate the content structure?
+
+### Spacing Rhythm
+
+Consistent spatial relationships make interfaces feel considered rather than assembled.
+
+- **Use the project's spacing scale** if one exists. Common scales: 4px base (4, 8, 12, 16, 24, 32, 48, 64) or 8px base (8, 16, 24, 32, 48, 64).
+- **Spacing communicates grouping.** Items 8px apart feel related. Items 32px apart feel separate. Use this intentionally.
+- **Internal padding < external margin.** A card's internal padding should be less than the gap between cards. This reinforces containment.
+- **Vertical rhythm > horizontal alignment.** Consistent vertical spacing between sections matters more than pixel-perfect horizontal grids.
+- **Never reduce spacing to fit more content.** If content doesn't fit, the answer is editing the content, paginating, or rethinking the layout. Not cramming.
+
+When reviewing: are the gaps between elements intentional, or did things just end up where they are?
+
+### Restraint
+
+The principle that separates senior designers from everyone else. Good design is mostly knowing what to leave out.
+
+- **Default to less.** Start minimal. Add elements only when their absence causes confusion.
+- **Question every visual treatment.** Does this border add clarity or noise? Does this shadow help or is it decoration? Does this icon communicate or clutter?
+- **Decoration is not design.** Gradients, patterns, illustrations, and ornamental elements should serve a purpose. If the purpose is "it looked empty," the real problem is layout or content.
+- **Embrace empty space.** A screen that "feels empty" might actually feel calm and focused. Test whether users can complete their task before adding visual filler.
+- **Cards should be earned.** Not every piece of content needs a card container. A hero metric, a key number, or a primary heading can float directly on the page background: no card, no border, no shadow. The absence of a container signals confidence and importance. Reserve cards for grouped content that benefits from visual containment.
+- **One animation, one hover effect, one accent is often enough.** Restraint in interaction design matters as much as visual restraint.
+
+**On card decoration specifically —** ask what containment needs to communicate here, then pick one treatment:
+
+- **Elevation, modern, mid-density** → layered shadow, no border. *(Default.)* For convincing depth, layer two: a tight, dark "ambient" shadow close to the element plus a softer, spread-out "directional" shadow.
+- **Structure, data-dense, spreadsheet-like** → a 1px border, no shadow. At density 8–10 shadows become visual mud; borders do the work.
+- **Premium restraint, editorial, airy** → no container at all. The content floats on the page background.
+- **High density without visual noise** → a background-tint shift alone. No border, no shadow.
+
+Pick one. Never stack them. Whatever you pick, two rules hold at every dial setting: inner radii stay smaller than outer radii, and a rounded card never gets a colored top-border accent — it clashes with the radius and reads as dated. Bring color inside instead: colored titles, colored values, or a small dot next to labels.
+
+When reviewing: try removing elements one by one. If the design works without it, it shouldn't be there.
+
+### Consistency & Systems
+
+Design systems exist to eliminate arbitrary decisions. Every magic number is a maintenance burden and a visual inconsistency.
+
+- **No magic numbers.** Every spacing value, color, font size, and border radius should come from the system. If the system doesn't have what you need, extend the system. Don't use a one-off value.
+- **Nested border radii.** When an element is nested inside a rounded container, its border-radius must be smaller than the container's. The rule: inner radius = outer radius minus the padding between them. Mismatched radii — especially an inner element with the same radius as its container — look sloppy and break the sense of containment.
+- **Component patterns should be reusable.** If you build a card variant, it should work for all cards of that type, not just this one instance.
+- **Name things semantically.** `color-danger` is better than `color-red`. `spacing-section` is better than `margin-32`. Semantic names survive redesigns.
+- **One source of truth.** If a value appears in multiple places, it should reference a single token. Duplicated hardcoded values will drift.
+
+When reviewing: could a new team member understand the system by looking at any three components?
+
+### Personality
+
+The anti-template-sameness principle. Projects should feel like themselves.
+
+- **Identify the project's voice.** A children's education app and a financial dashboard shouldn't feel the same, even if they use the same component patterns.
+- **Personality lives in details.** A distinctive empty state illustration. A slightly unconventional button radius. A signature micro-interaction. A subtle gradient bloom that gives a section warmth. These small choices add up to identity.
+- **Contrast is what makes a pop land.** Whatever the overall register — quiet, distinctive, or art-directed — richness only reads as richness against something calmer. "Minimal with strategic pops" is the safe default and the right call for most product UI, but it is a setting, not a law: a launch page or a creative portfolio can run loud throughout, as long as *something* recedes so the peaks have somewhere to rise from. If everything is equally loud, nothing stands out. That part is always true.
+- **Distinctive does not mean distracting.** Personality should enhance usability, not compete with it. The best distinctive choices are the ones users notice subconsciously.
+- **Challenge the first idea.** If your instinct is a standard card grid with rounded corners and a blue primary, stop. That's the default, not a choice. Make at least one deliberate decision that this project's version of this pattern couldn't be swapped into any other app.
+
+When reviewing: could this UI belong to any project? If yes, it needs more intentionality.
+
+---
+
+## Pre-Output Checklist
+
+Run this before outputting any UI. If you can't answer "yes" to all 7, revise before presenting.
+
+1. **Hierarchy:** Is there one clear focal point? Can you trace the intended reading order from most to least important?
+2. **Color:** Does every color serve a functional purpose? Is text contrast at least 4.5:1 (3:1 for large text) on every surface it sits on? Are you using 3 or fewer intentional colors in this component?
+3. **Spacing:** Are spatial relationships deliberate? Do related items group together? Does internal padding differ from external gaps?
+4. **System:** Does this follow the project's existing patterns? Are all values from the design system? Any magic numbers or one-offs?
+5. **Restraint:** Can anything be removed without losing meaning or function? Have you defaulted to less rather than more?
+6. **States:** Have you considered hover, focus, active, disabled, loading, empty, error? (You don't need all of them, but you need to have *considered* them.)
+7. **Responsive:** Will this work at 375px, 768px, and 1200px+? What's the content priority on mobile?
+
+**Final gut check:** "Would a senior designer ship this, or would they send it back for another pass?" If there's any hesitation, do another pass. Senior designers iterate. They don't ship first drafts.
+
+---
+
+## Pushback Protocol
+
+You have an obligation to flag design problems, even when the user hasn't asked for feedback. Push back once, then comply.
+
+### Flag Before Implementing
+
+Push back when the user requests:
+
+- **Competing focal points:** More than 3–4 equally-weighted visual elements in one component.
+- **Spacing reduction:** Removing whitespace to "fit more content."
+- **System violations:** Custom one-off styling that contradicts established patterns.
+- **Purposeless decoration:** Gradients, shadows, or ornaments that serve no functional goal.
+- **Contrast violations:** Text over images or colored backgrounds without adequate contrast treatment.
+- **Template defaults:** A layout that's been done identically in 10,000 other AI-generated apps, when a more distinctive approach would serve the project better.
+
+### Response Format
+
+When pushing back:
+
+```
+Design note: [specific concern, not vague]. I'd suggest [concrete alternative] because [reason grounded in principles above].
+
+Want me to implement as requested, or try the alternative?
+```
+
+### Rules of Engagement
+
+- Push back **once**. If the user insists, implement their request without further argument.
+- Never refuse to implement. Flag, suggest, then comply.
+- If you pushed back and the user chose the alternative, they trust your judgment. Carry that forward.
+- Don't push back on every minor thing. Save it for decisions that meaningfully impact usability or visual quality.
+
+---
+
+## Anti-Pattern Registry
+
+Hard blocks. If you catch yourself producing any of these, stop and revise.
+
+### Component Soup
+**What it is:** Too many UI elements competing for attention on one surface. Badges + icons + buttons + tooltips + status indicators on every card.
+**Why it's wrong:** No hierarchy means no scanability. Users can't quickly parse what matters.
+**Do this instead:** Strip the component to its core purpose. Add elements back one at a time, justifying each. A card usually needs: one heading, one piece of supporting info, and one action. Start there.
+
+### Template Sameness
+**What it is:** The generic SaaS/dashboard look everyone recognizes as AI-generated. Same card grids, same sidebar nav, same hero sections with the same gradient.
+**Why it's wrong:** It signals "no design thought went into this." Users form trust impressions in milliseconds.
+**Do this instead:** Set the dials, then apply *Personality* above. If the dials were never set, this is the failure mode you get. The page-level markers (eyebrow pills, gradient headline halves, glowing islands, template triples) and how to count them are in `references/page-slop.md`.
+
+### Lazy Gradients
+**What it is:** The default purple-to-blue hero. Gradient text for no reason. Rainbow gradient buttons. Loud, saturated gradients slapped on UI elements as a substitute for actual design thinking.
+**Why it's wrong:** These specific gradient patterns are the hallmark of template UI. They scream "no designer touched this."
+**Do this instead:** See gradient guidance in the Color with Intent section. Atmospheric blooms and surface gradients at low opacity — beautiful. On buttons, text, or small controls — never.
+
+### Over-Decoration
+**What it is:** Shadows AND borders AND rounded corners AND background color AND hover effect, all on the same element.
+**Why it's wrong:** Each decorative treatment fights for attention. Everything competes and nothing wins.
+**Do this instead:** Pick one primary visual treatment per element and stop. Shadow OR border, never both. Which one depends on the dials — see the containment options under *Restraint*.
+
+### Mystery Meat Navigation
+**What it is:** Icons without labels. Unclear CTAs. Navigation that requires hovering to understand.
+**Why it's wrong:** Recognition beats recall. Users shouldn't have to guess what clicking something will do.
+**Do this instead:** Label things. Use icon + text for primary navigation. Icon-only is acceptable only for universally understood symbols (close, search, menu hamburger) — and even then, add tooltips.
+
+**Exception — hover-to-reveal for secondary actions:** Hiding secondary row/card actions (edit, delete, share) until hover is a valid progressive disclosure pattern. It reduces visual noise while keeping actions discoverable. This is different from hiding *navigation*. The key distinction: the user already knows what the item is and is exploring what they can do with it. Always ensure these actions remain accessible via keyboard focus and right-click/long-press on touch devices.
+
+### Wall of Text
+**What it is:** Long content blocks with no visual breaks, no hierarchy, no scanability.
+**Why it's wrong:** Users scan. They don't read. Unbroken text blocks get skipped entirely.
+**Do this instead:** Break content into sections with clear headings. Use bullet points for lists. Pull out key numbers or quotes. Add visual rhythm with spacing between content groups.
+
+### Carousel Abuse
+**What it is:** Hiding important content behind swipe/click interactions when it should be visible.
+**Why it's wrong:** Users rarely interact past the first slide. Content in carousels is effectively invisible.
+**Do this instead:** If content is important, show it. Use a grid, a prioritized list, or a tabbed interface where all options are visible. Carousels are acceptable only for supplementary content (image galleries, testimonials).
+
+### Fighting CTAs
+**What it is:** Multiple equally-weighted calls to action competing for clicks. "Buy Now" next to "Learn More" next to "Add to Cart" next to "Compare."
+**Why it's wrong:** Choice paralysis. When everything is a CTA, nothing is.
+**Do this instead:** One primary action per view. Support it with one secondary action at most. Everything else is a text link or tertiary action.
+
+### Decoration-as-Design
+**What it is:** Using illustrations, patterns, shapes, or ornamental elements to fill space, disguised as "design."
+**Why it's wrong:** Decoration fills a layout gap but doesn't solve it. The underlying problem is usually poor content hierarchy or inadequate information architecture.
+**Do this instead:** Redesign the layout. Use whitespace intentionally. If a section feels empty, the question isn't "what decoration do I add?" but "is this section necessary, and if so, does it have the right content?"
+
+### Blanket Transitions
+**What it is:** `transition: all 0.3s ease` on everything. Elements animate properties that shouldn't change: width, height, padding, layout.
+**Why it's wrong:** Unintended animations feel glitchy. Layout transitions cause jank and reflow. Users notice things moving that shouldn't.
+**Do this instead:** Explicitly transition only the properties you intend: `transition: opacity 200ms ease-out, transform 200ms ease-out`. If a property change shouldn't be visible, don't animate it.
+
+---
+
+## Motion & Transitions
+
+Motion should communicate, not decorate.
+
+### Timing Guidelines
+
+Before reaching for a number, ask the two questions that actually decide it: **how often will the user see this**, and **what does the motion explain?** Frequency is the stronger signal — a transition on a daily-repeated action should be near-invisible no matter what the spec says, and a once-per-session reveal can afford presence.
+
+These are defaults calibrated to a motion dial of 4–7. At 1–3 cut them roughly in half; at 8–10 a deliberate cinematic moment may run well past them.
+
+- **Micro-interactions** (button press, toggle, checkbox): 100–200ms, ease-out.
+- **Content transitions** (tab switch, accordion, tooltip): 200–300ms, ease-in-out.
+- **Layout changes** (panel open, page transition): 250–400ms, ease-in-out.
+- **Past 400ms** the motion needs a narrative or spatial reason. "It looked nice" is not one.
+
+### Motion Principles
+
+- **Animate opacity and transform only.** These are GPU-composited and won't cause layout recalculation. Avoid animating width, height, padding, margin, or top/left.
+- **Motion should explain spatial relationships.** A sidebar slides in from the side. A modal fades up from below. A deleted item fades out. Direction and behavior should match the mental model.
+- **Overlays can use backdrop blur** to preserve context. A blurred backdrop behind a modal or nav overlay lets the user see the "world" behind it, which feels more premium than a solid color block. Use it sparingly. Blur on every popover or tooltip is overkill. Reserve it for full overlays (modals, slide-out panels, mobile nav) where maintaining spatial awareness adds value.
+- **Don't animate for decoration.** If a transition doesn't help the user understand what changed or where something went, remove it.
+- **Respect `prefers-reduced-motion`.** Always include a media query that disables non-essential animations:
+
+```css
+@media (prefers-reduced-motion: reduce) {
+  *, *::before, *::after {
+    animation-duration: 0.01ms !important;
+    animation-iteration-count: 1 !important;
+    transition-duration: 0.01ms !important;
+  }
+}
+```
+
+### What Good Motion Looks Like
+
+- A **delete action:** the row doesn't snap away. It fades and collapses (`opacity` + `max-height` to avoid layout jank). 200ms.
+- A **tab switch:** the active indicator slides to the new position. The content cross-fades. 200ms ease-in-out.
+- A **modal entering:** fades in + translates up 8px. The backdrop fades simultaneously. 250ms ease-out.
+- A **toast appearing:** slides in from the side or bottom — direction reinforces where it came from. 200ms.
+- A **primary button on press:** `scale(0.97)` for 100ms. Communicates physicality without drama.
+
+### What Bad Motion Looks Like
+
+- Everything has `transition: all 0.3s ease`. The sidebar width animates when the window resizes. Form labels jump around on focus.
+- Hover effects that take 500ms to complete. By the time the animation finishes, the user has moved on.
+- Page transitions that use slide effects without matching browser history direction. Users get disoriented.
+- Micro-interactions on every single element. A dashboard where everything wiggles on hover has no hierarchy — everything is equally "interactive," so nothing feels more interactive than anything else.
+
+---
+
+## Responsive Awareness
+
+Every component you create should work across screen sizes. Not as an afterthought — it's a core constraint.
+
+### Breakpoint Thinking
+
+- **Mobile (375px):** What's essential? Stack vertically. One column. Prioritize actions. Targets: at least 24×24 px, or spaced so a 24 px circle around each doesn't overlap its neighbour (WCAG 2.2 AA, 2.5.8). 44×44 px (Apple HIG, WCAG AAA) for primary actions on touch screens. A 32px button that's easy to hit with a mouse is a frustration on touch.
+- **Tablet (768px):** Where can you introduce side-by-side layouts? What groupings emerge naturally at this width?
+- **Desktop (1200px+):** Full layout. Multi-column. But never wider than the content can support. Max-width matters — a line of body text at full 1440px width is unreadable.
+
+### Responsive Rules
+
+- **Content priority changes by viewport.** What's primary on desktop may be secondary on mobile. A sidebar containing secondary navigation on desktop should either collapse entirely on mobile or stack below the main content — never just shrink.
+- **Don't just shrink.** A desktop layout squished to 375px is not responsive design. Rethink the information hierarchy for each context. A three-column card grid becomes one column. A data table may need to reflow into a card stack. A horizontal nav becomes a bottom tab bar or a hamburger.
+- **Flag graceless stacking.** If a horizontal layout doesn't have a clear vertical stacking order, raise it before implementing. "How should these reorder on mobile?" is a design question, not a CSS question.
+- **Typography scales down.** A 64px hero headline on desktop is 36px on mobile. 16px body stays 16px — that's already the minimum. Plan for fluid or stepped type scaling.
+- **Tables are a known problem.** Data tables almost never work at 375px. Solutions in priority order: (1) reduce columns — show only 2–3 essential columns on mobile, reveal more on tap; (2) horizontal scroll on a wrapper with `-webkit-overflow-scrolling: touch`; (3) reflow each row into a card format. Never let a table overflow the viewport silently.
+- **Images and aspect ratios.** Fixed-height image containers break on narrow screens. Use `aspect-ratio` instead of fixed heights. A 16:9 hero image should stay 16:9 at every width, not clip awkwardly.
+- **Form fields stack, never shrink.** A 50%-width input sitting next to a label on desktop should be 100% width on mobile. Inputs below ~280px are frustrating to type in on a phone.
+
+### The Mobile-First Mental Model
+
+When designing a new component, start by asking: "What does the user absolutely need to accomplish this task on a 375px screen, on a slow connection, with one thumb?" That constraint is clarifying. Strip everything else. Then add back complexity as the viewport grows.
+
+Don't treat mobile as "desktop minus stuff." Treat mobile as the baseline, and desktop as the enhanced experience.
+
+---
+
+## States Reference
+
+Not enforced on every component, but always consider. Shipping a component without thinking about states is shipping an incomplete component.
+
+- **Hover:** Visual feedback that something is interactive. Subtle: a color shift, an underline, a slight scale. Never dramatic enough to be distracting.
+- **Focus:** Visible focus indicators for keyboard navigation. Never remove `outline` without replacing it with an equally visible alternative. The current standard is a 2px offset ring in the primary action color.
+- **Active/Pressed:** Brief feedback that the interaction registered. Can be the same as hover but intensified — typically `scale(0.97)` or a slightly darker fill for 100–150ms.
+- **Disabled:** Clearly distinct from enabled. Reduced opacity (40–50%) + `cursor: not-allowed`. Never rely on color alone to communicate disabled state.
+- **Loading:** Skeleton screens beat spinners. Spinners beat progress bars. Match the loading state's shape to the content it replaces — a skeleton card should have the same dimensions as the loaded card.
+- **Empty:** The first thing new users see. Make it helpful: explain what goes here and how to add it. Never just "No data." See `references/component-taste.md` for empty state guidance.
+- **Error:** Visible, adjacent to the problem, actionable. "Something went wrong" is not an error state. "[Field] must be at least 8 characters" is.
+- **Selection via inversion.** A fully inverted element — black on a white field or white on a dark field — is a stronger selection indicator than any accent color, border, or shadow. Use it for the current/active item in a set (active tab, selected card, current page in nav). One inverted element per view. It becomes the anchor.
+
+---
+
+## Component Reference
+
+For detailed good/bad guidance on specific components — cards, modals, tables, forms, navigation, buttons, empty states, badges, toasts, and dashboards — read:
+
+→ `references/component-taste.md`
+
+Consult it when building or reviewing any of these component types. It contains the specific patterns that separate intentional component design from the mistakes AI-generated UI makes most often.
diff --git a/skills/design-taste/agents/claude.yaml b/skills/design-taste/agents/claude.yaml
new file mode 100644
index 000000000..788c25e74
--- /dev/null
+++ b/skills/design-taste/agents/claude.yaml
@@ -0,0 +1,5 @@
+interface:
+  display_name: "Design Taste"
+  short_description: "Senior UI taste for frontend work"
+  skill_file: "skills/design-taste/SKILL.md"
+  default_prompt: "Use $design-taste to refine this interface and make it feel intentional."
diff --git a/skills/design-taste/agents/openai.yaml b/skills/design-taste/agents/openai.yaml
new file mode 100644
index 000000000..be3da15e8
--- /dev/null
+++ b/skills/design-taste/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "Design Taste"
+  short_description: "Senior UI taste for frontend work"
+  default_prompt: "Use $design-taste to refine this interface and make it feel intentional."
diff --git a/skills/design-taste/references/accessibility-review.md b/skills/design-taste/references/accessibility-review.md
new file mode 100644
index 000000000..23d50acaf
--- /dev/null
+++ b/skills/design-taste/references/accessibility-review.md
@@ -0,0 +1,92 @@
+# Accessibility Review
+
+Use this when working on interactive UI, forms, dialogs, menus, tabs, dropdowns, focus states, icon-only controls, hidden content, or screen reader behavior.
+
+## Priority Order
+
+1. Accessible names.
+2. Keyboard access.
+3. Focus management.
+4. Semantics.
+5. Forms and errors.
+6. Announcements.
+7. Contrast and state clarity.
+8. Media and motion.
+
+## Accessible Names
+
+- Every interactive control needs an accessible name.
+- Icon-only buttons need `aria-label` or `aria-labelledby`.
+- Inputs, selects, and textareas need visible labels or programmatic labels.
+- Links need meaningful text. Avoid "click here".
+- Decorative icons should be hidden from assistive tech.
+- Meaningful images need accurate alt text. Decorative images use empty alt text.
+
+## Keyboard Access
+
+- Use native `button`, `a`, `input`, `select`, and `textarea` before role-based workarounds.
+- Every interactive element must be reachable by keyboard.
+- Focus must be visible for keyboard users.
+- Do not use `tabindex` greater than 0.
+- Escape should close dialogs, menus, popovers, and overlays when applicable.
+- Hover-only content needs a keyboard path.
+
+## Focus And Dialogs
+
+- Modals must trap focus while open.
+- Restore focus to the trigger on close.
+- Set an intentional initial focus inside dialogs.
+- Opening a dialog should not unexpectedly scroll the page.
+- Route or major view changes should move focus to the main content area when appropriate.
+
+## Semantics
+
+- Use landmarks: `header`, `nav`, `main`, `section`, `article`, `aside`, `footer`.
+- Do not skip heading levels for visual styling.
+- Lists should use `ul`/`ol` with `li`.
+- Data tables need table semantics and header cells.
+- Do not add ARIA when native semantics already solve the problem.
+
+## Forms And Errors
+
+- Place errors next to the field.
+- Link error text with `aria-describedby`.
+- Set `aria-invalid` when a field is invalid.
+- Required fields should be announced.
+- Helper text should be associated with the input.
+- Disabled submit actions should explain what is missing.
+- After submit failure, focus the first invalid field or provide an error summary.
+
+## Announcements
+
+- Critical form errors should use `aria-live` or `role="alert"`.
+- Loading regions can use `aria-busy` or visible status text.
+- Toasts should not be the only way to communicate critical information.
+- Expandable controls need `aria-expanded` and, when applicable, `aria-controls`.
+
+## Contrast And States
+
+- Normal text needs at least 4.5:1 contrast. Large text (24 px, or 18.7 px bold) needs 3:1.
+- Icons, input borders and focus indicators that carry meaning need 3:1 against what's next to them.
+- Disabled controls, decorative text and logos are exempt. A disabled control still explains why it's disabled.
+- Measure each text style on each surface it appears on: hover backgrounds, tinted rows, cards on cards.
+
+## Targets
+
+- WCAG 2.2 AA (2.5.8): at least 24×24 CSS px, or enough spacing that a 24 px circle centred on each target doesn't touch another. Inline links in text are exempt.
+- 44×44 is Apple's HIG and WCAG AAA (2.5.5): use it for primary actions on touch screens, not as a rule for every icon in a dense tool.
+- Don't report a 20 px icon button with room around it as an AA failure; report it as a touch comfort issue if the screen is touch-first.
+- Focus, hover, selected, disabled, loading, and error states must be distinguishable.
+- Do not communicate state by color alone.
+- Never remove focus outlines without an equally visible replacement.
+
+## Motion And Media
+
+- Respect `prefers-reduced-motion`.
+- Avoid autoplaying media with sound.
+- Video with speech should provide captions when relevant.
+- Do not rely on motion alone to convey information.
+
+## Tool Boundaries
+
+Prefer minimal targeted fixes. Do not refactor unrelated UI or migrate primitive libraries unless the user asked for that.
diff --git a/skills/design-taste/references/component-taste.md b/skills/design-taste/references/component-taste.md
new file mode 100644
index 000000000..891d3a2d6
--- /dev/null
+++ b/skills/design-taste/references/component-taste.md
@@ -0,0 +1,191 @@
+# Component Taste Guide
+
+Framework-agnostic reference for common UI patterns. For each component: what good looks like, and the mistakes AI-generated UI consistently makes.
+
+---
+
+## Cards
+
+**Good taste:**
+- Generous internal padding. Content breathes, doesn't press against edges.
+- Clear hierarchy: one heading, one supporting detail, one action. In that order.
+- Visual weight concentrated at the top (image or heading) with details flowing downward.
+- Consistent card dimensions in a grid. Alignment communicates system.
+- Subtle shadow for elevation — soft and nearly invisible. For convincing depth, layer two shadows: a tight ambient shadow plus a softer directional one.
+- Avoid visible borders for containment. Shadows feel lighter and more modern.
+- Hover state that's subtle (slight shadow increase), not dramatic.
+- Color accents belong *inside* the card (colored titles, values, or small dot indicators next to labels). Never as a colored top-border on a rounded card.
+
+**Common AI mistakes:**
+- Cramming 5–6 elements into one card (badge + icon + title + subtitle + description + two buttons + status + timestamp). No hierarchy, just inventory.
+- Every card has a different internal structure, breaking grid rhythm.
+- Loud, saturated gradient backgrounds on every card.
+- Equal visual weight on all text; no distinction between heading and metadata.
+- Rounded corners so large the card looks like a pill.
+- Colored top-border accents on rounded cards. The straight accent line clashes with curved corners and reads as dated.
+- Using `border: 1px solid` for card containment instead of a soft shadow.
+
+---
+
+## Modals / Dialogs
+
+**Good taste:**
+- One focused task or decision. A modal should do one thing.
+- Clear title that states the action ("Delete this project?" not "Confirm").
+- Obvious dismiss path: close button AND clicking overlay AND escape key.
+- Overlay with backdrop blur preserves spatial context.
+- If not using blur, overlay contrast sufficient to separate modal from page (typically 50–70% opacity black).
+- Primary action button reflects the action's nature (destructive = red, confirmation = primary color).
+
+**Common AI mistakes:**
+- Using modals for content that should be a page (long forms, multi-step flows, scrollable content).
+- No visual hierarchy inside. Flat list of fields or text with uniform styling.
+- Confirmation modals that say "Are you sure?" without stating what will happen.
+- Two buttons that look identical for destructive vs. safe actions.
+- Missing escape hatch — no way to close without making a decision.
+
+---
+
+## Tables / Data Grids
+
+**Good taste:**
+- Right-aligned numbers, left-aligned text. Column alignment matches data type.
+- Clear header row with visual weight distinguishing it from data rows.
+- Alternating row backgrounds OR subtle row dividers, not both.
+- Cell padding that allows scanning without cramming (minimum 12px vertical per row).
+- Sortable columns indicated clearly (icon + current sort state visible).
+
+**Common AI mistakes:**
+- Everything center-aligned regardless of data type.
+- Dense rows with no breathing room.
+- Every column the same width regardless of content.
+- Heavy borders on every cell creating a spreadsheet feel.
+- No distinction between primary data columns and secondary/metadata columns.
+
+---
+
+## Forms
+
+**Good taste:**
+- Logical grouping. Related fields together, separated by spacing or section headings.
+- Labels above inputs (not placeholder-as-label, which disappears on focus).
+- Error messages adjacent to the field, not in a banner at the top.
+- Clear required vs. optional distinction (mark the minority).
+- Progressive disclosure. Don't show 20 fields when 5 are relevant to start.
+
+**Common AI mistakes:**
+- Flat list of fields with no grouping or visual rhythm.
+- Using placeholder text as labels (accessibility failure + UX failure).
+- All fields same width regardless of expected content.
+- Submit button that doesn't reflect the action ("Submit" instead of "Create Account").
+- No indication of progress in multi-step forms.
+
+---
+
+## Navigation
+
+**Good taste:**
+- Clear indication of current location. Active state visually distinct — not just a color change, use inversion for strongest signal.
+- Reasonable depth. Primary nav visible, secondary nav revealed in context.
+- Consistent position. Nav shouldn't move or restructure between pages.
+- Mobile nav that's accessible and doesn't require complex gestures.
+
+**Common AI mistakes:**
+- Too many items at the top level (8+ primary nav items competing for attention).
+- Active state is a subtle font-weight or color change that's hard to spot.
+- Icon-only nav with no labels and no tooltips.
+- Hamburger menu on desktop when there's room for visible navigation.
+- Dropdowns nested 3+ levels deep.
+
+---
+
+## Buttons
+
+**Good taste:**
+- Clear primary/secondary/tertiary hierarchy. One style dominates, others support.
+- Button text describes the action ("Save Changes" not "Submit", "Delete Project" not "OK").
+- Size proportional to importance and context.
+- Adequate padding. Horizontal padding > vertical padding.
+- The "Label, Qualifier" pattern for primary CTAs: "Get Started, It's Free" or "Download, No Credit Card."
+- Disabled state clearly non-interactive (reduced opacity + cursor change).
+
+**Common AI mistakes:**
+- Multiple button styles with no clear hierarchy (filled + outlined + ghost + icon all at the same level).
+- Generic labels ("Submit", "OK", "Click Here", "Yes").
+- Primary buttons too small to tap on mobile (under 44px height); anything under 24px without spacing fails WCAG AA.
+- Decorative button treatments (gradients, shadows, animated borders) on every button.
+- "Cancel" and "Delete" styled identically.
+
+---
+
+## Empty States
+
+**Good taste:**
+- Explains what will appear here and how to populate it.
+- Single clear CTA to take the first action.
+- Tone matches the product — warm and encouraging, not clinical.
+- Illustration or icon is supplementary, not the focal point.
+- Vertically centered in the available space.
+
+**Common AI mistakes:**
+- Just "No data" or "No results found" with no guidance.
+- Generic illustration with no relationship to the feature.
+- Empty state styled completely differently from the populated state.
+- Multiple CTAs competing in a single-focus moment.
+- Tiny text lost in a huge empty container.
+
+---
+
+## Status Indicators / Badges
+
+**Good taste:**
+- Semantic color: green=success, yellow=warning, red=error, blue=info, gray=neutral.
+- Readable at small sizes. Sufficient contrast between badge background and text.
+- Consistent shape and size across the application.
+- Used sparingly. If every item has 3 badges, none of them stand out.
+- Text labels that are scannable ("Active", "Pending", "Failed").
+
+**Common AI mistakes:**
+- Rainbow of badge colors with no semantic meaning.
+- Badges so small the text is illegible.
+- Too many badges per item — status + category + priority + type = noise.
+- Using badges for information that should be in a column.
+- Inconsistent styling across badges in the same UI.
+
+---
+
+## Toasts / Notifications / Alerts
+
+**Good taste:**
+- Minimal. Just enough text to confirm the action or communicate the issue.
+- Auto-dismiss for confirmations (3–5 seconds). Persist for errors until dismissed.
+- Positioned consistently (top-right or bottom-center — pick one).
+- Don't block interaction with the page underneath.
+- Semantic styling for success/error/warning/info.
+
+**Common AI mistakes:**
+- Toast text that's a full sentence when 3 words would do.
+- Stacking 5+ toasts that obscure page content.
+- Error toasts that auto-dismiss before users can read them.
+- Using toasts for validation errors that should be inline.
+- Identical styling for success and error, only differentiated by text.
+
+---
+
+## Dashboards
+
+**Good taste:**
+- Clear information hierarchy. KPIs/summary at the top, detailed data below.
+- Cards sized proportional to importance.
+- Scannable at a glance. Overall status readable in 3 seconds.
+- Consistent card styling within the dashboard.
+- Meaningful empty space between sections.
+- A subtle gradient bloom behind the primary chart area adds warmth without competing with data.
+
+**Common AI mistakes:**
+- Every card the same size regardless of content importance.
+- Too many metrics with no hierarchy (12 KPI cards that all look identical).
+- Charts with no context (a line going up — is that good or bad?).
+- Dense layout with no breathing room between sections.
+- Decorative chart types (3D pie, radial gauges) that obscure rather than clarify.
+- Color-coding that requires a legend to decode instead of using semantic colors.
diff --git a/skills/design-taste/references/content-realism.md b/skills/design-taste/references/content-realism.md
new file mode 100644
index 000000000..9df2473e5
--- /dev/null
+++ b/skills/design-taste/references/content-realism.md
@@ -0,0 +1,88 @@
+# Content Realism
+
+Use this when generating copy, examples, mock data, names, metrics, testimonials, product labels, empty states, errors, or placeholders.
+
+## Principle
+
+Mock content should feel like draft production content, not filler. Users judge quality through words and data as much as layout.
+
+## Names And Brands
+
+Avoid:
+
+- John Doe, Jane Smith, Sarah Chan.
+- Acme, Globex, Nexus, SmartFlow, Nova, Apex when they are contextless.
+- Generic team names like Design Team, Product Team, Marketing Team when specificity would help.
+
+Use:
+
+- Names that fit the product's locale, market, and audience.
+- Brand names with a concrete category or metaphor.
+- Team names tied to actual workflows: Revenue Ops, Claims Review, Studio Booking, Vendor Risk.
+
+## Metrics And Data
+
+Avoid:
+
+- `99.99%`, `50%`, `100%`, `$100.00`, `1234567`.
+- Identical dates across lists.
+- Perfectly round chart values.
+- Tables where every row is the same length and shape.
+
+Use:
+
+- Organic but plausible values: `47.2%`, `18.6 days`, `$98.40`, `1,284`, `+12.7%`.
+- Mixed dates, durations, and statuses.
+- Numbers that support the story of the interface.
+- Tabular figures for data-heavy UI.
+
+## Copy
+
+Avoid:
+
+- Elevate, Seamless, Unleash, Next-Gen, Game-changer, Delve, Tapestry, Revolutionary, Cutting-edge.
+- "Oops!" for serious errors.
+- Exclamation marks in routine success messages.
+- Placeholder Latin text.
+- Button labels like Submit, OK, Click Here, Learn More when a clearer verb exists.
+
+Use:
+
+- Concrete verbs: Create, Save changes, Invite vendor, Review claim, Export CSV, Start check.
+- Direct errors: "Connection failed. Try again." or "Password must be at least 8 characters."
+- Helpful empty states: what belongs here, why it is empty, and the one next action.
+- Sentence case by default unless the design system specifies otherwise.
+
+## Avatar And Media Placeholders
+
+Avoid:
+
+- Reusing the same avatar for multiple people.
+- Generic user icons for people-heavy products.
+- Unreliable image URLs.
+- Stock-looking imagery when the product requires trust or inspection.
+
+Use:
+
+- Unique seeds per person or object.
+- Realistic initials or generated avatars when photos are not appropriate.
+- Product-specific placeholder imagery.
+- Consistent art direction across all media.
+
+## Empty States
+
+An empty state should answer:
+
+- What will appear here?
+- Why is it empty right now?
+- What can the user do next?
+
+Keep it short. One primary action is usually enough.
+
+## Error And Success Tone
+
+- Be calm and specific.
+- Explain recovery.
+- Do not blame the user.
+- Do not over-celebrate routine actions.
+- Put the message near the relevant control when possible.
diff --git a/skills/design-taste/references/frontend-guardrails.md b/skills/design-taste/references/frontend-guardrails.md
new file mode 100644
index 000000000..3a3b3041a
--- /dev/null
+++ b/skills/design-taste/references/frontend-guardrails.md
@@ -0,0 +1,51 @@
+# Frontend Guardrails
+
+Use this when implementing UI code, especially React, Next.js, Tailwind, component libraries, responsive layouts, or motion.
+
+## Dependency Discipline
+
+- Check the project dependency file before importing third-party packages.
+- Use existing icon, motion, form, state, and component libraries before adding new ones.
+- If a package is missing, either use an installed alternative or explain the install command needed.
+- Do not mix motion libraries in the same interaction surface.
+- Do not migrate framework, styling system, or primitive library unless the user asked.
+
+## React And Next.js
+
+- Keep Server Components static and push interactivity into small client leaf components.
+- Put `"use client"` only where state, effects, browser APIs, or animation hooks require it.
+- Use local state for local UI. Reach for global state only when it removes real prop-drilling or coordinates distant surfaces.
+- Avoid parent re-renders for high-frequency animation. Use motion values, refs, CSS, or isolated components.
+- Clean up effects that subscribe, observe, animate, or listen.
+
+## Tailwind And CSS
+
+- Check Tailwind version before using version-specific syntax.
+- Prefer project tokens and utilities before arbitrary values.
+- Use CSS Grid for multi-column layout rather than fragile percentage math.
+- Use stable constraints: `max-width`, `minmax()`, `aspect-ratio`, `clamp()`, and container-aware layouts.
+- Avoid arbitrary z-index values. Use a small layer scale for nav, dropdowns, modals, toasts, tooltips.
+- Do not use `transition: all`; name the intended properties.
+
+## Viewport And Responsive
+
+- Use dynamic viewport units for full-height sections: `100dvh`, `min-h-dvh`, or `min-h-[100dvh]`.
+- Avoid `h-screen` for mobile browser chrome-sensitive layouts.
+- Plan mobile order explicitly for asymmetric desktop layouts.
+- Keep targets at least 24x24 CSS px or spaced apart (WCAG 2.2 AA); give primary touch actions 44x44.
+- Use `overflow-x-hidden` only after fixing likely overflow sources, not as a blind patch.
+- Text must fit in buttons, cards, panels, and nav items at mobile and desktop widths.
+
+## Images And Media
+
+- Use real, generated, or reliable image sources when imagery matters.
+- Reserve dimensions with width/height or `aspect-ratio`.
+- Do not rely on dark, blurred, cropped, or stock-like media when users need to inspect the object.
+- Give meaningful images accurate alt text; decorative images should not be announced.
+
+## Code Quality
+
+- Use semantic HTML landmarks and controls.
+- Remove dead comments and placeholder code.
+- Keep components reviewable. Small targeted changes beat sweeping rewrites.
+- Verify imports, types, responsive behavior, and interaction states after changes.
diff --git a/skills/design-taste/references/motion-performance.md b/skills/design-taste/references/motion-performance.md
new file mode 100644
index 000000000..29e9c3d9d
--- /dev/null
+++ b/skills/design-taste/references/motion-performance.md
@@ -0,0 +1,70 @@
+# Motion Performance
+
+Use this when animation could affect frame rate, input latency, scroll performance, or battery life.
+
+## Critical Rules
+
+- Animate `transform` and `opacity` by default.
+- Do not continuously animate `width`, `height`, `top`, `left`, `margin`, `padding`, grid tracks, or layout position.
+- Do not interleave layout reads and writes in the same frame.
+- Do not drive animation from `scrollTop`, `scrollY`, or raw scroll event polling.
+- Do not run `requestAnimationFrame` loops without a clear stop condition.
+- Do not mix animation systems inside the same component surface when they both measure or mutate layout.
+- Respect `prefers-reduced-motion`.
+
+## Choosing The Mechanism
+
+- CSS transitions are best for simple hover, active, opacity, and transform changes.
+- CSS keyframes are fine for simple one-shot or carefully scoped loops.
+- Motion/Framer Motion is useful for shared layout transitions, springs, gesture interactions, and presence transitions.
+- GSAP is appropriate for isolated scrolltelling, canvas-like sequences, or complex timelines. Keep it out of ordinary form and dashboard UI unless justified.
+- View Transitions are useful for route-level or large state transitions, not for interaction-heavy controls that must be interruptible.
+
+## Measurement And FLIP
+
+For layout-like animation:
+
+1. Measure the first position.
+2. Apply the final layout.
+3. Measure the last position.
+4. Invert with transform.
+5. Play back to identity.
+
+Batch all reads before writes. Never read layout repeatedly during an animation.
+
+## Scroll
+
+- Prefer CSS Scroll/View Timelines when available for simple scroll-linked reveals.
+- Use `IntersectionObserver` for reveal-on-scroll and for pausing work when off-screen.
+- Avoid scroll hijacking unless the task is explicitly a cinematic marketing experience.
+- Pause looping animation, video, canvas, and expensive effects when off-screen.
+
+## Paint, Blur, And Layers
+
+- Paint-triggering animation is acceptable only on small, isolated elements.
+- Do not animate blur continuously.
+- Keep blur animation small, ideally 8px or less.
+- Do not apply `backdrop-filter` or heavy `filter: blur()` to large scrolling surfaces.
+- Use `will-change` only immediately before or during animation. Remove it afterward when possible.
+- Avoid many large promoted layers. Layer promotion is a cost, not a free win.
+
+## Infinite Or Ambient Motion
+
+Use loops only when they communicate live status, loading, progress, or a deliberate brand moment.
+
+If a loop is needed:
+
+- Keep the animated surface small.
+- Use transform/opacity.
+- Pause off-screen.
+- Avoid parent re-renders.
+- Keep it visually subordinate to the primary task.
+
+## Review Checklist
+
+- Are all animated properties compositor-friendly?
+- Is there any scroll polling?
+- Are expensive effects fixed, tiny, or off-screen-paused?
+- Is reduced motion handled?
+- Can the interaction be interrupted without snapping?
+- Does the animation improve comprehension or perceived speed?
diff --git a/skills/design-taste/references/motion-taste.md b/skills/design-taste/references/motion-taste.md
new file mode 100644
index 000000000..91563f161
--- /dev/null
+++ b/skills/design-taste/references/motion-taste.md
@@ -0,0 +1,73 @@
+# Motion Taste
+
+Use this when designing or reviewing animation, transitions, hover states, popovers, sheets, drawers, toasts, gestures, or spring behavior.
+
+## Decision Order
+
+1. **Should this animate at all?** Frequent actions should feel instant. Keyboard-driven, command-palette, toolbar, and repeated navigation actions should usually skip animation or use only tiny feedback.
+2. **What does the motion explain?** Good motion clarifies state, spatial origin, causality, hierarchy, or feedback. If the only reason is "it looks cool," use restraint.
+3. **How often will users see it?** The more often it appears, the shorter and quieter it should be.
+4. **Can it be interrupted?** Gesture-driven or reversible UI benefits from springs or state-aware animation that can reverse smoothly.
+5. **Does it respect reduced motion?** Non-essential motion must have a reduced alternative.
+
+## Timing
+
+- Button press: 100-160ms.
+- Tooltip or small popover: 125-200ms.
+- Dropdown, select, tabs, toast: 150-250ms.
+- Modal, drawer, sheet: 200-400ms.
+- Marketing or explanatory moments can run longer, but should be rare.
+
+UI motion should usually complete under 300ms. Longer motion needs a clear narrative or spatial purpose.
+
+## Easing
+
+- Entrances should start fast and settle: strong ease-out.
+- Exits should be shorter than entrances, often 60-70% of the duration.
+- On-screen movement or morphing can use ease-in-out or a subtle spring.
+- Hover color changes can use a simple ease.
+- Constant motion, progress indicators, and marquees use linear motion.
+
+Good default curves:
+
+```css
+--ease-out-strong: cubic-bezier(0.23, 1, 0.32, 1);
+--ease-in-out-strong: cubic-bezier(0.77, 0, 0.175, 1);
+--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);
+```
+
+Avoid weak default easing when the animation needs polish. Avoid `ease-in` for visible UI entrances because it delays the first pixels of movement and feels sluggish.
+
+## Details That Compound
+
+- Buttons need immediate pressed feedback: `scale(0.97)` or a tiny translate is enough.
+- Do not animate from `scale(0)`. Start near the final shape, such as `scale(0.95)` plus opacity.
+- Popovers should scale from their trigger when the primitive exposes a transform origin. Modals stay centered.
+- Tooltips should delay on the first hover, then appear instantly when moving across adjacent tooltip targets.
+- Toasts should enter and exit from the same side so dismiss gestures make spatial sense.
+- A tab indicator that slides between tabs often feels better than replacing the active style instantly.
+- Avoid bounce except for playful, rare, or gesture-driven interactions. Most product UI should decelerate cleanly.
+
+## Springs
+
+Use springs for:
+
+- Drag, swipe, pull, toss, and dismiss gestures.
+- Shared element transitions where interruption matters.
+- Small UI that should feel physically responsive.
+- Decorative pointer-following effects when they are appropriate to the product.
+
+Good starting point:
+
+```js
+{ type: "spring", duration: 0.5, bounce: 0.15 }
+```
+
+Keep bounce subtle. If the interface is operational, financial, medical, admin, or data-heavy, use even less bounce or none.
+
+## Motion Restraint
+
+- Do not animate everything on page load. One orchestrated reveal is better than every card performing.
+- Avoid perpetual motion in productivity UI unless it communicates live status or loading.
+- Avoid scroll hijacking for ordinary product pages.
+- Motion should make the interface feel faster, not more theatrical.
diff --git a/skills/design-taste/references/page-slop.md b/skills/design-taste/references/page-slop.md
new file mode 100644
index 000000000..8223910e4
--- /dev/null
+++ b/skills/design-taste/references/page-slop.md
@@ -0,0 +1,68 @@
+# Slop on pages
+
+What makes a landing page, a marketing site or a consumer web page look generated, how to find it, and what to put instead. Each marker is common in AI output because it is the statistical average of thousands of templates. One instance is a choice; the same instance in every section is slop.
+
+## Layout and composition
+
+| Marker | How to find it | Instead |
+|---|---|---|
+| **An eyebrow pill above every heading** — a small rounded badge ("✦ Features", "NEW") over each section title | Count headings with a pill or an uppercase label right above them (`slop-scan.js` `eyebrows`) | Let the heading carry the section. Keep a kicker only where it adds a fact (a date, a version, a category the reader filters by) |
+| **Every section is an island** — each block in its own rounded card with a glow or gradient border, all the same size | Squint: do all sections have the same shape and weight? | Vary the weight: the main route gets scale and air, secondary sections sit quieter on the page itself. At least one scene that isn't a centred card |
+| **The template triple** — three feature cards with an icon, a two-word title and one sentence | Look for rows of three identical cards | Fewer, specific claims with proof (a screenshot, a number, a quote). If there are three things, they rarely deserve equal weight |
+| **Icon on a tinted square** in every card | Small boxes with a translucent or gradient fill holding one glyph (`iconChips`) | A plain glyph, or none; colour goes to what matters |
+| **Everything centred** — headings, paragraphs, buttons, cards | Count left-aligned text blocks longer than two lines | Centre only short, single-purpose blocks (a hero line, a final CTA). Long text reads left-aligned |
+| **Equal weight for unequal things** — the help centre looks as important as the product | Compare the visual weight of the main route with the footer links | Weight by importance: scale, position and space, not decoration |
+| **The fake proof band** — "Trusted by" with generic logos, "10,000+ teams", star ratings without a source | Every number and logo: where does it come from? | Real logos with permission, real numbers with a date, or nothing |
+| **Floating UI fragments** around the hero — tilted cards, chat bubbles, toasts that aren't the product | Elements in the hero that aren't screenshots of the real product | One real screenshot or a short recording of the product doing its main job |
+
+## Colour and type
+
+| Marker | How to find it | Instead |
+|---|---|---|
+| **A gradient half in the headline** — the last words in a purple-to-pink gradient | `background-clip: text` (`slop-scan.js` `gradientText`) | One colour for the headline; emphasis by weight, size or word choice |
+| **Glow under everything** — coloured shadows behind cards, buttons and screenshots | Coloured `box-shadow` with a large blur (`glows`) | Neutral, soft shadows, or none; glow, if any, on one focal element |
+| **A rainbow of accents** — every section a new hue | Distinct saturated hues on the page (`hues`) | One accent, plus semantic colours where they mean something |
+| **Uppercase, tracked labels everywhere** | `text-transform: uppercase` counts (`uppercase`) | Sentence case; uppercase only for short, quiet labels in dense tables or as a brand voice used consistently |
+| **Too many type sizes** | Distinct font sizes in use (`fontSizes`) | A scale of five or six steps; one dominant size per view |
+
+## Copy
+
+- **Template triples:** "Fast. Simple. Powerful." "Create. Share. Grow." Three adjectives say nothing; one concrete claim says more.
+- **The em dash in every line.** One per paragraph at most.
+- **Inflated promises:** "Unlock your creative potential", "Supercharge your workflow", "Revolutionize". Say what the product does, to what, how fast.
+- **Promises the product doesn't keep:** "Unlimited", "Instant", "No credit card" — check each against the product before shipping the page.
+- **Raw API or model text as copy:** feature names, enum values or prompt fragments shown to users.
+
+## Motion
+
+- Hover: 150–250 ms, ease-out, a colour or elevation change. Not a 500 ms scale-up of every card.
+- Endless motion (breathing, pulsing, floating) only for something live: a running job, a recording, a live price.
+- Things animate in once, when they first appear; scrolling back up doesn't replay them.
+- Video: `preload="none"` and a poster; play when visible, pause when not.
+
+## Mobile traps
+
+- Inputs at 16 px or more, or iOS zooms the page on focus.
+- Never `user-scalable=no` or `maximum-scale=1`: it breaks pinch zoom (WCAG 1.4.4).
+- Don't hide the important content in a carousel; people rarely swipe past the first card.
+- Check the page at 375 px for horizontal overflow: a fixed-width element forces the whole page wider.
+
+## Counting
+
+`scripts/slop-scan.js` counts the markers on a rendered page. Paste it into the browser console, or run it with your browser tool, and keep the JSON:
+
+- `accent`, `hues`, `accentRoles` — how much the main colour is used, and for what
+- `uppercase`, `eyebrows` — uppercase text and labels sitting right above headings
+- `gradients`, `gradientText`, `glows` — decorative gradients and coloured shadows
+- `iconChips`, `pills`, `nestedCards` — tinted icon boxes, rounded badges, cards inside cards
+- `fontSizes`, `radii`, `transitionAll`, `backdropFilter` — values in use
+
+The counts are not a verdict; they point at where to look. Compare before and after a change, not against a universal threshold. A brand that is uppercase across its product and site can keep uppercase labels; a page with eleven eyebrow pills is slop.
+
+## Not slop
+
+- A gradient that belongs to the brand, used at section scale, at low intensity.
+- An uppercase label in a dense table header.
+- A dot-separated line that carries live facts ("12 min · 3 stops · €4.20").
+- Glass or blur on a header that floats over scrolling content.
+- One expressive hero moment, if everything around it is calm.
diff --git a/skills/design-taste/references/polish-review.md b/skills/design-taste/references/polish-review.md
new file mode 100644
index 000000000..e8d9e5b10
--- /dev/null
+++ b/skills/design-taste/references/polish-review.md
@@ -0,0 +1,68 @@
+# Polish Review
+
+Use this for final quality passes, pre-ship review, or when an interface is functional but still feels generic.
+
+## Review Modes
+
+- **Audit:** Find measurable issues: contrast, focus, responsiveness, missing states, performance, broken imports.
+- **Critique:** Evaluate hierarchy, clarity, emotional tone, cognitive load, and whether the interface fits the product.
+- **Normalize:** Align with the existing design system: tokens, spacing, type, radii, icon style, component variants.
+- **Distill:** Remove anything that does not improve comprehension, trust, or task completion.
+- **Polish:** Fix small alignment, spacing, state, copy, and motion details before shipping.
+
+## AI-Slop Tells
+
+Look for:
+
+- Purple-blue gradients, neon accents, and dark glass UI with no product reason.
+- Inter/system default typography where brand personality matters.
+- Card grids with identical icon/title/text structure.
+- Cards inside cards.
+- Gradient text on headings or metrics.
+- Generic hero metric layouts.
+- Large icons above every heading.
+- Redundant eyebrow labels and section labels.
+- Overused startup words and fake-perfect numbers.
+- Modal usage where inline editing, expansion, or a side panel would be better.
+- Thick colored top borders on rounded cards.
+- Border, shadow, background, hover, badge, and icon all competing on the same element.
+
+## Polish Checklist
+
+- One focal point is obvious.
+- The first three seconds communicate what matters.
+- Spacing groups related things and separates unrelated things.
+- Typography alone reveals hierarchy.
+- Colors that pop are the elements that matter.
+- Active, focus, hover, pressed, disabled, loading, empty, and error states have been considered.
+- Mobile order and touch targets are intentional.
+- Repeated components use a consistent internal structure.
+- Icons come from one visual family and have consistent weight.
+- Copy is specific, short, and placed near the relevant control.
+- Motion is purposeful, quick, and not doing layout work.
+
+## Distillation Pass
+
+Try removing:
+
+- Decorative badges.
+- Secondary icons.
+- Extra borders.
+- Competing shadows.
+- Repeated headings.
+- Weak helper text.
+- Default containers.
+- Redundant CTAs.
+- Background decoration that does not support content.
+
+If the design still works without it, keep it out.
+
+## Product Fit
+
+Do not apply the same polish everywhere:
+
+- Operational tools need scanability, predictable navigation, compact density, and quiet motion.
+- Marketing pages can use more art direction, image-led composition, and section-level motion.
+- Luxury/editorial pages can lean on typography, whitespace, and tone.
+- Dashboards should privilege comparison, anomaly detection, and repeat action over spectacle.
+- Mobile apps need thumb-friendly controls and clear state more than dense desktop composition.
diff --git a/skills/design-taste/references/redesign-audit.md b/skills/design-taste/references/redesign-audit.md
new file mode 100644
index 000000000..4219815a4
--- /dev/null
+++ b/skills/design-taste/references/redesign-audit.md
@@ -0,0 +1,155 @@
+# Redesign Audit
+
+Use this when improving an existing UI. Work with the current stack and design system. Do not rewrite from scratch unless the user asks.
+
+## Workflow
+
+1. **Scan:** Identify framework, styling method, component library, tokens, current layout patterns, and interaction primitives.
+2. **Diagnose:** Find weak hierarchy, generic patterns, missing states, accessibility issues, and implementation risks.
+3. **Fix:** Apply focused upgrades with the existing stack.
+4. **Verify:** Check responsive behavior, states, contrast, and no broken imports.
+
+## Typography
+
+Look for:
+
+- Browser defaults or a generic font used where personality matters.
+- Headings with no presence or poor line breaks.
+- Body text wider than 65-75 characters.
+- Only 400 and 700 weights, with no subtle hierarchy.
+- Proportional figures in dense data UI.
+- All-caps labels everywhere.
+- Orphaned words in headings.
+
+Better:
+
+- Respect project fonts if they are established.
+- Use `text-wrap: balance` for headings and `text-wrap: pretty` for paragraphs where supported.
+- Use tabular figures for metrics, prices, timers, tables, and dashboards.
+- Use type scale contrast intentionally: one dominant element, not many.
+
+## Color And Surfaces
+
+Look for:
+
+- Pure black or pure white where a slightly tinted neutral would feel better.
+- Oversaturated accents.
+- More than one accent color competing in the same view.
+- Warm and cool grays mixed accidentally.
+- Purple/blue AI-gradient aesthetics.
+- Generic black shadows at low opacity.
+- Sudden dark sections inside otherwise light pages.
+- Flat sections that feel empty because hierarchy or content is weak.
+
+Better:
+
+- One coherent neutral family.
+- One accent per view unless semantics require more.
+- Tinted shadows that match the environment.
+- Subtle texture, image, or atmospheric depth only when it supports the content.
+- Gradients at section scale, not on text or controls.
+
+## Layout
+
+Look for:
+
+- Everything centered and symmetrical.
+- Generic three equal feature cards.
+- `height: 100vh` full-screen sections that break mobile browser chrome.
+- Complex flexbox percentage math.
+- Missing max-width constraints.
+- Forced equal-height cards with uneven content.
+- Uniform radii everywhere.
+- Awkward gaps or baselines in side-by-side elements.
+- Dashboard layouts that default to a left sidebar without considering workflow.
+
+Better:
+
+- `min-height: 100dvh` or `min-h-dvh` for viewport-height sections.
+- CSS Grid for real multi-column structures.
+- Optical alignment for icons, button text, and visual centers.
+- Mobile collapse planned explicitly.
+- Cards only where containment helps.
+
+## Interaction And States
+
+Look for:
+
+- No hover, active, focus, loading, empty, or error states.
+- Generic circular spinners where skeletons would match the layout.
+- `window.alert()` for errors.
+- Buttons linked to `#`.
+- No active navigation state.
+- Instant state changes that feel broken.
+- Layout-triggering animation.
+
+Better:
+
+- Pressed feedback on buttons and tappable surfaces.
+- Skeletons that match final content dimensions.
+- Helpful empty states with one clear next action.
+- Inline, actionable errors.
+- Active navigation visible enough to scan.
+- Transform/opacity animation.
+
+## Content And Data
+
+Look for:
+
+- Generic names: John Doe, Jane Smith, Acme, Nexus, SmartFlow.
+- Fake-perfect numbers: `99.99%`, `50%`, `$100.00`.
+- AI copy cliches: Elevate, Seamless, Unleash, Next-Gen, Game-changer, Delve, Tapestry.
+- Lorem ipsum.
+- All dates identical.
+- Same avatar reused for multiple people.
+- Title Case on every heading.
+
+Better:
+
+- Specific, believable names and examples.
+- Organic values: `47.2%`, `$99.00`, realistic phone numbers, varied dates.
+- Plain verbs and concrete product language.
+- Sentence case unless the brand system says otherwise.
+
+## Component Patterns
+
+Look for:
+
+- Border + shadow + white background on every card.
+- One filled button plus one ghost button on every section.
+- Generic pill badges.
+- FAQ accordions for everything.
+- Three testimonial cards with dots.
+- Modals for simple inline edits.
+- Avatar circles everywhere.
+- Footer link farms.
+
+Better:
+
+- Use spacing, dividers, and typography before adding containers.
+- Use tertiary text links where actions are not peers.
+- Use inline editing, slide-overs, or expansion before modals.
+- Make navigation and footer match actual user paths.
+
+## Code Quality
+
+Look for:
+
+- Div soup instead of semantic HTML.
+- Inline styles mixed into a styled system.
+- Hardcoded fixed widths where responsive constraints are needed.
+- Missing alt text.
+- Arbitrary z-index values.
+- Commented-out dead code.
+- Import hallucinations.
+- Missing title, description, and social metadata on pages where sharing matters.
+
+## Fix Priority
+
+1. Clarify hierarchy.
+2. Clean color palette and accents.
+3. Add missing interaction states.
+4. Fix layout, spacing, max-width, and responsive behavior.
+5. Replace generic component patterns.
+6. Add loading, empty, and error states.
+7. Polish type, alignment, and micro-details.
diff --git a/skills/design-taste/references/shadcn-implementation.md b/skills/design-taste/references/shadcn-implementation.md
new file mode 100644
index 000000000..ef808ebc7
--- /dev/null
+++ b/skills/design-taste/references/shadcn-implementation.md
@@ -0,0 +1,57 @@
+# Shadcn Implementation
+
+Use this when the project uses shadcn/ui, Radix UI, Base UI, Tailwind CSS, `components.json`, or a `components/ui` directory.
+
+## Core Model
+
+shadcn/ui is copied source, not a black-box component package. Treat it as project-owned code with a stable primitive foundation.
+
+## Before Editing
+
+- Check `components.json`.
+- Check Tailwind version and configuration.
+- Check path aliases.
+- Check whether primitives are Radix UI or Base UI.
+- Check existing `components/ui` variants before adding new ones.
+- Check installed dependencies before importing a package.
+
+## Composition Rules
+
+- Prefer composing from existing `components/ui` before creating new primitives.
+- Keep primitive components generic and reusable.
+- Put product-specific wrappers outside `components/ui`.
+- Do not fork a primitive for one screen when a wrapper or variant would solve it.
+- Preserve ARIA attributes, keyboard behavior, focus management, and disabled semantics.
+
+## Customization Rules
+
+- Customize theme tokens before scattering one-off classes.
+- Use `cn()` for class merging.
+- Use `cva` or the local variant pattern when the component already uses it.
+- Keep variants semantic: `primary`, `secondary`, `destructive`, `ghost`, `compact`, not `blue`, `big`, `marketing`.
+- Do not leave default shadcn styling untouched if the project has a distinct brand language.
+- Do not mix multiple primitive systems inside one interaction surface.
+
+## Taste Rules
+
+- shadcn gives structure, not taste. The default look is a starting point, not a design direction.
+- Avoid stacking shadcn cards inside shadcn cards.
+- Avoid the default SaaS pattern of `CardHeader`, `CardContent`, icon, title, description repeated everywhere.
+- Make active navigation obvious enough to scan.
+- Use semantic color and spacing tokens from the project.
+- Keep radii consistent with the system. Inner radii should be smaller than outer radii.
+
+## Forms
+
+- Labels should be visible.
+- Error messages should sit near the field.
+- Helper text should be associated with the input.
+- Loading and disabled states should be explicit.
+- Use established form libraries only if the project already uses them or the form complexity justifies it.
+
+## Verification
+
+- Typecheck after adding components or variants.
+- Test keyboard navigation for menus, dialogs, popovers, tabs, and dropdowns.
+- Check mobile layout and touch targets.
+- Check focus indicators after visual customization.
diff --git a/skills/design-taste/references/visual-dials.md b/skills/design-taste/references/visual-dials.md
new file mode 100644
index 000000000..c1791de88
--- /dev/null
+++ b/skills/design-taste/references/visual-dials.md
@@ -0,0 +1,58 @@
+# Visual Dials
+
+Use these dials to calibrate visual direction without turning taste into a pile of absolute rules.
+
+## The Three Dials
+
+### Design Variance
+
+How conventional or surprising the composition should be.
+
+- **1-3: Predictable.** Symmetrical, centered, familiar, low-risk. Good for admin, settings, healthcare, finance, compliance, internal tools.
+- **4-7: Distinctive.** Asymmetry, varied section rhythm, intentional offsets, stronger type contrast. Good for polished SaaS, product pages, portfolios, editorial product UI.
+- **8-10: Art-directed.** Broken grids, large whitespace, unusual image crops, expressive pacing. Good for campaigns, launch pages, creative portfolios, brand moments.
+
+Guardrail: high variance must still collapse cleanly on mobile. At small widths, prioritize order, readability, and touch targets over preserving desktop drama.
+
+### Motion Intensity
+
+How much animation the interface can carry.
+
+- **1-3: Quiet.** Hover, focus, active states only. Good for dense tools, repeated workflows, dashboards, settings, data entry.
+- **4-7: Fluid.** Page or section reveals, tab indicators, popovers, toasts, subtle shared transitions. Good for most product UI.
+- **8-10: Choreographed.** Scrolltelling, pinned sections, 3D/canvas, complex timelines, cinematic reveals. Good for marketing, storytelling, product launches, demos.
+
+Guardrail: motion intensity should drop as task frequency rises. The more often users perform an action, the less animation it should have.
+
+### Visual Density
+
+How much information belongs on one screen.
+
+- **1-3: Airy.** Premium, editorial, sparse, image-led, high whitespace.
+- **4-7: Balanced.** Standard app/product density with clear grouping and scanability.
+- **8-10: Dense.** Dashboards, command centers, data tools, operational workflows.
+
+Guardrail: density does not mean cramming. Dense UI needs stronger alignment, smaller type hierarchy, tabular figures, dividers, and reduced decoration.
+
+## Defaults By Product Type
+
+- **Operational SaaS:** variance 3-5, motion 1-3, density 6-9.
+- **Marketing landing page:** variance 5-8, motion 4-7, density 2-5.
+- **Portfolio or creative studio:** variance 7-10, motion 5-8, density 1-4.
+- **Financial/admin dashboard:** variance 2-4, motion 1-3, density 7-10.
+- **Consumer mobile app:** variance 4-7, motion 4-7, density 4-7.
+- **Luxury/editorial brand:** variance 5-8, motion 2-5, density 1-3.
+
+## How To Apply
+
+Before designing, infer the dial settings from the product, audience, and task. If the user gives direction, let it override the defaults.
+
+Use the dials to decide:
+
+- Whether to use symmetry or asymmetry.
+- Whether cards should be framed or content should float.
+- Whether motion should be invisible, fluid, or cinematic.
+- Whether whitespace should expand or tighten.
+- Whether typography should be utilitarian or expressive.
+
+Do not expose the dials to the user unless it helps explain a design choice.
diff --git a/skills/design-taste/scripts/slop-scan.js b/skills/design-taste/scripts/slop-scan.js
new file mode 100644
index 000000000..83e6d8cd9
--- /dev/null
+++ b/skills/design-taste/scripts/slop-scan.js
@@ -0,0 +1,72 @@
+// Counts the markers of generated-looking UI on a rendered page. Paste it into the browser console, or run it with your browser tool.
+// Read-only. The counts are not a verdict: they point at where to look, and are most useful before vs after.
+//   accent           elements painted in the most used saturated color (text, background or border)
+//   hues             distinct saturated hues in use (30° buckets)
+//   uppercase        text set in uppercase (by CSS or by typing), and uppercase labels right above a heading (eyebrows)
+//   gradients        backgrounds with gradients; gradient text (background-clip: text)
+//   glows            colored shadows with a large blur
+//   iconChips        small boxes with a tinted or translucent background holding one icon
+//   pills            fully rounded elements with a background (badges, chips, buttons)
+//   accentRoles      for the most used saturated color: how many elements use it as a link or control, as status or
+//                    other text, and as a fill without text (bars, dots) — one hue doing all three is a place to look
+//   nestedCards      card-like boxes (own fill or border, radius ≥ 6, ≥ 120×60) inside another card-like box
+//   fontSizes, radii distinct values in use
+//   transitionAll, backdropFilter  counts
+(() => {
+  const cv = document.createElement('canvas'); cv.width = cv.height = 1
+  const cx = cv.getContext('2d', { willReadFrequently: true })
+  const memo = new Map()
+  const rgba = v => { if (memo.has(v)) return memo.get(v); let o = null; if (v && v !== 'transparent') { cx.clearRect(0, 0, 1, 1); cx.fillStyle = '#000'; cx.fillStyle = v; cx.fillRect(0, 0, 1, 1); const d = cx.getImageData(0, 0, 1, 1).data; o = [d[0], d[1], d[2], d[3] / 255] } memo.set(v, o); return o }
+  const hsl = ([r, g, b]) => { r /= 255; g /= 255; b /= 255; const mx = Math.max(r, g, b), mn = Math.min(r, g, b), l = (mx + mn) / 2, d = mx - mn; if (!d) return [0, 0, l]; const s = d / (1 - Math.abs(2 * l - 1)); let h = mx === r ? ((g - b) / d) % 6 : mx === g ? (b - r) / d + 2 : (r - g) / d + 4; return [(h * 60 + 360) % 360, s, l] }
+  const saturated = c => c && c[3] > 0.15 && (([, s, l]) => s > 0.45 && l > 0.2 && l < 0.85)(hsl(c))
+  const key = c => c.slice(0, 3).map(v => Math.round(v / 8)).join(',')
+  const vis = e => { const r = e.getBoundingClientRect(), s = getComputedStyle(e); return r.width > 0 && r.height > 0 && s.visibility !== 'hidden' && s.display !== 'none' && +s.opacity > 0.05 }
+  const sel = e => { const c = typeof e.className === 'string' ? e.className.trim().split(/\s+/).slice(0, 2).join('.') : ''; return e.tagName.toLowerCase() + (c ? '.' + c : '') }
+  const all = [...document.body.querySelectorAll('*')].filter(vis)
+  const ownText = e => [...e.childNodes].filter(n => n.nodeType === 3).map(n => n.textContent).join('').trim()
+
+  const colorUse = new Map(), roleUse = new Map(), hues = new Set(), sizes = new Set(), radii = new Set()
+  const out = { uppercase: 0, eyebrows: [], gradients: 0, gradientText: 0, glows: 0, iconChips: [], pills: 0, transitionAll: 0, backdropFilter: 0 }
+  for (const e of all) {
+    const s = getComputedStyle(e), r = e.getBoundingClientRect(), text = ownText(e)
+    const svg = e instanceof SVGElement && !(e instanceof SVGSVGElement)
+    const paints = [text ? s.color : null, s.backgroundColor, parseFloat(s.borderTopWidth) > 0 ? s.borderTopColor : null, svg && s.fill !== 'none' ? s.fill : null, svg && s.stroke !== 'none' ? s.stroke : null].map(v => v && !/^url/.test(v) ? rgba(v) : null).filter(saturated)
+    for (const c of new Set(paints.map(key))) colorUse.set(c, (colorUse.get(c) || 0) + 1)
+    for (const c of new Set(paints.map(key))) { if (!roleUse.has(c)) roleUse.set(c, { control: 0, text: 0, fill: 0 }); const r = roleUse.get(c); if (e.closest('a,button,[role=button],[role=tab]')) r.control++; else if (text) r.text++; else r.fill++ }
+    for (const c of paints) hues.add(Math.floor(hsl(c)[0] / 30))
+    if (text) {
+      sizes.add(s.fontSize)
+      const upper = s.textTransform === 'uppercase' || (text.length > 3 && /[A-ZА-Я]/.test(text) && text === text.toUpperCase())
+      if (upper) {
+        out.uppercase++
+        const next = e.nextElementSibling || e.parentElement?.nextElementSibling
+        if (next && (/^H[1-3]$/.test(next.tagName) || parseFloat(getComputedStyle(next).fontSize) >= parseFloat(s.fontSize) * 1.8)) out.eyebrows.push(text.slice(0, 40))
+      }
+    }
+    if (/gradient/.test(s.backgroundImage)) { out.gradients++; if (/text/.test(s.backgroundClip + s.webkitBackgroundClip)) out.gradientText++ }
+    for (const sh of s.boxShadow === 'none' ? [] : s.boxShadow.split(/,(?![^()]*\))/)) {
+      const c = rgba((sh.match(/(rgba?|oklch|color)\([^)]*\)|#[0-9a-f]+/i) || [])[0]); const blur = (sh.match(/(-?\d+(?:\.\d+)?)px/g) || []).map(parseFloat)[2] || 0
+      if (saturated(c) && blur >= 16) { out.glows++; break }
+    }
+    const rad = parseFloat(s.borderTopLeftRadius); if (rad > 0) radii.add(rad >= 999 || rad >= r.height / 2 - 0.5 ? 'pill' : rad)
+    const solid = rgba(s.backgroundColor)
+    const bg = solid && solid[3] > 0 ? solid : /gradient/.test(s.backgroundImage) ? [0, 0, 0, 0.5] : null
+    if (bg && bg[3] > 0 && rad >= r.height / 2 - 0.5 && r.height <= 40 && text) out.pills++
+    if (bg && bg[3] > 0 && r.width <= 56 && r.height <= 56 && Math.abs(r.width - r.height) < 4 && e.children.length === 1 && /^(svg|img|i|span)$/i.test(e.children[0].tagName) && !text && !e.matches('button,a,[role=button]') && (bg[3] < 1 || saturated(bg))) out.iconChips.push(sel(e))
+    if (/(^|,\s*)all\b/.test(s.transitionProperty) && parseFloat(s.transitionDuration) > 0) out.transitionAll++
+    if ((s.backdropFilter || s.webkitBackdropFilter || 'none') !== 'none') out.backdropFilter++
+  }
+  const cardLike = e => { const s = getComputedStyle(e), r = e.getBoundingClientRect(); const fill = rgba(s.backgroundColor); return r.width >= 120 && r.height >= 60 && parseFloat(s.borderTopLeftRadius) >= 6 && ((fill && fill[3] > 0) || (parseFloat(s.borderTopWidth) > 0 && s.borderTopStyle !== 'none')) }
+  const cardEls = all.filter(cardLike)
+  const nested = cardEls.filter(e => { for (let n = e.parentElement; n && n !== document.body; n = n.parentElement) if (cardEls.includes(n)) return true; return false })
+  const ranked = [...colorUse.entries()].sort((a, b) => b[1] - a[1])
+  return {
+    viewport: `${innerWidth}×${innerHeight}`, elements: all.length,
+    accent: ranked[0] ? { rgb: ranked[0][0].split(',').map(v => v * 8), elements: ranked[0][1] } : null,
+    accentRoles: ranked[0] ? roleUse.get(ranked[0][0]) : null,
+    saturatedColors: ranked.length, hues: hues.size,
+    ...out, eyebrows: out.eyebrows.slice(0, 15), iconChips: { count: out.iconChips.length, examples: [...new Set(out.iconChips)].slice(0, 8) },
+    nestedCards: { count: nested.length, examples: [...new Set(nested.map(sel))].slice(0, 6) },
+    fontSizes: sizes.size, radii: [...radii].sort((a, b) => (a === 'pill') - (b === 'pill') || a - b),
+  }
+})()