← Font Pairing: Design & BrandsCONTENT HISTORY

Update to Font Pairing: Design & Brands

Snapshot Sep 30, 2026 · 22:48 UTC · version 1.0.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "name": "legibility-first-type-system",
  "description": "Create and preview a legibility-first heading, accent, and body Google Font system for long-form reading, dense interfaces, educational material, healthcare content, older audiences, or other readability-sensitive work. Use when reading comfort and hierarchy matter more than typographic novelty. Provide practical usage guardrails without claiming that font choice alone establishes accessibility compliance.",
  "included_files": [],
  "skill_md_contents": "---\nname: legibility-first-type-system\ndescription: Create and preview a legibility-first heading, accent, and body Google Font system for long-form reading, dense interfaces, educational material, healthcare content, older audiences, or other readability-sensitive work. Use when reading comfort and hierarchy matter more than typographic novelty. Provide practical usage guardrails without claiming that font choice alone establishes accessibility compliance.\n---\n\n# Legibility-First Type System\n\nBuild the system from the body text outward, then preview the complete hierarchy with the app.\n\n## Verify the app tool\n\nConfirm that `suggest-fonts` is available before selecting or describing a trio. If it is unavailable, stop and say that the Font Pairing app must be enabled to generate the preview; do not present speculative families as a completed result. Describe a preview as rendered only after the tool returns structured font output.\n\n## Establish the reading conditions\n\nIdentify or sensibly infer:\n\n- content type, density, and typical reading duration;\n- audience needs and likely devices;\n- language or script requirements;\n- brand constraints and the desired amount of personality;\n- whether the accent role is functional or decorative.\n\nAsk only when a missing constraint creates a material legibility risk. State any conservative assumptions.\n\n## Select the trio\n\n1. Choose the body role first. Favor a restrained, text-appropriate family with a supported regular or medium weight. Avoid display, handwriting, very light, and highly condensed choices for sustained body copy.\n2. Add a heading that creates an obvious hierarchy without sacrificing recognition at smaller sizes. Prefer weight, proportion, or category contrast over decoration alone.\n3. Add an accent that remains clear in short labels or supporting copy. Keep handwriting and display faces out of functional UI text and long passages.\n4. Use italics only where the selected family supports the chosen weight and the brief has a useful emphasis role for them.\n5. Invoke `suggest-fonts` with exactly one `heading`, `accent`, and `body`, using only schema-listed families and supported variants. Include a concise `reason` describing the reading context.\n\nIf a requested language or script is important, avoid asserting coverage from a family name alone. Ask the user to test representative text in the editable specimen when coverage is not established by available information.\n\n## Give usage guardrails\n\nAfter the widget appears, provide adjustable starting guidance:\n\n- body text around 16–18 CSS pixels with roughly 1.5–1.7 line height;\n- a readable line length, usually about 45–75 characters;\n- clearly stronger heading hierarchy without relying on ultra-light weights;\n- limited use of all caps, italics, and decorative accents;\n- testing with real content, zoom, narrow screens, and the intended scripts.\n\nAdapt these ranges to the user's medium instead of presenting them as universal requirements.\n\n## Deliver the result\n\nProvide:\n\n- the visual trio from `suggest-fonts`;\n- a body-first explanation of the three roles;\n- the most relevant reading and hierarchy guardrails;\n- any unresolved script, size, or environment caveat;\n- a suggested role to lock before exploring a refinement.\n\n## Boundaries\n\n- Treat the `suggest-fonts` schema as authoritative for families and variants.\n- Do not claim WCAG conformance, dyslexia suitability, measured readability, glyph coverage, or performance results. The app does not test those properties.\n- Do not claim to change private preview text or widget controls. Ask the user to paste representative content into the editable specimen when that test matters.\n- Distinguish legibility guidance from medical or accessibility certification.\n"
}

SHA-256: 5b337aea56b5f5bdb5573aaae77769d388e94ed6705400498627f0d83b6a60b2