Type

Type — typography router

Routes typographic work to the smallest sufficient set of focused skills. Do not answer typography questions from memory when a skill below covers them: the skills carry the decision procedures, the ranges, and the source conflicts that "looks right" misses.

Core principle

Books teach judgment. Current standards teach implementation.

Never emit a bare universal constant. Encode the decision and its inputs.

> ❌ "Body text should always be 16px." > ✅ Determine body-text size from the typeface's apparent size, x-height, target > device, reading distance, content density, user needs, and available line length. > Treat 16px as a common browser-oriented starting point, not a universal optimum. > Validate readability, zoom behavior, line length, and hierarchy in the rendered > context.

1. When to invoke

• The user types /type (or $type).
• Any task that sets, chooses, scales, spaces, loads, tokenizes, audits, or

critiques type.

• A screen "looks off", "feels cheap", or "looks AI-generated" and the cause may be

typographic.

• You are about to answer a typography question from memory.

Do not invoke for non-typographic layout — that belongs to the general design skills. Two topics are split rather than excluded: type that moves is motion-typography (general interface motion is not this pack's), and type that carries colour or is made of glyphs is color-and-icon-fonts (general colour systems and iconography are not). If the request is really about information architecture or copy content rather than its setting, say so and route elsewhere.

2. Required context

Before routing, establish:

• What is actually changing — a value, a system, a file, or a judgment.
• Medium and platform — web, native, print, or cross-platform.
• Whether an artifact exists to inspect, or this is greenfield.
• Whether accessibility or i18n is in scope (they usually are, whether stated or

not).

If the request is one line and ambiguous, route on the most likely reading and state the assumption — don't stall.

3. Invariant principles

• Load 2–4 skills maximum per pass. More is context waste and dilutes attention.
• Route by what changes, not by vocabulary used. Someone saying "kerning" often

means tracking, and someone saying "font" usually means typeface.

• Always resolve conflicts with the hierarchy below, and say which rule won.
• Never claim typography is accessible after a contrast check alone — 1.4.3,

1.4.4, and 1.4.12 fail independently.

• State what was not verified in a rendered context.

4. Context-dependent heuristics — conflict resolution and routing

Conflict hierarchy — read before deciding anything

Full list in references/source-hierarchy.md. Highest first:

1. Accessibility standards and browser behavior
2. User and product context
3. Thinking with Type → 4. Web Typography → 5. Flexible Typesetting →
4. Detail in Typography → 7. Typographic Systems
5. The supporting books
6. Style trends and subjective convention

This exists so the agent never applies a print-era rule to a responsive application, and never lets a trend override an accessibility floor.

Routing table

| Signal in the request | Load | |---|---| | "what is leading / em / baseline", vocabulary, first principles | type-foundations | | naming letterform parts, reading a specimen, apertures/terminals/counters | typeface-anatomy | | "which font should I use", evaluating or replacing a typeface | typeface-selection | | combining two or more typefaces | typeface-pairing | | type scale, heading levels, size ramp, "hierarchy is unclear" | hierarchy-and-scale | | body copy, long-form reading, measure, line-height, paragraphs | body-text-and-reading | | fluid type, clamp(), breakpoints, "text breaks on mobile" | responsive-typography | | buttons, labels, inputs, tables, nav, dense product UI | ui-component-typography | | articles, marketing pages, art-directed layouts, drop caps, pull quotes | editorial-web-typography | | composition, grid, spatial arrangement, "layout feels arbitrary" | typography-layout-systems | | kerning, tracking, word spacing, hyphenation, punctuation, orphans/widows | microtypography | | variable fonts, weight/width/optical-size axes, font-variation-settings | variable-fonts | | animated or kinetic type, text transitions, scroll effects, streaming text | motion-typography | | colour fonts, layer fonts, font-palette, icon fonts vs SVG, emoji | color-and-icon-fonts | | webfont performance, FOUT/FOIT, CLS, subsetting, font-display | font-loading-and-performance | | contrast, zoom, Dynamic Type, dyslexia, screen readers, WCAG | typography-accessibility | | Arabic, Hebrew, CJK, Indic, bidi, vertical text, localization | international-typography | | exporting type as design tokens, Style Dictionary, theme config | design-token-generation | | "check this", systematic review against criteria, pass/fail | typography-audit | | "is this good", taste, expressive judgment, art direction | typography-critique |

Reference tables (load directly, no skill needed)

| Question | File | |---|---| | "which OpenType tag / CSS property does X?" | references/opentype-features.md | | "is there a principle covering X?" | references/universal-principles-index.md (all 100, routed) | | "the books disagree — which wins?" | references/source-hierarchy.md | | "what do the books actually disagree about?" | references/corpus-conflicts.md |

Always co-load

• Anything rendering body text → also typography-accessibility.
• Anything shipping webfonts → also font-loading-and-performance.
• Anything for a non-English or multi-script product → also

international-typography.

Shortcuts

• "Make this look better", no specifics → typography-critique +

hierarchy-and-scale + microtypography.

• "Build a type system" → hierarchy-and-scale + responsive-typography +

design-token-generation.

• "Why does this feel cheap / generic / AI-generated" → typography-critique +

microtypography. The tell is almost always spacing detail, not font choice.

• "Audit our typography" → typography-audit, which pulls others as needed.

5. Failure patterns

| Pattern | Cause | Fix | |---|---|---| | Answered from memory; emitted a constant | Router skipped | Load the skill; encode the procedure | | Loaded all twenty-one skills | Routing by topic, not by change | 2–4 max | | Routed "kerning" to letterform spacing | Took the word literally | Usually tracking → microtypography | | Font swap recommended for a spacing problem | Skipped typography-critique §4 | Diagnose before prescribing | | Body text set with no accessibility check | Co-load rule ignored | Always add typography-accessibility | | Emitted 2017 font-loading advice | Corpus treated as current | Rule 1 outranks the books | | Gave taste feedback when criteria existed | Critique/audit conflated | Criteria → audit | | Claimed "accessible" after contrast only | Criteria treated as one | Check 1.4.4 and 1.4.12 too |

6. Evaluation procedure

1. Identify what the task actually changes.
2. Pick 2–4 skills from the table. Apply co-load rules.
3. Read them before answering — not after drafting.
4. If two skills conflict, resolve with the hierarchy and name the winning rule.
5. Before answering, check: did I emit any bare constant? Replace it with its

decision procedure.

1. Check whether the claim needs a rendered artifact. If you didn't render it, say so.
2. If the answer touches CSS, browser support, or font loading, verify against MDN —

the corpus is 2007–2024.

7. Output format

Routed to: ,  [+  because ]
Assumption: 

Conflicts resolved: 
Unverified: 

8. Examples

"Our dashboard numbers look wobbly."

> Routes to ui-component-typography (tabular figures own this) plus > typeface-anatomy (to confirm the face actually ships a tnum set). Two skills, > not five. The word "wobbly" is a rendering symptom, so the answer requires looking > at the rendered table — flag that if you can't.

"Set up typography for our new marketing site."

> Greenfield and broad, so route in sequence rather than loading everything at once: > typeface-selection → hierarchy-and-scale → responsive-typography, co-loading > typography-accessibility (body text) and font-loading-and-performance > (webfonts). Answer each stage before moving on; don't try to produce a whole > system in one pass.

9. Counterexamples

• ❌ Answering "what line-height should I use?" directly. — That's

body-text-and-reading, and the answer depends on measure, size, and face.

• ❌ Loading all twenty-one skills for "pick a font."
• ❌ Routing "the text looks bad on mobile" to typeface-selection. — Almost always

responsive-typography + body-text-and-reading.

• ❌ Treating typography-audit and typography-critique as interchangeable. —

Criteria exist → audit. Taste → critique.

• ❌ Skipping international-typography because "we're English-only for now." — If

the product will localise, the layout decisions are being made now.

• ❌ Quoting a book on font-display behavior. — Rule 1 outranks rule 4.

10. Source citations

Corpus: Lupton Thinking with Type 3e (2024); Rutter Web Typography (2017); Brown Flexible Typesetting (2018); Elam Typographic Systems (2007); Hochuli Detail in Typography (2008); Coles The Anatomy of Type (2012); Lupton (ed.) Type on Screen (2014); Latin Better Web Typography (2017); Santa Maria On Web Typography (2014); Stocks Universal Principles of Typography (2024).

Living sources, which outrank the books on implementation: MDN CSS Fonts · WCAG 2.2 · web.dev fonts · W3C Internationalization

See also references/source-hierarchy.md and references/corpus-conflicts.md.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jpoindexter
• Source: jpoindexter/typography-skills
• License: MIT

Install and usage instructions live in the source repository linked above.