diff --git a/.claude/skills/frontend-design/reference/typography.md b/.claude/skills/frontend-design/reference/typography.md
index 8cce06a12..fc201c8a6 100644
--- a/.claude/skills/frontend-design/reference/typography.md
+++ b/.claude/skills/frontend-design/reference/typography.md
@@ -86,9 +86,11 @@ Tools like [Fontaine](https://github.com/unjs/fontaine) calculate these override
 
 ### Fluid Type
 
-Use `clamp(min, preferred, max)` for fluid typography. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens.
+Fluid typography via `clamp(min, preferred, max)` scales text smoothly with the viewport. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens.
 
-**When NOT to use fluid type**: Button text, labels, UI elements (should be consistent), very short text, or when you need precise breakpoint control.
+**Use fluid type for**: Headings and display text on marketing/content pages where text dominates the layout and needs to breathe across viewport sizes.
+
+**Use fixed `rem` scales for**: App UIs, dashboards, and data-dense interfaces. No major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI — fixed scales with optional breakpoint adjustments give the spatial predictability that container-based layouts need. Body text should also be fixed even on marketing pages, since the size difference across viewports is too small to warrant it.
 
 ### OpenType Features
 
diff --git a/.claude/skills/typeset/SKILL.md b/.claude/skills/typeset/SKILL.md
index d768c3f7b..60f41ed35 100644
--- a/.claude/skills/typeset/SKILL.md
+++ b/.claude/skills/typeset/SKILL.md
@@ -33,7 +33,7 @@ Analyze what's weak or generic about the current type:
 3. **Sizing & scale**:
    - Is there a consistent type scale, or are sizes arbitrary?
    - Does body text meet minimum readability? (16px+)
-   - Is fluid sizing used, or do sizes jump at breakpoints?
+   - Is the sizing strategy appropriate for the context? (Fixed `rem` scales for app UIs; fluid `clamp()` for marketing/content page headings)
 
 4. **Readability**:
    - Are line lengths comfortable? (45-75 characters ideal)
@@ -73,7 +73,8 @@ Build a clear type scale:
 - **5 sizes cover most needs**: caption, secondary, body, subheading, heading
 - **Use a consistent ratio** between levels (1.25, 1.333, or 1.5)
 - **Combine dimensions**: Size + weight + color + space for strong hierarchy — don't rely on size alone
-- **Use fluid sizing**: `clamp(min, preferred, max)` for smooth scaling
+- **App UIs**: Use a fixed `rem`-based type scale, optionally adjusted at 1-2 breakpoints. Fluid sizing undermines the spatial predictability that dense, container-based layouts need
+- **Marketing / content pages**: Use fluid sizing via `clamp(min, preferred, max)` for headings and display text. Keep body text fixed
 
 ### Fix Readability
 
diff --git a/source/skills/frontend-design/reference/typography.md b/source/skills/frontend-design/reference/typography.md
index 8cce06a12..fc201c8a6 100644
--- a/source/skills/frontend-design/reference/typography.md
+++ b/source/skills/frontend-design/reference/typography.md
@@ -86,9 +86,11 @@ Tools like [Fontaine](https://github.com/unjs/fontaine) calculate these override
 
 ### Fluid Type
 
-Use `clamp(min, preferred, max)` for fluid typography. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens.
+Fluid typography via `clamp(min, preferred, max)` scales text smoothly with the viewport. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens.
 
-**When NOT to use fluid type**: Button text, labels, UI elements (should be consistent), very short text, or when you need precise breakpoint control.
+**Use fluid type for**: Headings and display text on marketing/content pages where text dominates the layout and needs to breathe across viewport sizes.
+
+**Use fixed `rem` scales for**: App UIs, dashboards, and data-dense interfaces. No major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI — fixed scales with optional breakpoint adjustments give the spatial predictability that container-based layouts need. Body text should also be fixed even on marketing pages, since the size difference across viewports is too small to warrant it.
 
 ### OpenType Features
 
diff --git a/source/skills/typeset/SKILL.md b/source/skills/typeset/SKILL.md
index 2bf23e183..29cf689a9 100644
--- a/source/skills/typeset/SKILL.md
+++ b/source/skills/typeset/SKILL.md
@@ -33,7 +33,7 @@ Analyze what's weak or generic about the current type:
 3. **Sizing & scale**:
    - Is there a consistent type scale, or are sizes arbitrary?
    - Does body text meet minimum readability? (16px+)
-   - Is fluid sizing used, or do sizes jump at breakpoints?
+   - Is the sizing strategy appropriate for the context? (Fixed `rem` scales for app UIs; fluid `clamp()` for marketing/content page headings)
 
 4. **Readability**:
    - Are line lengths comfortable? (45-75 characters ideal)
@@ -73,7 +73,8 @@ Build a clear type scale:
 - **5 sizes cover most needs**: caption, secondary, body, subheading, heading
 - **Use a consistent ratio** between levels (1.25, 1.333, or 1.5)
 - **Combine dimensions**: Size + weight + color + space for strong hierarchy — don't rely on size alone
-- **Use fluid sizing**: `clamp(min, preferred, max)` for smooth scaling
+- **App UIs**: Use a fixed `rem`-based type scale, optionally adjusted at 1-2 breakpoints. Fluid sizing undermines the spatial predictability that dense, container-based layouts need
+- **Marketing / content pages**: Use fluid sizing via `clamp(min, preferred, max)` for headings and display text. Keep body text fixed
 
 ### Fix Readability