@mohammadhprp/system-prompt 0.11.2 → 0.12.1

package/framework/skills/great-interface/references/no-browser.md

@@ -0,0 +1,73 @@
+# Reading a site without a browser
+
+Fetch the HTML, then the stylesheets it links, then grep. That answers most questions a scriptable browser answers and a few it cannot.
+
+Do not use a markdown-converting fetch for this. It strips exactly what you came for. Fetch the raw bytes.
+
+```bash
+curl -sL --max-time 25 "$URL" -o page.html
+wc -c page.html
+grep -oE 'href="[^"]*\.css[^"]*"' page.html | sed 's/href="//;s/"$//' | sort -u
+```
+
+Pull each stylesheet the same way, resolving protocol-relative and root-relative hrefs against the page's origin first.
+
+## Utility CSS is self-describing
+
+Where the site uses utility classes, the markup already contains the declarations and no stylesheet lookup is needed. Grep the class attribute for the effect:
+
+```bash
+grep -oE '(backdrop-)?blur-\[[^]]*\]|(backdrop-)?blur-[a-z0-9]+' page.html | sort | uniq -c | sort -rn
+grep -oE 'class="[^"]*(gradient|blur|mask|mix-blend)[^"]*"' page.html | head -20
+```
+
+This is where the fetch method beats a browser. A class list carries every responsive and state variant at once, so `blur-[50px] md:h-214 md:-translate-x-1/2` says the element changes shape at the `md` breakpoint. Computed styles read at one width cannot.
+
+Semantic CSS gives you a hashed class name instead (`Hero_glow__a1b2c`). Take that name to the stylesheet and grep it there.
+
+## Inline styles carry the values utilities cannot express
+
+A multi-stop gradient is usually too specific for a utility, so it lands in a `style` attribute:
+
+```bash
+grep -oE 'linear-gradient\([^)]*\)' page.html | sort -u | head
+grep -oE 'radial-gradient\([^)]*\)' page.html | sort -u | head
+grep -oE 'style="[^"]*(transform|filter|mask)[^"]*"' page.html | head
+```
+
+## The stylesheet, for tokens and generated utilities
+
+```bash
+grep -oE ':root\{[^}]*\}' style.css | head -1 | tr ';' '\n'      # the token layer
+grep -oE '@layer [a-z]+' style.css | sort -u                      # Tailwind v4 emits theme/base/components/utilities
+grep -oE '@media[^{]*\(m(in|ax)-width:[^)]*\)' style.css | sort -u # real breakpoints
+grep -oE '@font-face\{[^}]*\}' style.css | head                    # families, weights, formats
+grep -oE '@keyframes [a-zA-Z-]+' style.css | sort -u               # named animations
+```
+
+To understand a custom utility, grep its class name in the stylesheet and read the declaration whole. That is how `gradient-ease-in-out` turns into its mechanism, a generated stop list built with `color-mix()` and relative color syntax rather than twelve hand-written stops.
+
+## Stack fingerprints from the HTML alone
+
+```bash
+grep -ocE '__NEXT_DATA__|/_next/static' page.html          # Next.js
+grep -oc 'self.__next_f' page.html                          # App Router with RSC payload
+grep -ocE '__NUXT__|/_nuxt/' page.html                      # Nuxt
+grep -ocE '__remixContext|___gatsby|astro-island' page.html  # Remix, Gatsby, Astro
+grep -oc 'class="[^"]*svelte-' page.html                     # Svelte
+grep -oc 'data-radix-' page.html                             # Radix primitives
+grep -oc 'bg-linear-to' page.html                            # Tailwind v4 (v3 wrote bg-gradient-to)
+grep -oE '<meta name="generator"[^>]*>' page.html
+```
+
+Report these as fingerprints with the evidence that produced them, never as facts. `/_next/static` in an asset path is strong; a utility-looking class name alone is weak.
+
+## What this method cannot tell you
+
+Say so rather than guessing past it:
+
+- **Which rule won.** Nine rules may match one element; only a browser resolves the cascade.
+- **Anything injected at runtime.** CSS-in-JS, a theme applied by script, styles added on interaction.
+- **Paint order and what is actually visible.** A declaration in the CSS may be overridden or never rendered.
+- **Live animation state.** Whether an effect moves at all.
+- **Computed values.** A `rem` stays a `rem`, and you never learn the resolved pixel size.

package/framework/skills/great-interface/references/palette-generation.md

@@ -0,0 +1,104 @@
+# Palette generation
+
+Producing the values once the structure is decided. For which ramps to build and what each step is for, see [palette-structure.md](palette-structure.md).
+
+## Start from the brand color
+
+A brand color arrives as one value, usually a hex. Two decisions come before any ramp exists:
+
+**Which step does it occupy?** A brand color meant for buttons and links belongs on the solid-fill step: `500` in Tailwind, `9` in Radix. Then `bg-brand-500` renders the actual brand color, not an approximation.
+
+**Is it pinned or snapped?** Pin a contractually fixed brand color. It stays exact, the ramp builds outward from it and that one step spaces slightly unevenly. Otherwise snap it onto the ramp so every step spaces evenly. That looks better almost always, and nobody notices without a swatch held to the screen.
+
+A brand color that fails contrast behind white text is still the brand color, just not the solid-fill step. Put it where it lands and use a darker step for interactive fills. Never quietly darken the brand.
+
+## What a correct ramp looks like
+
+Properties of the finished ramp, checkable against any output in any notation:
+
+- **Steps are evenly spaced in perceived lightness.** Not in the number your format calls "lightness". HSL's is not perceptual, and evenly spaced HSL values bunch at one end.
+- **Hue is constant end to end.** Every step is recognisably the same color. A wandering hue reads as two colors blended and will not sit correctly against a neutral built on a different hue.
+- **Vividness peaks in the middle and falls off at both ends.** The lightest and darkest steps are nearly neutral; the middle carries the color. Holding full vividness into the extremes gives a `50` that glows and a `950` like ink spilled on the brand.
+- **Steps are denser at the light end.** Light backgrounds need finer distinctions than dark ones. Keep `50` to `200` close together and `800` to `950` further apart. Even spacing across the whole range makes the pale end unusable, because `50` and `100` stop reading as two surfaces.
+- **No two adjacent steps are indistinguishable.** If `200` and `300` look identical on a calibrated screen, the ramp has more steps than decisions. Drop one.
+- **Both ends stop short of pure black and white.** A ramp that reaches them loses its identity exactly where the page background lives.
+
+## Use a color library
+
+Never compute these by hand or by eye. `culori`, `colorjs.io` and `chroma.js` all convert between notations, measure perceived lightness and interpolate perceptually. Read the brand color in whatever format it arrives, do the math in a perceptual space and emit the project's notation:
+
+```js
+import { formatHex, interpolate, samples } from 'culori'
+
+// Perceptual interpolation, hex in and hex out.
+const ramp = interpolate(['#eff6ff', '#3b82f6', '#172554'], 'lab')
+const steps = samples(11).map((t) => formatHex(ramp(t)))
+```
+
+The output format is the project's choice. For a ramp the interpolation space is not, because the steps have to land evenly in perceived lightness and sRGB interpolation produces muddy mid-steps. Decorative gradients are the opposite case, where the space is a deliberate look ([color-usage.md](color-usage.md)).
+
+```css
+:root {
+  --brand-50: #eff6ff;
+  --brand-100: #dbeafe;
+  --brand-200: #bfdbfe;
+  --brand-300: #93c5fd;
+  --brand-400: #60a5fa;
+  --brand-500: #3b82f6;
+  --brand-600: #2563eb;
+  --brand-700: #1d4ed8;
+  --brand-800: #1e40af;
+  --brand-900: #1e3a8a;
+  --brand-950: #172554;
+}
+```
+
+## Several hues at once
+
+With an accent plus status ramps, the ramps must agree step for step. `danger-500` and `brand-500` should read as equally bright and vivid, or a red button looks heavier than a blue one at the same step.
+
+- **Match perceived lightness exactly.** Same step, same brightness, across every hue.
+- **Match vividness relatively, not absolutely.** Hues do not share a maximum vividness. A saturated yellow and a saturated blue are not equally far from gray, and no format makes them so. Set each ramp to the same *proportion* of what its own hue reaches. Copying a saturation number across hues leaves one washed out.
+
+Yellows and cyans are the usual casualties, peaking much lower than reds and blues. Copy the numbers across and the warning color looks weak beside the danger one.
+
+## Dark mode
+
+A dark palette is not the light one reversed. Reversal is the starting point, not the output.
+
+Swap the semantic roles first, then tune the values:
+
+```css
+:root {
+  --color-bg: var(--brand-50);
+  --color-text: var(--brand-950);
+}
+
+.dark {
+  --color-bg: var(--brand-950);
+  --color-text: var(--brand-50);
+}
+```
+
+Three things almost always need hand-tuning after the swap:
+
+- **Vividness comes down.** A color that reads as confident on white reads as neon on near-black. Dark appearances need the accent a step or two less vivid.
+- **The dark end needs more separation.** Steps distinguishable as pale backgrounds collapse into each other as dark surfaces.
+- **Contrast does not survive the mirror.** A pair passing in light mode can fail reversed, because contrast is not symmetric. Recheck every foreground against its real background in both appearances ([contrast.md](contrast.md)).
+
+### Choosing the switching mechanism
+
+Pick one and use it throughout:
+
+- **`prefers-color-scheme` alone** is correct with no theme toggle. Nothing to persist, nothing to hydrate.
+- **A `.dark` class** is required as soon as users can override the system setting. The media query then sets only the initial value.
+- **`light-dark()`** collapses both values into one declaration, the least code when the project also sets `color-scheme`. It reads that property rather than a class, so a class-based toggle must set `color-scheme` too.
+
+```css
+:root {
+  color-scheme: light dark;
+  --color-bg: light-dark(#ffffff, #172554);
+}
+```
+
+Mixing mechanisms is the common failure. A media query setting some tokens and a class setting others gives a half-themed interface the moment a user overrides their system preference.

package/framework/skills/great-interface/references/palette-structure.md

@@ -0,0 +1,76 @@
+# Palette structure
+
+What a color system is made of, before any values exist. For computing the values see [palette-generation.md](palette-generation.md); for what to call them see [token-naming.md](token-naming.md).
+
+## What a system needs
+
+Most products need three kinds of ramp and nothing else:
+
+| Ramp | How many | Notes |
+| --- | --- | --- |
+| Neutral | 1 | Carries 80–90% of the interface: backgrounds, borders, body text |
+| Accent | 1 | The brand hue. Interactive and selected states |
+| Status | 0–4 | `danger`, `warning`, `success`, `info`. Add one only when the product shows that state |
+
+A second accent hue must also never sit adjacent to the first. Where it would, the accent ramp's own steps provide the range.
+
+## Every step has a job
+
+Each step maps to a role. Generate the steps the roles below call for and skip the rest.
+
+| Role | Tailwind | Radix |
+| --- | --- | --- |
+| Page background | `50` | `1` |
+| Subtle background | `50` | `2` |
+| Component background | `100` | `3` |
+| Component hover | `200` | `4` |
+| Component active / selected | `200` | `5` |
+| Subtle border | `200` | `6` |
+| Border, separator | `300` | `7` |
+| Strong border, focus ring | `400` | `8` |
+| Solid fill | `500` | `9` |
+| Solid fill hover | `600` | `10` |
+| Low-contrast text | `700` | `11` |
+| High-contrast text | `900` | `12` |
+
+The two conventions differ in kind, not only in numbering:
+
+- **Radix defines its 12 steps by role.** Step 9 is "the solid fill" in every ramp and appearance. The dark scale is a separate ramp reusing the same numbers, so `--accent-9` is the fill in both and component CSS never changes.
+- **Tailwind defines its 11 steps by lightness.** `50` is light, `950` is dark. The mapping above therefore holds in light mode and inverts in dark, with the page background at `950` and high-contrast text at `50`. Components either swap step numbers per appearance or read a semantic token that swaps once.
+
+Match whichever the project uses. For a new system prefer Radix's model, because a role-defined step survives a theme change that a lightness-defined step does not. On Tailwind, keep `50`–`950` and put the role mapping in the semantic tier.
+
+Tailwind's 11 steps cover 12 roles, so some do double duty. Where the table repeats a step, the two roles are adjacent in practice and the collision is real. A design needing a subtle border and a component hover to be distinguishable needs a 12-step ramp.
+
+## Neutrals
+
+A pure gray ramp is a perfectly good default. It sits under any accent hue without competing and never needs revisiting when the brand color changes.
+
+Tinting the neutral toward the accent hue is a stylistic option, not a correction. A trace of the accent, a few percent of its vividness, puts the greys in the same family as the accent rather than merely coexisting with it. Enough to measure, not enough to name. Neither choice reads as a mistake.
+
+Warm neutrals, hue toward orange, read approachable and editorial; cool ones, toward blue, read technical and precise. Whichever you pick, including none, hold it across the whole ramp. A warm gray border on a cool gray background is visible even when neither color is nameable alone.
+
+Neutrals carry the most roles, so they need the most steps. Never generate fewer neutral steps than accent steps.
+
+## Status colors
+
+Convention constrains status hues before taste does. Red reads as danger, amber as warning, green as success. See the cultural exceptions in [color-usage.md](color-usage.md).
+
+Two rules govern them:
+
+- **Keep every status hue distinct from the accent.** If the brand is red, the danger ramp cannot also be red. Move danger toward a deeper crimson and check the two side by side, or the destructive and primary actions are the same button.
+- **Status ramps need fewer steps than the accent.** Most render four roles: a background, a border, a solid fill and text. Generate the full ramp only where the product styles status components across the whole range.
+
+Status color is never the only signal of a state change; pair it with an icon or text. `better-accessibility` owns that requirement.
+
+## Auditing an existing palette
+
+Before restructuring a system, inventory it. Most codebases hold several times more colors than the design has decisions.
+
+1. **Collect every literal.** Grep for hex, `rgb(`, `hsl(`, `oklch(` and the project's utility-class prefixes. Include SVG `fill`/`stroke`, chart configs and email templates. Colors hide outside stylesheets.
+2. **Sort by perceived lightness within each hue family.** Duplicates surface immediately as near-identical neighbors.
+3. **Collapse near-duplicates.** Two colors closer than about one ramp step are one color that drifted. Keep the one used most and retire the others. Never average them.
+4. **Assign each survivor a role** from the table above. A color matching no role is a missing token or a mistake. Decide which, and say so in the finding.
+5. **Count what is left.** More than one ramp per role above means the palette outgrew its structure, not that the product needs more color.
+
+Report the inventory before changing anything. Consolidating a palette changes rendered output on screens nobody asked you to touch, so it stays a proposal until the user accepts it.

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

@@ -0,0 +1,88 @@
+# Performance
+
+Transition specificity and GPU compositing hints.
+
+## Transition only what changes
+
+Never use `transition: all` or Tailwind's `transition-all`. Always name the exact properties that change. Tailwind's bare `transition` maps to a curated list of colors, opacity, shadow and transforms rather than `all`, and naming what changes is still better.
+
+### Why
+
+- `transition: all` forces the browser to watch every property for changes
+- Causes unexpected transitions on properties you didn't intend to animate (colors, padding, shadows)
+- Prevents browser optimizations
+
+### CSS example
+
+```css
+/* Good: only transition what changes */
+.button {
+  transition-property: scale, background-color;
+  transition-duration: 150ms;
+  transition-timing-function: ease-out;
+}
+
+/* Bad: transition everything */
+.button {
+  transition: all 150ms ease-out;
+}
+```
+
+### Tailwind
+
+```tsx
+// Good: explicit properties
+<button className="transition-[scale,background-color] duration-150 ease-out">
+
+// Bad: transition all
+<button className="transition-all duration-150 ease-out">
+```
+
+### Tailwind `transition-transform` note
+
+`transition-transform` in Tailwind maps to `transition-property: transform, translate, scale, rotate`, covering every transform-related property rather than only `transform`. Use it when animating transforms alone. For several non-transform properties, use the bracket syntax `transition-[scale,opacity,filter]`.
+
+## Use `will-change` sparingly
+
+`will-change` hints the browser to pre-promote an element to its own GPU compositing layer. Without it the browser promotes only when the animation starts, and that one-time promotion can cause a micro-stutter on the first frame.
+
+It helps most for `scale`, `rotation` and movement through `transform`. For other properties it does little, because the browser cannot composite them on the GPU anyway.
+
+### Rules
+
+```css
+/* Good: specific property that benefits from GPU compositing */
+.animated-card {
+  will-change: transform;
+}
+
+/* Good: multiple compositor-friendly properties */
+.animated-card {
+  will-change: transform, opacity;
+}
+
+/* Bad: never use will-change: all */
+.animated-card {
+  will-change: all;
+}
+
+/* Bad: properties that can't be GPU-composited anyway */
+.animated-card {
+  will-change: background-color, padding;
+}
+```
+
+### Useful properties
+
+| Property | GPU-compositable | Worth using `will-change` |
+| --- | --- | --- |
+| `transform` | Yes | Yes |
+| `opacity` | Yes | Yes |
+| `filter` (blur, brightness) | Yes | Yes |
+| `clip-path` | Newer Chromium only | Rarely; not reliable cross-browser |
+| `top`, `left`, `width`, `height` | No | No |
+| `background`, `border`, `color` | No | No |
+
+### When to skip
+
+Modern browsers optimize well on their own. Add `will-change` only when you see first-frame stutter, which Safari benefits from most. Never add it preemptively to every animated element, since each extra compositing layer costs memory.

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

@@ -0,0 +1,76 @@
+# The picker
+
+The control that switches variants. Its appearance is not a design decision, because it sits on top of the thing being judged. Build the spec below and leave it alone.
+
+## Deliberately outside the design system
+
+Never style the picker with the project's tokens, fonts, or colors. One that looks native to the product becomes part of what you are looking at, and then you are judging the harness.
+
+One dark neutral surface, the system font stack and no project variables. Dark reads as chrome over both light and dark pages, which is why it does not follow the theme.
+
+## Behavior
+
+- It sets a `variant` search param and reads the active variant back from it, so the URL is the source of truth and every variant a link.
+- Left and right arrows step through the set. Number keys jump to one directly.
+- The active item carries `aria-current="true"`, and the container carries a label.
+- Switching is instant. Flipping is the run's highest-frequency action, so `better-ui`'s motion restraint gives it no transition.
+- It survives a resize, so you can hold a variant and drag the window rather than reloading per width.
+
+## Structure
+
+One button per variant, in the order they were named. Add a replay button only where a variant has an entrance worth re-triggering.
+
+```html
+<nav class="variant-picker" aria-label="Variants">
+  <button type="button" data-variant="quiet" aria-current="true">Quiet</button>
+  <button type="button" data-variant="editorial">Editorial</button>
+  <button type="button" data-variant="dense">Dense</button>
+</nav>
+```
+
+## Placement and styling
+
+Fixed, bottom centre, above everything the page can stack. Keep it clear of the piece under judgement. Where the variants live at the bottom of the viewport, move the picker to top centre and say so.
+
+```css
+.variant-picker {
+  position: fixed;
+  bottom: 24px;
+  left: 50%;
+  translate: -50% 0;
+  z-index: 2147483647;
+  display: flex;
+  gap: 2px;
+  padding: 4px;
+  border-radius: 999px;
+  background: rgb(20 20 20 / 0.9);
+  box-shadow: inset 0 0 0 1px rgb(255 255 255 / 0.1), 0 8px 24px rgb(0 0 0 / 0.25);
+  font: 13px/1 -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
+  user-select: none;
+}
+
+.variant-picker button {
+  padding: 7px 14px;
+  border: 0;
+  border-radius: 999px;
+  background: none;
+  color: rgb(255 255 255 / 0.6);
+  cursor: pointer;
+}
+
+.variant-picker button:hover {
+  color: rgb(255 255 255 / 0.85);
+}
+
+.variant-picker button[aria-current="true"] {
+  background: rgb(255 255 255 / 0.14);
+  color: rgb(255 255 255);
+}
+
+.variant-picker button:focus-visible {
+  outline: 2px solid rgb(255 255 255 / 0.7);
+  outline-offset: 2px;
+}
+```
+
+In a framework, keep the class names and the structure and change only the rendering syntax.

package/framework/skills/great-interface/references/read-the-system.md

@@ -0,0 +1,178 @@
+# Reading the whole system
+
+Use this where no specific effect was named and the question is how the interface is built in general. For one named thing, use [find-the-effect.md](find-the-effect.md).
+
+Every snippet runs in the page context, through whatever browser tooling is available: `evaluate_script` in the Chrome DevTools MCP, the console, a Playwright `page.evaluate`. Each returns data rather than printing, so the result comes back whole.
+
+Run them in this order. Tokens first, because a page that hands you its custom properties has already told you most of the answer.
+
+## The gotcha that costs you the run
+
+`sheet.cssRules` throws on a cross-origin stylesheet. Every snippet that walks stylesheets wraps the access and reports what it could not read. An explanation that silently skipped the main stylesheet describes a page nobody is looking at.
+
+## The stack first
+
+"How was this site built" wants the frontend named before a type scale. Run this, then report each hit with its evidence, never as a bare claim:
+
+```js
+const html = document.documentElement;
+const res = performance.getEntriesByType('resource').map(r => r.name);
+const any = re => res.some(n => re.test(n));
+const attr = sel => !!document.querySelector(sel);
+({
+  framework: {
+    next: !!window.__NEXT_DATA__ || any(/\/_next\/static/),
+    nextAppRouter: typeof self.__next_f !== 'undefined',
+    nuxt: !!window.__NUXT__ || any(/\/_nuxt\//),
+    remix: !!window.__remixContext,
+    gatsby: !!window.___gatsby,
+    astro: attr('astro-island, [data-astro-cid]'),
+    svelte: attr('[class*="svelte-"]') || any(/\/_app\/immutable\//),
+    angular: attr('[ng-version]'),
+    reactFiber: Object.keys(document.body.firstElementChild ?? {}).some(k => k.startsWith('__react')),
+  },
+  styling: {
+    tailwind: getComputedStyle(html).getPropertyValue('--tw-ring-offset-width') !== ''
+              || !!document.querySelector('[class*="bg-linear-to"], [class*="bg-gradient-to"]'),
+    tailwindV4: !!document.querySelector('[class*="bg-linear-to"]'),
+    cssModules: attr('[class*="_"][class*="__"]'),
+    styledComponents: attr('[class^="sc-"]') || attr('style[data-styled]'),
+    emotion: attr('[class^="css-"]'),
+  },
+  components: {
+    radix: attr('[data-radix-popper-content-wrapper], [data-radix-scroll-area-viewport]')
+           || !!document.querySelector('[data-slot], [data-state][data-side]'),
+    baseUi: attr('[data-base-ui-portal], [class*="base-ui"]'),
+    headlessUi: attr('[data-headlessui-state]'),
+    mui: attr('[class*="Mui"]'),
+    arkOrChakra: attr('[data-scope][data-part]'),
+  },
+  motion: { animationsRunning: document.getAnimations().length, gsap: !!window.gsap },
+  images: { nextImage: any(/\/_next\/image\?/), modernFormats: [...document.images].some(i => /\.(avif|webp)/.test(i.currentSrc)), srcset: [...document.images].filter(i => i.srcset).length },
+  fonts: { count: document.fonts.size, variable: [...document.fonts].some(f => String(f.weight).includes(' ')), selfHosted: !any(/fonts\.g(oogleapis|static)\.com/) },
+});
+```
+
+Two rules. A fingerprint is not a fact, so give the evidence: `/_next/static` in an asset path is strong, a utility-looking class name alone is weak. And a `false` is not an absence, only a fingerprint that did not fire.
+
+## Tokens
+
+```js
+const tokens = {}; const unreadable = [];
+for (const sheet of document.styleSheets) {
+  let rules; try { rules = sheet.cssRules } catch { unreadable.push(sheet.href); continue }
+  for (const r of rules ?? []) {
+    if (r.selectorText === ':root' || r.selectorText === 'html') {
+      for (const prop of r.style) {
+        if (prop.startsWith('--')) tokens[prop] = r.style.getPropertyValue(prop).trim();
+      }
+    }
+  }
+}
+({ tokens, unreadable, count: Object.keys(tokens).length });
+```
+
+Group the result by prefix. The prefixes are the system's own layer names, and a two-tier structure, `--blue-500` feeding `--color-text-primary`, is the seam `better-colors` calls the semantic tier.
+
+## The type scale
+
+Leaf text nodes only, so a wrapper's inherited size is not counted as its own step.
+
+```js
+const seen = new Map();
+for (const el of document.querySelectorAll('*')) {
+  if (el.children.length || !el.textContent?.trim()) continue;
+  const s = getComputedStyle(el);
+  const key = `${parseFloat(s.fontSize)}px  w${s.fontWeight}  lh ${s.lineHeight}  ls ${s.letterSpacing}`;
+  seen.set(key, (seen.get(key) ?? 0) + 1);
+}
+[...seen].sort((a, b) => b[1] - a[1]);
+```
+
+Sorted by usage, so the body size is first and the one-offs last. Derive the ratio between adjacent sizes. A consistent ratio means a scale; scattered values mean hard-coded sizes.
+
+## The spacing rhythm
+
+```js
+const vals = new Map();
+for (const el of document.querySelectorAll('*')) {
+  const s = getComputedStyle(el);
+  for (const p of ['paddingTop', 'paddingLeft', 'marginTop', 'marginLeft', 'gap', 'rowGap']) {
+    const v = parseFloat(s[p]);
+    if (v > 0) vals.set(v, (vals.get(v) ?? 0) + 1);
+  }
+}
+[...vals].sort((a, b) => a[0] - b[0]);
+```
+
+Look for the base unit that divides most values, then check `better-layout`'s grouping rule. Is the gap between groups at least 2× the gap within one?
+
+## Radii, shadows, borders
+
+```js
+const grab = (prop, skip) => {
+  const m = new Map();
+  for (const el of document.querySelectorAll('*')) {
+    const v = getComputedStyle(el)[prop];
+    if (v && v !== skip) m.set(v, (m.get(v) ?? 0) + 1);
+  }
+  return [...m].sort((a, b) => b[1] - a[1]);
+};
+({ radius: grab('borderRadius', '0px'), shadow: grab('boxShadow', 'none') });
+```
+
+Count the distinct shadows. One or two recipes is a system; nine is a page where everyone invented their own elevation.
+
+## Motion
+
+```js
+const t = new Map();
+for (const el of document.querySelectorAll('*')) {
+  const s = getComputedStyle(el);
+  if (s.transitionDuration === '0s') continue;
+  const key = `${s.transitionProperty}  ${s.transitionDuration}  ${s.transitionTimingFunction}`;
+  t.set(key, (t.get(key) ?? 0) + 1);
+}
+[...t].sort((a, b) => b[1] - a[1]);
+```
+
+`transition: all` shows up here as `all`. Custom curves arrive as `cubic-bezier(...)`, and the built-in keywords tell you nobody tuned them.
+
+## Breakpoints
+
+```js
+const bp = new Set(); const unreadable = [];
+for (const sheet of document.styleSheets) {
+  let rules; try { rules = sheet.cssRules } catch { unreadable.push(sheet.href); continue }
+  const walk = list => { for (const r of list ?? []) {
+    if (r.media) { for (const m of r.media) { const hit = m.match(/(min|max)-width:\s*([\d.]+)(px|r?em)/); if (hit) bp.add(hit[0]) } }
+    if (r.cssRules) walk(r.cssRules);
+  }};
+  walk(rules);
+}
+({ breakpoints: [...bp].sort(), unreadable });
+```
+
+Compare against the framework defaults. Breakpoints at exactly `640/768/1024/1280` are Tailwind's out of the box, which tells you they were never chosen.
+
+## Fonts and theming
+
+```js
+({
+  loaded: [...document.fonts].map(f => `${f.family} ${f.weight} ${f.style} ${f.status}`),
+  bodyStack: getComputedStyle(document.body).fontFamily,
+  variable: [...document.fonts].some(f => String(f.weight).includes(' ')),
+  themeClass: document.documentElement.className || '(none)',
+  colorScheme: getComputedStyle(document.documentElement).colorScheme,
+});
+```
+
+`variable: true` means one file covers a weight range. A class on `<html>` beside a `prefers-color-scheme` query means a toggle that can override the system, the mechanism `better-colors` describes.
+
+## Reading a second state
+
+Everything above reads one state at one width. Before writing the explanation, at minimum:
+
+- Resize to 375px and re-run the spacing and breakpoint snippets. The values that change are what is fluid.
+- Toggle the theme and re-run the token snippet. The tokens that change are the themed layer, the ones that do not are the primitives.
+- Tab to the first interactive control and read its `:focus-visible` styles, since a focus ring is one of the most common absences.

package/framework/skills/great-interface/references/removed-signals.md

@@ -0,0 +1,38 @@
+# Removed signals
+
+What to look for on the `-` side of a hunk and which skill owns the judgement. A row here is a lead, never a finding. Route the removal to its owner and report it only once that skill confirms the interface got worse.
+
+| Removed from the `-` side | Owner | What to check |
+| --- | --- | --- |
+| `aria-label`, `aria-labelledby`, `aria-describedby`, `aria-live`, `role=` | `better-accessibility` | The control or region lost its accessible name, description, or announcement |
+| `alt=`, `<label`, `for=`, `scope=` | `better-accessibility` | Image, field, or table cell lost its programmatic association |
+| `<button>`, `<a>`, `<nav>`, `<main>`, `<ul>` replaced by `div` or `span` | `better-accessibility` | Keyboard and assistive-technology behavior was traded for styling |
+| `:focus-visible`, `:focus`, `outline`, `tabindex` | `better-accessibility` | Keyboard users lost the focus indicator or the element left the tab order |
+| `prefers-reduced-motion`, `prefers-contrast` | `better-accessibility` | Motion or contrast now ignores the user's system preference |
+| Logical properties swapped for `left` / `right` | `better-layout` | Direction-aware layout was dropped |
+| `lang=`, `dir=` | `better-typography` | Language metadata or text direction was dropped |
+| `text-wrap`, `line-clamp`, `overflow-wrap`, `tabular-nums`, `font-feature-settings` | `better-typography` | Text rendering, wrapping, or numeral alignment silently changed |
+| A color token swapped for a literal, or a token swapped for a lighter one | `better-colors` | The rendered contrast pair may now fail; measure it |
+| A user-facing string deleted or shortened | `better-writing` | A label, error, or empty state lost the information it carried |
+
+## Equivalent replacements
+
+These clear the signal. Check for them before routing anything, or the report fills with refactors reported as regressions:
+
+- `aria-label` giving way to `aria-labelledby` pointing at visible text.
+- An explicit `role` dropped because the element became the native equivalent, `role="button"` going as a `div` becomes a `<button>`.
+- `outline` replaced by a `box-shadow` focus ring that still meets the focus-indicator rule.
+- `tabindex="0"` dropped from an element that is now natively focusable.
+- A color literal replaced by a token that measures the same rendered pair.
+- A physical property replaced by its logical counterpart, which is the fix rather than the regression.
+- A string moved into the translation catalogue rather than deleted.
+
+## Searching the removed side
+
+Restrict the search to deleted lines so additions do not mask a removal:
+
+```bash
+git diff -U0 "$BASE"...HEAD -- '*.tsx' '*.css' | grep -E '^-[^-]' | grep -E 'aria-|role=|alt=|focus|tabindex|prefers-'
+```
+
+Read the surrounding hunk before deciding. A removed attribute is meaningless without the element it came from, and `-U0` deliberately hides that context.