@maccesar/aiskills 1.7.0

package/skills/refactoring-ui/references/02-visual-hierarchy.md

@@ -0,0 +1,84 @@
+# Ch2 — Hierarchy is Everything
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## Visual Hierarchy is the #1 Design Tool
+
+- Every element on a page is either competing for attention or supporting something else
+- Good design is not about making everything stand out — it's about making the right things stand out
+- If everything is emphasized, nothing is
+
+## Use Weight and Color, Not Just Size
+
+Three tools for hierarchy (in order of subtlety):
+1. **Font size** — most obvious, use sparingly for big differences
+2. **Font weight** — bold text reads as important; good for same-size emphasis
+3. **Color** — use dark/grey/lighter-grey to create a 3-tier system:
+   - Primary: near-black for main content
+   - Secondary: mid-grey for supporting text
+   - Tertiary: lighter grey for placeholder/disabled/least important
+
+**Never use font weights below 400** for UI text — thin/light weights look bad at small sizes on screens.
+
+## Grey Text on Colored Backgrounds
+
+- Don't reduce text opacity to create grey on a colored background — this desaturates and looks muddy
+- Instead: hand-pick a color with the same hue as the background, but adjusted lightness/saturation
+- Pick a color that feels like a "grey" version within that color family, not an actual grey
+
+## Emphasize by De-Emphasizing Competitors
+
+- When you want one element to stand out, try making everything around it less prominent instead of making it bigger/bolder
+- Reduce contrast on secondary elements rather than adding more styling to primary ones
+- This is often more effective than adding emphasis — it preserves the visual balance
+
+## Labels: When to Skip, Combine, or Subordinate
+
+**Skip the label when:**
+- Format makes it obvious (e.g., an email address, a phone number, a date)
+- Context makes it obvious (e.g., a profile page bio doesn't need "Bio:" label)
+
+**Combine label and value:**
+- "12 left in stock" instead of "In stock: 12"
+- "Bedrooms: 3" → "3 bedrooms"
+
+**Treat label as secondary:**
+- When you do need a label, make it smaller/lighter than the value
+- The value is what matters; the label is supporting metadata
+
+## HTML Heading Elements ≠ Visual Size
+
+- `<h1>`–`<h6>` are semantic, not visual
+- An `<h1>` might visually be smaller than surrounding text if the context calls for it
+- An `<h3>` sidebar title might be the same size as body text, just bolder
+- Style headings based on visual hierarchy, not element level
+
+## Icons Are Heavy — Reduce Their Contrast
+
+- Icons carry more visual weight than text at the same size
+- To balance icons with surrounding text, use a softer/lighter color for the icon
+- Don't use the same high-contrast color you use for body text — icons will dominate
+- Reduce icon contrast; increase text contrast if needed
+
+## Increase Border Width for Low-Contrast Elements
+
+- When a border is barely visible (low contrast), making it thicker compensates
+- A thicker, slightly lighter border can read better than a thin, barely-there one
+- This is especially relevant for dividers, table borders, and card edges
+
+## Button Hierarchy
+
+Four tiers of buttons:
+
+| Tier | Style | Use |
+|------|-------|-----|
+| Primary | Solid + high-contrast fill | The main action on the page |
+| Secondary | Outline or low-contrast fill | Supporting actions |
+| Tertiary | Link-style (no background/border) | Least important actions |
+| Destructive | Secondary style + confirmation step | Delete, remove, revoke |
+
+- A page should rarely have more than one primary button
+- Destructive actions should NOT use red as primary — make them secondary, then confirm
+- Hierarchy between buttons prevents visual noise and guides users to the right action

package/skills/refactoring-ui/references/03-layout-spacing.md

@@ -0,0 +1,69 @@
+# Ch3 — Layout and Spacing
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## Start with Too Much White Space
+
+- Default to more white space, then remove it — don't add white space after the fact
+- Most UIs suffer from too little spacing, not too much
+- Dense UIs feel busy and hard to scan; generous spacing feels calm and organized
+
+## Spacing Scale
+
+- Use a defined, non-linear spacing scale — not arbitrary pixel values
+- Base value: **16px** is a natural anchor point
+- Adjacent values on the scale should differ by at least 25%
+- Example scale (non-linear): 4, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192, 256, 384, 512, 640, 768
+- The non-linearity matters: you want clearly distinct values, not ones that look nearly the same
+
+## Use Only the Space You Need
+
+- Don't stretch elements to fill the full container by default
+- Short forms don't need full-width inputs
+- If an element's natural width is 200px, let it be 200px — don't stretch to 600px
+- Full-width is a choice, not a default
+
+## Shrink Your Canvas for Small Interfaces
+
+- When designing small components (modals, cards, widgets), shrink the canvas
+- Working at ~400px forces you to think about the actual scale
+- Zooming out on a 1440px canvas to see a card is deceptive — elements feel more generous than they are
+- Mobile-first approach: design at 320-400px first, then expand
+
+## Split into Columns Instead of Stretching
+
+- When content is too wide or elements feel stretched, introduce columns
+- A two-column layout for a settings page beats stretching form fields across the full width
+- Use columns to create denser, more structured layouts without sacrificing usability
+
+## Fixed Widths for Sidebars
+
+- Sidebars should use fixed pixel widths, not percentages
+- A sidebar at `240px` stays consistent; at `20%` it becomes tiny or huge at different breakpoints
+- Use `max-width` constraints for content columns rather than percentage-based grid columns
+- Percentage widths work for responsive images and grid cells — not for UI chrome
+
+## Responsive Scaling: Large Elements Shrink Faster
+
+- Large headline that is 45px on desktop → should be 20-24px on mobile
+- The ratio of reduction is not 1:1 — large elements shrink proportionally more
+- Button padding does not scale proportionally with font size:
+  - A button with 16px font and 12px vertical padding looks right
+  - Increasing font to 24px doesn't mean padding should become 18px
+  - Often keep padding roughly the same while increasing font
+
+## Spacing Within Groups vs. Between Groups
+
+- More space should appear **around** a group than **within** it (Law of Proximity)
+- Elements close together are perceived as related
+- A form section header should have more space above it (separating from previous section) than below it (connecting to its fields)
+- Labels should be closer to their own input than to the input above or below
+
+## Law of Proximity Checklist
+
+- [ ] Does the spacing clearly show which elements belong together?
+- [ ] Is there more space between groups than within groups?
+- [ ] Is the label closer to its own input than to adjacent inputs?
+- [ ] Does the layout communicate grouping without relying on borders or backgrounds?

package/skills/refactoring-ui/references/04-typography.md

@@ -0,0 +1,70 @@
+# Ch4 — Designing Text
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## Hand-Crafted Type Scale (Avoid Modular Scales)
+
+- Modular scales (e.g., 1.25× ratio) produce fractional pixel values and limited useful sizes
+- Better approach: hand-pick 8-10 sizes that actually work for your use cases
+- Example scale: 12, 14, 16, 18, 20, 24, 30, 36, 48, 60, 72px
+- Each value should feel clearly different from adjacent ones — not nearly identical
+
+## Use px or rem — Never em
+
+- `em` units are relative to the parent element's font size
+- Nesting elements with `em` compounds the sizing unpredictably
+- Use `px` or `rem` (relative to root font size only) for type scale
+- `em` is appropriate for things like `margin`/`padding` that should scale with font size, but NOT for defining the type scale itself
+
+## Choosing Fonts from Google Fonts
+
+- Filter by: "10+ styles" — this alone cuts ~85% of sans-serif fonts, leaving fewer than 50
+- Quality signal: fonts with many weights/styles are taken seriously by their designers
+- For UI: choose a neutral sans-serif (Helvetica-style, not geometric or humanist extremes)
+- System font stack (`-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto`) is a safe fallback
+- Avoid condensed fonts (narrow letterforms) or fonts with very short x-heights for body text — hard to read at small sizes
+
+## Optimal Line Length
+
+- Target: **45–75 characters** per line for comfortable reading
+- Equivalent width: approximately **20–35em**
+- Limit paragraph width even when placed inside a wider content area
+- Too wide: eyes get lost tracking back to the next line
+- Too narrow: too many line breaks, disrupts reading flow
+
+## Baseline Alignment for Mixed Font Sizes
+
+- When two elements with different font sizes sit side by side, align them by **baseline** (bottom of text), not by vertical center
+- Vertical center alignment of mixed sizes looks off — the smaller text appears too high
+
+## Line-Height Rules
+
+- **Body text (narrow columns):** ~1.5 line-height
+- **Wide columns:** up to 2.0 line-height
+- **Large headlines:** ~1.0 or slightly below (they need almost no leading)
+- Rule: line-height is **inversely proportional** to font size
+  - Small text → more line-height (harder to track between lines)
+  - Large text → less line-height (already easy to track; extra space feels empty)
+
+## Styling Links
+
+- In **link-heavy UIs** (e.g., sidebars, navigation): use heavier weight or darker color instead of blue color
+- Color alone creates too much noise when everything is a link
+- **Ancillary links** (e.g., "privacy policy" in footers): only show underline/color on hover
+- Reserve high-contrast blue links for inline text where they need to stand out from surrounding prose
+
+## Text Alignment
+
+- **Left-align** for most text — the natural reading direction for LTR languages
+- **Center-align** only for short text blocks (max 2–3 lines); never center long paragraphs
+- **Right-align** numbers in tables (so decimal points and digits align vertically)
+- **Justified text:** hyphenate it — without hyphenation, justified text creates awkward gaps
+
+## Letter-Spacing Adjustments
+
+- **Headlines using wide-spaced body fonts:** tighten letter-spacing slightly (negative tracking)
+  - Body fonts are optimized for reading at small sizes; at large sizes they can feel too loose
+- **All-caps text:** always increase letter-spacing — all-caps is harder to read, extra spacing compensates
+- Never apply tight letter-spacing to body text or all-caps — it reduces legibility

package/skills/refactoring-ui/references/05-color.md

@@ -0,0 +1,96 @@
+# Ch5 — Working with Color
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## HSL Color Model
+
+HSL (Hue, Saturation, Lightness) is the right model for UI color work:
+
+- **Hue:** 0°=red, 60°=yellow, 120°=green, 180°=cyan, 240°=blue, 300°=magenta
+- **Saturation:** 0%=grey (no color), 100%=fully vivid
+- **Lightness:** 0%=black, 50%=pure color, 100%=white
+
+**HSL ≠ HSB (HSV):** Different definitions of "lightness." HSB's "brightness" at 100% still gives a vivid color; HSL's lightness at 100% is always white. They are NOT interchangeable.
+
+## What Colors You Need
+
+A complete UI color system requires:
+- **Greys:** 8–10 shades (used for text, backgrounds, borders, UI chrome)
+- **Primary color:** 5–10 shades (brand color, main actions)
+- **Accent colors:** typically 3–5 colors × 5–10 shades each
+  - Red (danger, error, destructive)
+  - Yellow (warning, caution)
+  - Green (success, positive)
+  - Others as needed (blue for info, purple, etc.)
+
+This can mean 10 colors × 10 shades = 100 values. Define them all up front.
+
+## Do NOT Use Preprocessor lighten()/darken()
+
+- `lighten(blue, 20%)` just adds white or removes saturation — produces washed-out results
+- `darken(blue, 20%)` adds black — produces muddy, lifeless results
+- Define shades up front by hand using HSL — you'll get better results every time
+
+## How to Build a 9-Shade Scale (100–900)
+
+Step-by-step:
+1. **Pick your base color** (e.g., 500): should work as a button background
+2. **Pick the darkest shade** (e.g., 900): should work as dark text
+3. **Pick the lightest shade** (e.g., 100): should work as a tinted background
+4. **Fill in 700** next (halfway between 500 and 900)
+5. **Fill in 300** next (halfway between 100 and 500)
+6. **Fill remaining gaps** (200, 400, 600, 800) by eye
+
+## Saturation Must Increase as Lightness Moves from 50%
+
+- Pure HSL: as you move lightness toward 0% or 100%, the color appears less vivid
+- To compensate, **increase saturation** as lightness increases or decreases from 50%
+- Very light shades (lightness 90–95%): bump saturation up significantly
+- Very dark shades (lightness 15–25%): bump saturation up to maintain richness
+- If you don't, light shades look washed-out and dark shades look muddy
+
+## Rotate Hue for Perceptually Better Shades
+
+- Rotating hue slightly while lightening/darkening produces more natural results
+- To make a **lighter** shade: rotate hue toward the nearest "bright" color (60°, 180°, 300°)
+- To make a **darker** shade: rotate hue toward the nearest "dark" color (0°, 120°, 240°)
+- Maximum rotation: **20–30°** — more than that and the color looks completely different
+- This mimics how real pigments behave when tinted or shaded
+
+## Cool vs. Warm Greys
+
+- True neutral grey has 0% saturation — often feels clinical and bland
+- **Cool greys:** add a small amount of blue saturation (feels modern, professional)
+- **Warm greys:** add a small amount of yellow or orange saturation (feels inviting, human)
+- Match grey temperature to your overall palette's temperature
+
+## Accessible Contrast (WCAG)
+
+- **Small text (<~18px normal weight, <~14px bold):** minimum 4.5:1 contrast ratio
+- **Large text (≥~18px normal or ≥~14px bold):** minimum 3:1 contrast ratio
+- Check: dark text on white bg is easier to pass than white on dark colored bg
+
+## Accessibility Alternatives to White-on-Dark
+
+- Instead of white text on a dark colored background, try **dark text on a light tinted background**
+- Example: dark navy text on pale blue background — same brand color, much higher contrast
+- This "flip" is often more accessible and looks more sophisticated
+
+## Colored Text on Colored Background (Accessible)
+
+- White text on a vivid colored button fails contrast if the color is too bright
+- Instead of darkening the background, try **rotating the hue toward a bright anchor**
+- A gold/yellow text on a dark orange button is more legible than white because yellow is inherently brighter
+- Experiment: rotate hue toward 60° (yellow) for lighter-feeling text that still passes contrast
+
+## Never Use Color as the Only Signal
+
+- Color-blind users (8% of males) cannot distinguish red/green by color alone
+- Always pair color with a second signal:
+  - Icon (checkmark, warning triangle, X)
+  - Shape difference
+  - Text label
+  - Position or contrast difference
+- This applies to: status badges, error states, success messages, alert levels, charts

package/skills/refactoring-ui/references/06-depth-shadows.md

@@ -0,0 +1,74 @@
+# Ch6 — Creating Depth
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## Light Source Convention
+
+- Light source is always **above** the interface
+- Users look at screens from a slightly downward angle
+- This is the physical convention all simulated depth should honor
+
+## Raised Elements
+
+To make an element appear raised off the page:
+- **Lighter top edge:** use a top border or top-side inset box-shadow in a lighter color
+- **Small dark box-shadow below:** simulates the shadow cast downward by the raised element
+- Pick the lighter edge color by hand — do NOT use semi-transparent white (`rgba(255,255,255,0.x)`) because it desaturates the underlying color and looks fake
+
+## Inset Elements
+
+To make an element appear pressed into the page:
+- **Lighter bottom edge:** use a bottom border or bottom-side inset box-shadow in a lighter color
+- **Small dark inset shadow at top:** simulates the shadow falling into the well
+- Same rule: hand-pick the lighter color instead of using semi-transparent white
+
+## 5-Level Shadow Elevation System
+
+Define 5 shadow levels (like Material Design's elevation system):
+- **Level 1 (almost flat):** very small blur, tiny offset — element is barely raised
+- **Level 2:** slightly larger blur and offset
+- **Level 3:** medium blur, medium offset — default "card" shadow
+- **Level 4:** large blur, larger offset — modals, dropdowns
+- **Level 5 (closest to user):** very large blur, biggest offset — tooltips, popovers in foreground
+
+Rule: small blur = slightly raised; large blur = close to the user/floating.
+
+## Shadow Response to Interaction
+
+- **On drag (element is "picked up"):** shadow grows — blur and offset increase as if the element moved closer to the user
+- **On click/press (element is pressed in):** shadow shrinks and may disappear — simulates the element being pushed into the surface
+- This gives tactile feedback without animation
+
+## Two-Part Shadow for Realism
+
+Real objects cast two kinds of shadow:
+1. **Direct light shadow** (umbra): large, soft, with big offset and big blur — from the primary light source
+2. **Ambient light shadow** (penumbra): tight, dark, with small offset and small blur — from scattered ambient light
+
+For UI shadows:
+- Shadow 1: large blur, large offset, low opacity (direct light)
+- Shadow 2: small blur, small offset, higher opacity (ambient)
+
+At higher elevations (closer to user), the ambient shadow (Shadow 2) becomes more subtle relative to Shadow 1.
+
+## Flat Design Depth Alternatives
+
+When shadows are not appropriate (flat aesthetic):
+- **Lighter = closer, darker = further** — opposite of intuition with real light, but works visually
+- Use solid, no-blur shadows: `box-shadow: 4px 4px 0 #000` for a retro/flat look
+- These shadows define edges without implying light source
+
+## Overlap Elements for Layering
+
+- Overlapping one element across a background boundary creates a strong sense of layers
+- Example: a card that straddles a dark hero and a white content area feels layered
+- Example: an avatar that overlaps the edge of a card creates depth without shadows
+
+## Overlapping Images: Invisible Border
+
+- When images overlap each other or a background, edges can clash
+- Add a border that matches the **background color** — an "invisible" border
+- This creates separation between elements without a visible border color
+- Also called a "halo" — a same-color buffer that prevents visual clashing

package/skills/refactoring-ui/references/07-images.md

@@ -0,0 +1,75 @@
+# Ch7 — Working with Images
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## Use Real Images From Day One
+
+- Never design with placeholder images (grey boxes, lorem ipsum images)
+- Placeholder images lie about how real content will look — especially for products, people, and covers
+- Hire a photographer or use quality stock photo services (e.g., Unsplash)
+- The visual design must work with actual images, not idealized placeholders
+
+## Text Over Images
+
+Option 1: **Semi-transparent overlay**
+- Add a dark overlay (black) for light-colored text on top of a photo
+- Add a light overlay (white) for dark-colored text on top of a photo
+- Overlay controls how much of the image shows through
+
+Option 2: **Lower image contrast + adjust brightness**
+- Reduce contrast on the image itself so text has a more uniform background
+- Brighten or darken the whole image to create a consistently light/dark canvas for text
+
+Option 3: **Colorize the image**
+- Desaturate the image (remove color)
+- Apply a solid fill layer using "multiply" blend mode in your design tool
+- Result: a single-color tone that text can sit on top of
+
+Option 4: **Text shadow**
+- Use a large blur, no offset text-shadow behind the text
+- Creates a soft halo that separates text from the image background
+- Best for small amounts of text (headlines, labels)
+
+## Icons at Scale
+
+- Icons designed at 16–24px look chunky and blurry when scaled to 3–4×
+- At large sizes, use a **shaped container** with a background color instead of a raw oversized icon
+- Put the icon inside a circle, rounded square, or other shape
+- Scale the container to the needed size; keep the icon at its native size (or slightly larger)
+- This prevents the "blown up icon" problem while adding visual polish
+
+## Screenshots
+
+Three problems with using screenshots at full scale:
+- At 70% scale, 16px font becomes ~11px — unreadable
+- At 50% scale, 16px font becomes 8px — completely illegible
+
+Solutions:
+1. **Use a tablet/narrow layout screenshot** instead of a full desktop one — content scales better
+2. **Take a partial screenshot** — crop to just the relevant portion
+3. **Draw a simplified version** — remove most UI, keep only what illustrates the point
+4. Never rely on the viewer being able to read or understand text in a thumbnail screenshot
+
+## Favicons
+
+- A 128px logo shrunk to 16px is unrecognizable — too much detail is lost
+- **Redraw the favicon at target size** from scratch (16×16, 32×32)
+- Keep it to 1–2 elements; use just the icon mark, not the full wordmark
+- Test it at 1× actual size while designing — what looks good at 128px often looks like noise at 16px
+
+## User-Uploaded Images
+
+Two problems: aspect ratio and background bleed.
+
+**Aspect ratio:** User uploads won't match your layout's expected proportions.
+- Use fixed containers (set width and height)
+- Apply `background-size: cover` (or the equivalent `object-fit: cover`)
+- Let the browser/engine center and crop to fill the container
+
+**Background bleed:** Images with white or light backgrounds bleed into light-colored page backgrounds.
+- Don't use a visible border — it creates a box outline that looks heavy
+- Instead, add a subtle **inner box-shadow** (inset): `box-shadow: inset 0 0 0 1px rgba(0,0,0,0.1)`
+- This creates a soft inner ring that defines the edge without a harsh border
+- Works across all image background colors since it sits on top of the image

package/skills/refactoring-ui/references/08-finishing-touches.md

@@ -0,0 +1,91 @@
+# Ch8+9 — Finishing Touches & Leveling Up
+
+Source: "Refactoring UI" by Adam Wathan & Steve Schoger
+
+---
+
+## Replace Bullets with Icons
+
+- Default bullet points feel generic and low-effort
+- Replace with icons that match the content:
+  - Checkmarks for feature lists or completed items
+  - Arrows for directional or sequential lists
+  - Content-specific icons (e.g., lock icon for "secure", globe for "worldwide")
+- Icons add visual interest and reinforce meaning simultaneously
+
+## Promote Quotation Marks as Visual Elements
+
+- Large, decorative quotation marks can become a design element in testimonials and pull quotes
+- Make them large, colorful (use an accent color), and position them prominently
+- The quote mark becomes part of the visual design, not just punctuation
+
+## Style Links Intentionally
+
+Two approaches depending on context:
+1. **Color + weight:** The standard blue link, but use brand color + slightly heavier font weight
+2. **Thick colorful underline:** A thick border-bottom (2–4px) in an accent color that partially overlaps the bottom of the text
+   - Creates visual interest while remaining clearly a link
+   - Can use a different color from the text for contrast
+
+## Custom Checkboxes and Radio Buttons
+
+- Browser default inputs look generic and don't match brand identity
+- Replace with custom-styled equivalents using brand color for the checked state
+- Common pattern: custom checkbox with a checkmark SVG on a colored background
+- Worth the extra markup for polished forms
+
+## Accent Borders
+
+Use a short, thick accent-color border as a decorative element:
+- **Top of card:** a colored bar at the top edge of a card or panel
+- **Left side of active nav item:** indicates current page/section
+- **Left side of alert message:** differentiates alert types (red=danger, yellow=warning, green=success)
+- **Under a headline:** a short thick underline using brand color
+- **Top of the entire page layout:** thin color strip across the very top
+
+These are simple, high-impact touches that add brand identity without complexity.
+
+## Background Decoration
+
+Options for making backgrounds interesting:
+1. **Solid color change:** Switch from white to a brand color or neutral tint
+2. **Gradient:** Use two hues that are no more than 30° apart on the color wheel — closer = more natural, farther = jarring
+3. **Low-contrast repeating pattern:** Subtle geometric pattern (dots, lines, hatching) at low opacity
+4. **Geometric shapes:** Abstract colored shapes or blobs in the background at low opacity
+
+Key rule for gradients: keep hues within 30° of each other for a natural look.
+
+## Empty States Are a Priority, Not an Afterthought
+
+- Most UIs look broken or confusing when completely empty
+- Design the empty state before adding content — it's often the first thing new users see
+
+Good empty state components:
+- Illustration or icon that's contextually relevant
+- Brief, friendly explanation of what belongs here
+- Clear call-to-action (e.g., "Add your first project" button)
+
+Additional rule: **hide irrelevant UI until it has content**
+- Tabs with no content, filters with no items, pagination with one page — all look broken empty
+- Don't render those elements until there's content that makes them useful
+
+## Alternatives to Borders
+
+Borders are often overused. Replace them with:
+1. **Box shadow:** `box-shadow: 0 1px 3px rgba(0,0,0,0.1)` — creates separation without a hard line
+2. **Two different background colors:** alternating section backgrounds communicate separation without borders
+3. **Extra spacing:** more white space between sections often eliminates the need for a border entirely
+
+## Think Outside the Box
+
+Don't default to generic UI patterns when something more engaging is possible:
+
+- **Enriched dropdowns:** add icons, sections, descriptions, or two-column layouts inside dropdowns
+- **Table column hierarchy:** instead of flat equal-weight columns, apply visual hierarchy within cells (primary value large/dark, secondary value small/grey)
+- **Selectable cards instead of radio buttons:** replace radio button groups with styled card options that highlight on selection — more visual, easier to scan
+
+## Leveling Up Your Eye
+
+Two practices from the book:
+1. **Study unintuitive decisions in good designs:** Look at polished UIs and ask "why did they do that?" Notice the specific, non-obvious choices — the things you wouldn't have thought of
+2. **Rebuild interfaces without DevTools:** Pick a UI from a product you admire and recreate it from scratch, without inspecting the original. Forces you to make real design decisions rather than copying values