@mohammadhprp/system-prompt 0.11.2 → 0.12.1

package/framework/skills/great-interface/references/surfaces.md

@@ -0,0 +1,219 @@
+# Surfaces
+
+Border radius, optical alignment, shadows and image outlines.
+
+## Concentric border radius
+
+When nesting rounded elements, the outer radius must equal the inner radius plus the padding between them:
+
+```
+outerRadius = innerRadius + padding
+```
+
+The rule matters most when nested surfaces sit close together. Past `24px` of padding, treat the layers as separate surfaces and choose each radius independently rather than forcing concentric math.
+
+### Example
+
+```css
+/* Good: concentric radii */
+.card {
+  border-radius: 20px; /* 12 + 8 */
+  padding: 8px;
+}
+.card-inner {
+  border-radius: 12px;
+}
+
+/* Bad: same radius on both */
+.card {
+  border-radius: 12px;
+  padding: 8px;
+}
+.card-inner {
+  border-radius: 12px;
+}
+```
+
+### Tailwind example
+
+```tsx
+// Good: outer radius accounts for padding
+<div className="rounded-2xl p-2">       {/* 16px radius, 8px padding */}
+  <div className="rounded-lg">          {/* 8px radius = 16 - 8 ✓ */}
+    ...
+  </div>
+</div>
+
+// Bad: same radius on both
+<div className="rounded-xl p-2">
+  <div className="rounded-xl">          {/* same radius, looks off */}
+    ...
+  </div>
+</div>
+```
+
+Mismatched radii on closely nested surfaces are a common source of visual tension. Calculate concentrically where the layers share a visible, even inset. Keep an established component token where they are independent or the padding is deliberately asymmetric.
+
+## Optical alignment
+
+When geometric centering looks off, align optically instead.
+
+### Buttons with text + icon
+
+Where an icon makes symmetric padding look unbalanced, use slightly less on the icon side. A starting point:
+`icon-side padding = text-side padding - 2px`.
+
+```css
+/* Good: less padding on icon side */
+.button-with-icon {
+  padding-inline-start: 16px;
+  padding-inline-end: 14px; /* trailing icon side = text side - 2px */
+}
+
+/* Bad: equal padding looks like icon is pushed too far right */
+.button-with-icon {
+  padding-inline: 16px;
+}
+```
+
+```tsx
+// Tailwind
+<button className="ps-4 pe-3.5 flex items-center gap-2">
+  <span>Continue</span>
+  <ArrowRightIcon />
+</button>
+```
+
+### Play button triangles
+
+Play icons are triangular and their geometric center is not their visual center. Shift slightly right:
+
+```css
+/* Good: optically centered */
+.play-button svg {
+  transform: translateX(2px); /* physical correction to the glyph itself */
+}
+
+/* Bad: geometrically centered but looks off */
+.play-button svg {
+  /* no adjustment */
+}
+```
+
+### Asymmetric icons (stars, arrows, carets)
+
+Some icons carry uneven visual weight. The best fix is adjusting the SVG directly, so the component needs no extra margin or padding.
+
+```tsx
+// Best: fix in the SVG itself
+// Adjust the viewBox or path to visually center the icon
+
+// Fallback: adjust with margin
+<span className="translate-x-px">
+  <StarIcon />
+</span>
+```
+
+## Shadows instead of borders
+
+Where **buttons, cards and containers** use a border for depth or elevation, replace it with a subtle `box-shadow`. Shadows use transparency, so they adapt to any background where solid borders do not. That matters most over images or multiple background colors, which a fixed border color was never designed for.
+
+**Never apply this to dividers**, meaning `border-b`, `border-t` and side borders, or any border whose purpose is layout separation rather than depth. Those stay borders.
+
+### Shadow as border (light mode)
+
+Three layers. The first acts as a 1px border ring, the second adds subtle lift, the third ambient depth:
+
+```css
+:root {
+  --shadow-border:
+    0px 0px 0px 1px oklch(0 0 0 / 0.06),
+    0px 1px 2px -1px oklch(0 0 0 / 0.06),
+    0px 2px 4px 0px oklch(0 0 0 / 0.04);
+  --shadow-border-hover:
+    0px 0px 0px 1px oklch(0 0 0 / 0.08),
+    0px 1px 2px -1px oklch(0 0 0 / 0.08),
+    0px 2px 4px 0px oklch(0 0 0 / 0.06);
+}
+```
+
+### Shadow as border (dark mode)
+
+In dark mode, simplify to one white ring, since layered depth shadows are invisible on dark backgrounds:
+
+```css
+/* Dark mode: adapt to whatever setup the project uses
+   (prefers-color-scheme, class, data attribute, etc.) */
+--shadow-border: 0 0 0 1px oklch(1 0 0 / 0.08);
+--shadow-border-hover: 0 0 0 1px oklch(1 0 0 / 0.13);
+```
+
+### Usage with hover transition
+
+Apply the variable and add `transition-[box-shadow]` for a smooth hover:
+
+```css
+.card {
+  box-shadow: var(--shadow-border);
+  transition-property: box-shadow;
+  transition-duration: 150ms;
+  transition-timing-function: ease-out;
+}
+
+.card:hover {
+  box-shadow: var(--shadow-border-hover);
+}
+```
+
+### When to use shadows vs. borders
+
+| Use shadows | Use borders |
+| --- | --- |
+| Cards, containers with depth | Dividers between list items |
+| Buttons with bordered styles | Table cell boundaries |
+| Elevated elements (dropdowns, modals) | Form input outlines (for accessibility) |
+| Elements on varied backgrounds | Hairline separators in dense UI |
+| Hover/focus states for lift effect | |
+
+## Image outlines
+
+Add a `1px` outline at low opacity to images for consistent depth, especially where other elements use borders or shadows.
+
+### Color rules (non-negotiable)
+
+- **Light mode**: pure black, `oklch(0 0 0 / 0.1)`.
+- **Dark mode**: pure white, `oklch(1 0 0 / 0.1)`.
+- Never a near-black or near-white from the project palette, such as slate-900, zinc-900, `#0a0a0a`, `#111827`, or `#f5f5f7`. Tinted outlines pick up the surrounding surface color and read as dirt on the image edge.
+- Never match the outline to the project's accent or ink color. The outline is a neutral separator, not a themed element.
+
+### Light mode
+
+```css
+img {
+  outline: 1px solid oklch(0 0 0 / 0.1);
+  outline-offset: -1px; /* draw the ring just inside the image edge */
+}
+```
+
+### Dark mode
+
+```css
+img {
+  outline: 1px solid oklch(1 0 0 / 0.1);
+  outline-offset: -1px;
+}
+```
+
+### Tailwind with dark mode
+
+```tsx
+<img
+  className="outline outline-1 -outline-offset-1 outline-black/10 dark:outline-white/10"
+  src={src}
+  alt={alt}
+/>
+```
+
+Use `outline-black/10` and `outline-white/10` specifically, not `outline-slate-*`, `outline-zinc-*`, `outline-neutral-*`, or any tinted scale.
+
+**Why outline instead of border?** `outline` never affects layout, adding no width or height at any offset, and `outline-offset: -1px` draws the ring just inside the image edge so it hugs the corner radius.

package/framework/skills/great-interface/references/token-naming.md

@@ -0,0 +1,97 @@
+# Token naming
+
+Naming is what makes a palette usable by anyone who did not build it. For which ramps exist and what each step does, see [palette-structure.md](palette-structure.md).
+
+## Two tiers
+
+**Primitives** name a value. They are the ramp, named by hue and step: `--blue-500`, `--neutral-200`. A primitive describes what the color *is*, so it never changes meaning between themes and is never applied directly in a component.
+
+**Semantics** name a job. They point at a primitive and take the name of the role they fill: `--color-text-secondary`, `--color-border-subtle`. Components only ever reference this tier.
+
+```css
+:root {
+  /* Tier 1: primitives, named by appearance. Never used directly. */
+  --blue-500: #3b82f6;
+  --neutral-200: #e5e7eb;
+  --neutral-700: #374151;
+
+  /* Tier 2: semantics, named by role. This is what components use. */
+  --color-accent-solid: var(--blue-500);
+  --color-border: var(--neutral-200);
+  --color-text-secondary: var(--neutral-700);
+}
+```
+
+The tiering is what makes theming possible. Dark mode, a white-label theme and an increased-contrast variant all repoint the semantic tier, leaving the primitives and every component untouched. A codebase applying `--blue-500` directly in components has no theming seam. Adding one later means auditing every usage to work out which meant "the accent" and which just wanted blue.
+
+Add a third, component-level tier (`--color-button-danger-bg`) only where a component genuinely and intentionally diverges from the system. One component token is a documented exception; twenty mean the semantic tier is missing roles.
+
+## The role inventory
+
+A system is complete when every role below has a token. Build against this list rather than adding tokens as components demand them, or the palette ends up shaped like whichever screen came first.
+
+| Group | Roles |
+| --- | --- |
+| Surfaces | page background, surface, raised (menus, popovers), sunken (inputs, wells), overlay scrim |
+| Text | primary, secondary, disabled, inverse, on-accent |
+| Borders | subtle, default, strong, focus ring, separator |
+| Accent | subtle background, border, solid, solid hover, text |
+| Status | per status shipped: subtle background, border, solid, text |
+
+Separator and border are separate roles even when they share a value today. A separator divides content; a border encloses a control. They diverge the first time someone restyles inputs, and a system that conflated them gets untangled at that moment.
+
+## Naming grammar
+
+Use one shape and never deviate: `--color-{role}-{variant}-{state}`.
+
+```css
+--color-bg-surface
+--color-text-secondary
+--color-border-strong
+--color-accent-solid-hover
+```
+
+Pick one word per concept and use only that word. Consistency matters more than the vocabulary. A reader who has seen `--color-text-primary` must be able to guess `--color-text-disabled` without looking:
+
+| Concept | Pick one | Never mix in |
+| --- | --- | --- |
+| Foreground | `text` | `fg`, `foreground`, `content`, `ink` |
+| Background | `bg` | `background`, `surface` as a synonym, `fill` |
+| Edge | `border` | `stroke`, `outline`, `line` |
+| Brand color | `accent` | `primary`, `brand`, `theme` used interchangeably |
+
+Reserve `primary` for exactly one meaning. `--color-text-primary` for body text beside `--color-primary` for the brand is the most common naming collision there is, and it makes every `primary` token ambiguous until you open its definition. Use `accent` for the brand and let `primary` mean "the most prominent of its group".
+
+## Anti-patterns
+
+| Name | Problem | Instead |
+| --- | --- | --- |
+| `--color-blue-button` | Appearance at the semantic tier; lies the moment the brand changes | `--color-accent-solid` |
+| `--color-sidebar-gray` | Named for where it was used first; the second usage makes it nonsense | `--color-bg-surface` |
+| `--color-light-gray` | Lies in dark mode, where it is the dark one | `--neutral-200` as a primitive |
+| `--color-text-2` | Numbered semantics carry no meaning; nobody can guess what `3` would be | `--color-text-secondary` |
+| `--color-gray-hover` | Mixes a hue with a state and belongs to no tier | `--color-bg-surface-hover` |
+| `--blue-500` used in a component | Skips the semantic tier and removes the theming seam | Point a semantic token at it |
+
+Every one of them is a case of **Use a token only in its role**. See [color-usage.md](color-usage.md).
+
+## In Tailwind projects
+
+Tailwind v4 generates utilities from `@theme`, so names declared there become the API. Declare primitives and semantics in the same block; the `--color-*` namespace is what produces `bg-*`, `text-*` and `border-*`:
+
+```css
+@theme {
+  /* Primitives */
+  --color-brand-50: #eff6ff;
+  --color-brand-500: #3b82f6;
+  --color-brand-900: #1e3a8a;
+
+  /* Semantics: what templates should use */
+  --color-accent-solid: var(--color-brand-500);
+  --color-text-secondary: var(--color-neutral-700);
+}
+```
+
+That yields `bg-accent-solid` and `text-secondary` alongside `bg-brand-500`. Both are reachable, so the discipline is a convention rather than a constraint. Templates use the semantic utilities, and a raw `bg-brand-500` in a component is the thing to flag.
+
+Opacity modifiers work on either tier, as in `bg-accent-solid/50`. But a color carrying alpha cannot be contrast-checked against a static background, because what it renders depends on what sits behind it. Use solid tokens for anything with text on it.

package/framework/skills/great-interface/references/variable-fonts-and-opentype.md

@@ -0,0 +1,105 @@
+# Variable fonts and OpenType
+
+What a font file can do beyond drawing letters and how to reach those abilities from CSS.
+
+## Static vs variable
+
+- **Static font:** one weight and one style per file. Regular, medium and bold is three files.
+- **Variable font:** a whole range in one file. Any value in it works, such as `font-weight: 589`.
+
+A variable font is not automatically better. At one or two weights, static files can be smaller. At several weights, optical sizes, or custom axes, a variable font usually wins.
+
+## Load intended weights and styles
+
+Use a weight or style the active family does not provide and the browser may synthesize it, so load the faces the design uses. `none` disables weight, style, small-cap, superscript and subscript synthesis together and can erase distinctions when the real face is unavailable. Verify the whole fallback stack and every emphasis state before setting it.
+
+```css
+.brand-wordmark {
+  /* Safe only after this isolated treatment is verified */
+  font-synthesis: none;
+}
+```
+
+For body and interface text, keep synthesis enabled unless a verified font setup supplies every requested form. If only one mode is unwanted, use the specific longhand (`font-synthesis-weight`, `font-synthesis-style` and related properties) instead of the blanket shorthand.
+
+## Axes
+
+Variable-font controls, each with a four-letter tag. A font supports only the axes its designer included.
+
+| Axis | Tag | Controls |
+| --- | --- | --- |
+| Weight | `wght` | Stroke thickness (like `font-weight`) |
+| Optical size | `opsz` | Details and spacing tuned for the display size |
+| Width | `wdth` | Glyph width |
+| Slant | `slnt` | Slant angle |
+| Custom | e.g. `GRAD` (Roboto Flex) | Whatever the designer built |
+
+Inter's variable file exposes only `wght` and `opsz`.
+
+Optical sizes predate variable fonts, and many families still ship them as separate files. Heldane Text is sturdier and more spaced for reading sizes, Heldane Display finer for large ones.
+
+## Properties over axis tags
+
+When a property exists, use it. `font-weight` keeps working when a non-variable fallback renders, where `font-variation-settings` silently does nothing. Save raw tags for custom axes with no property of their own:
+
+```css
+/* Good: common axes use the properties */
+.heading {
+  font-weight: 650;
+  font-optical-sizing: auto;
+}
+
+/* Good: custom axis with no property of its own */
+.heading-grade {
+  font-variation-settings: "GRAD" 80;
+}
+
+/* Bad: weight via raw tag breaks on fallback fonts */
+.heading {
+  font-variation-settings: "wght" 650;
+}
+```
+
+## OpenType features
+
+OpenType is the standard behind almost every modern font. Features are extra built-in options and, unlike axes, work the same on static and variable fonts. A font ships only the features its designer included.
+
+| Tag | Feature |
+| --- | --- |
+| `tnum` | Tabular numbers: every digit the same width |
+| `zero` | Slashed zero: `0` distinct from `O` |
+| `liga` | Ligatures: joins pairs like "fi" into one shape |
+| `ss01`–`ss20` | Stylistic sets (numbered slots) |
+| `cv01`–`cv99` | Character variants (numbered slots) |
+
+Same rule as axes. Prefer the `font-variant-*` properties and reserve `font-feature-settings` for tags with no property:
+
+```css
+/* Good: common features use the properties */
+.price {
+  font-variant-numeric: tabular-nums;
+}
+
+/* Good: slashed zero via the property too */
+.id {
+  font-variant-numeric: slashed-zero;
+}
+
+/* Good: niche feature with no property of its own */
+.logo {
+  font-feature-settings: "ss01" 1;
+}
+```
+
+Tabular numbers matter for changing values. Without them each digit has a different width and the layout shifts as values update.
+
+## Small caps, superscripts, subscripts
+
+- **Small capitals:** uppercase letters drawn at a smaller size. Enable real ones with `font-variant-caps`.
+- **Superscripts** sit above the normal line, the 2 in x², and **subscripts** below it, as in H₂O. Enable proper glyphs with `font-variant-position`.
+
+Both require the font to include the glyphs.
+
+## Stylistic sets and character variants
+
+`ss01` = stylistic set, slot 01. `cv11` = character variant, slot 11. What each slot does differs font to font, which is why they are numbered, not named. Check the font's docs. In Inter, `ss01` switches to open digits and `cv11` swaps in a single-story `a`.

package/framework/skills/great-interface/references/variant.md

@@ -0,0 +1,104 @@
+# Variants
+
+This skill takes one described piece of UI and builds three versions that differ on purpose. They go behind a picker in the real page, so you can flip between them and choose.
+
+Every other skill here judges. This one produces candidates and hands the decision back. Reviewing existing UI is `interface-review` and `better-interface`, and it does not pick the winner.
+
+## Different answers, not different tints
+
+Three variants that differ in accent color teach nothing. You flip between them, see no real choice and the run is wasted.
+
+So each variant is a different answer to the same brief, on an axis this collection owns:
+
+| Axis | Owner | What varies |
+| --- | --- | --- |
+| Structure | `better-layout` | Grouping, order, column count, what collapses |
+| Density | `better-layout` | Spacing scale, hit areas, how much fits |
+| Emphasis | `better-colors` | Where filled color goes, what recedes |
+| Type | `better-typography` | Scale steps, weight contrast, measure |
+| Voice | `better-writing` | Labels, tone, how much copy |
+
+Pick **one primary axis** and give each variant a different position on it. Secondary choices follow from it rather than varying on their own. A dense variant may need a smaller type step, and that is coherence, not a second axis.
+
+Varying every axis at once produces three unattributable results. You learn which you liked, not what made it work, so the next piece starts from nothing.
+
+## The floor every variant clears
+
+A variant that wins on looks and fails an escalation trigger is not a candidate. It is a bug with a nice surface.
+
+Before a variant enters the picker it clears `better-interface`'s escalation triggers. Every control has an accessible name, keyboard reaches everything a pointer does, focus is visible, nothing clips at 320px and no meaning rides on color alone.
+
+That floor is identical across variants. It is not an axis and never trades against one. Where a direction can only work by breaking it, say so and drop the direction.
+
+## 1. Scope one piece
+
+One piece of UI per run. "The dashboard" is not a piece; the metric card is. Where the brief spans several, name the one the others hang off, say why and offer the rest as later runs.
+
+Restate the brief in one sentence: what the thing is, where it renders, what it has to do.
+
+## 2. Learn the ground
+
+Variants have to look like they could ship tomorrow, so read what they stand on:
+
+- The styling system, the component library and any motion library.
+- The tokens: color, spacing, radius, type scale, easing.
+- The product's density and voice. A dense professional tool bounds how far the boldest variant may go.
+- Where the piece renders: against what background, beside which neighbours, at which widths.
+
+With no project to read, use neutral grays, one accent and the system font stack, and say that is what you did.
+
+## 3. Name the axis before writing code
+
+Default to three variants. Go to five only when asked, or when the space is genuinely wide. Past five nobody compares, they scroll.
+
+Write the set down first, a name and an axis position each. Names say what the direction is, so `Quiet`, `Editorial`, `Dense`, never `Option A`.
+
+This step is done when no two variants share a position and you can state each one's axis in a phrase.
+
+## 4. Build it into the real page
+
+A variant looks fine in isolation, which is why isolation is the wrong place to judge it. Host the variants on the page that will actually contain the piece, with the real chrome, the real neighbours and realistic data.
+
+Select with a URL search param (`?variant=quiet`), so every variant is a link you can send someone. A floating control sets it; [picker.md]() holds the spec.
+
+Render one variant at a time, full size. Thumbnails distort spacing and scale, and spacing is usually the thing you are choosing between.
+
+Where no page can host it, build one self-contained HTML file and keep the same picker.
+
+Give every variant real content: product-shaped copy, plausible names and the number of items the page will really carry. Lorem ipsum and three rows make every structure look good.
+
+## 5. Present the tradeoffs and stop
+
+Flip through every variant yourself first. Each one renders, each interaction responds, the console is clean.
+
+Then hand the decision over:
+
+| Variant | Axis position | Right when | Costs |
+| --- | --- | --- | --- |
+| Quiet | Lowest visual weight | The page is used daily | Least memorable |
+| Editorial | Largest type, most space | The moment deserves weight | Eats vertical space |
+
+Say where the picker is running, which key flips it and which width you judged at. The answer can change between 375px and 1440px.
+
+Never mark a favourite in the table. Asked directly, answer from how often the piece is seen and from the product's personality, not from which one you enjoyed building.
+
+## 6. Promote one, delete the rest
+
+On a choice: build that variant properly where it belongs, following the project's own conventions, then delete the others and the harness.
+
+Asked for another round instead, keep the harness and run step 3 again, taking new positions around the direction you leaned toward.
+
+Until promotion, the harness never imports from production and production never imports from the harness.
+
+## Before you finish
+
+| Mistake | Fix |
+| --- | --- |
+| Variants differ only in accent color or copy | Move one to a different position on the primary axis, or cut it |
+| Every axis varies at once | Vary one; let the rest follow from it |
+| Judged on a blank route | Host them on the page that will contain the piece |
+| Lorem ipsum, three rows, "Jane Doe" | Real copy and the item count the page will really carry |
+| The boldest variant skips keyboard or focus | Clear the floor or drop the direction |
+| A favourite marked in the table | State each variant's cost and let the user choose |
+| Picker restyled with the project's tokens | Keep it visibly outside the design system |
+| Harness left behind after promotion | Delete it unless asked to keep it |

package/framework/skills/great-interface/references/wrapping-and-punctuation.md

@@ -0,0 +1,55 @@
+# Wrapping and punctuation
+
+Where lines start, where they end, where they break and which characters they use.
+
+## Measure (line length)
+
+Long lines make it harder for the eye to find the start of the next. For long-form text, aim for 60–75 characters per line.
+
+Any unit works. `65ch` measures characters directly, one `ch` being the width of the `0` in the current font, and a pixel or rem cap is just as good. At a `16px` body size the 60–75 character range lands roughly between `560px` and `680px` depending on the font, so Tailwind's `max-w-xl` (`576px`) and `max-w-2xl` (`672px`) both fit. What matters is that a cap exists and the line length sits in range. Recheck it if the body font size changes.
+
+## Alignment
+
+`text-align` controls where each line starts and ends. `justify` stretches spaces until both edges line up, which works in specific editorial layouts and nowhere else in an interface.
+
+## Wrapping
+
+| Property | Use |
+| --- | --- |
+| `text-wrap: balance` | Distributes text evenly across multiple lines |
+| `text-wrap: pretty` | Avoids leaving a single short word on the final line |
+| `overflow-wrap: break-word` | Lets long words, links and IDs break before escaping the container |
+| `white-space: nowrap` | Keeps labels and badges on one line where a break looks broken |
+
+Use `balance` on headings and `pretty` on descriptions. Skip both in long-form text, because browsers ignore `balance` past a few lines anyway, and evening out a whole paragraph wastes space and makes it harder to read.
+
+## Truncation
+
+- Single line: `text-overflow: ellipsis`, which needs `overflow: hidden` and `white-space: nowrap`.
+- Multiple lines: `line-clamp` allows any number of lines before the ellipsis.
+
+Truncation hides content. Where the missing text matters, make the full value available in a tooltip or an expanded view.
+
+## Case
+
+`text-transform` changes how case appears without changing the underlying text. Write copy naturally and control presentation with CSS, so a redesign never means rewriting copy.
+
+## Smart punctuation
+
+Keyboard characters are not always the best characters:
+
+| Instead of | Use |
+| --- | --- |
+| Straight quotes `"..."` | Curly quotes that curve around the text (keep straight quotes in code) |
+| Hyphen in ranges | En dash: `2010–2020` |
+| Two hyphens for an aside | Em dash character |
+| Three periods `...` | The single ellipsis character `…` |
+| Regular space in `16 px` | ` ` so the value never breaks apart |
+| Uncontrolled word breaks | `­` to mark where a word may break |
+
+## Internationalization
+
+Two refinements for mixed-direction text:
+
+- **Long paragraphs align by their own language.** A one- or two-line snippet follows the surrounding UI's direction. A paragraph of three or more lines aligns to its own script instead, so an English paragraph stays start-aligned LTR even inside an RTL interface. `text-align: start` with the correct `lang`/`dir` on the paragraph element handles this.
+- **Never reverse digits.** Numbers keep their order in every direction, so a phone number or "541" reads identically in RTL. Browsers handle this through the Unicode bidi algorithm. Never fight it with manual reordering, and wrap mixed number and text values in `<bdi>` where adjacent RTL text disturbs them.

package/framework/skills/taste/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: taste
+description: One skill for the full taste spectrum. Covers anti-slop frontend design (landing pages, portfolios, redesigns, premium and minimalist UI, GSAP motion), image generation and image-to-code direction (web, mobile, brand kits), full-output enforcement, and Google Stitch design systems. Read the brief, pick the matching reference below, and follow it end to end. Do not auto-apply every reference at once.
+---
+
+# TASTE — Unified Design Quality Skill
+
+You are an elite frontend design engineer and art director. This skill bundles every taste discipline into one entry point. Each reference below is a complete playbook for one domain.
+
+## How to use
+
+1. **Read the brief first.** Do not fire all references at once.
+2. **Route to the matching reference** using the table below.
+3. **Follow that reference end to end** — its directives override generic defaults.
+4. When a task spans domains (e.g. redesign an existing site that also needs new imagery), apply the relevant references in sequence and reconcile conflicting rules by task priority.
+
+## Reference library
+
+| When the task is… | Use |
+|---|---|
+| Anti-slop frontend for landing pages, portfolios, redesigns (current default) | [design-taste-frontend.md](references/design-taste-frontend.md) |
+| Exact backward-compatible v1 taste behavior (original baseline) | [design-taste-frontend-v1.md](references/design-taste-frontend-v1.md) |
+| Awwwards-level design engineering with GSAP motion, randomization, bento grids | [gpt-taste.md](references/gpt-taste.md) |
+| High-end agency visual design — fonts, spacing, shadows, motion choreography | [high-end-visual-design.md](references/high-end-visual-design.md) |
+| Premium utilitarian minimalism — warm monochrome, editorial type, flat bento | [minimalist-ui.md](references/minimalist-ui.md) |
+| Industrial brutalism / tactical telemetry UI — Swiss print, CRT terminals | [industrial-brutalist-ui.md](references/industrial-brutalist-ui.md) |
+| Upgrading an existing project to premium quality (audit-first, no rewrites) | [redesign-existing-projects.md](references/redesign-existing-projects.md) |
+| Completeness of output — no truncation, no placeholders, no skipped sections | [full-output-enforcement.md](references/full-output-enforcement.md) |
+| Generating website section reference images, then implementing them | [image-to-code.md](references/image-to-code.md) |
+| Generating website design-reference images (one image per section) | [imagegen-frontend-web.md](references/imagegen-frontend-web.md) |
+| Generating mobile app screen concepts and flows (images only) | [imagegen-frontend-mobile.md](references/imagegen-frontend-mobile.md) |
+| Generating premium brand-kit / identity-system boards (images only) | [brandkit.md](references/brandkit.md) |
+| Generating a semantic DESIGN.md for Google Stitch | [stitch-design-taste.md](references/stitch-design-taste.md) |
+| Reference DESIGN.md output produced by the Stitch skill | [stitch-design-taste-design.md](references/stitch-design-taste-design.md) |
+
+## Cross-cutting rules
+
+Every reference shares these baseline principles; specific rules in a reference override these:
+
+- Never output the same layout or aesthetic twice in a row.
+- Reject the LLM defaults: Inter, Lucide/Feather icons, purple-blue AI gradients, three equal feature cards, centered hero over dark mesh, generic glassmorphism, `h-screen` (use `min-h-[100dvh]`).
+- Animate only `transform` and `opacity`. No layout-triggering properties.
+- No emojis in code, markup, text content, or alt text.
+- No pure black (`#000000`) — use off-black, charcoal, or zinc-950.
+- Prefer distinctive type (Geist, Outfit, Cabinet Grotesk, Satoshi, Fraunces, Instrument Serif) over generic fonts.
+- Verify dependency availability before importing third-party libraries.
+- Generate the `<design_plan>` / design-read step before writing any code where the reference requires it.