Font Pairing: Design & Brands

View saved version →

---
name: brand-brief-to-type-system
description: Turn a brand, product, or campaign brief into a coordinated heading, accent, and body Google Font system and preview it with the Font Pairing app. Use when a user supplies an audience, brand personality, market, medium, reference style, or creative direction and wants a concrete font trio. Also use for incomplete briefs when sensible assumptions can resolve the missing details. Do not use for abstract typography advice that does not request a specific pairing.
---

# Brand Brief to Type System

Turn strategic language into one usable, previewed typography direction. Keep the response focused on decisions the user can evaluate in the widget.

## Verify the app tool

Confirm 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.

## Gather the brief

Identify or infer:

- the audience and desired impression;
- the product, content, and reading context;
- three to five personality traits;
- any required, preferred, or forbidden fonts and styles;
- the balance between distinctiveness and restraint.

Ask one concise question only when the answer would materially change the direction. Otherwise, proceed and state important assumptions briefly.

## Build the system

1. Translate the brief into selection criteria for tone, hierarchy, contrast, and sustained reading.
2. Define each role before choosing families:
   - make the heading carry the strongest brand personality;
   - make the accent support navigation, emphasis, or short supporting copy;
   - make the body comfortable for the expected reading context.
3. Choose a coordinated trio rather than three individually interesting fonts. Avoid giving every role the same visual intensity unless the user explicitly wants that effect.
4. Invoke `suggest-fonts` with exactly one `heading`, `accent`, and `body`. Use only schema-listed families and supported weight/style combinations. Include a concise `reason` tied to the brief.
5. After the widget appears, explain each role in one sentence and name the most important tradeoff. Encourage the user to edit the specimen, lock successful roles, or request a refinement when useful.

For a refinement, preserve fonts marked `locked` in model-visible widget state and honor constraints stated in the follow-up prompt. Invoke `suggest-fonts` again only when presenting a revised trio.

## Deliver the result

Provide:

- a short name for the direction;
- the visual trio from `suggest-fonts`;
- a concise rationale for heading, accent, and body;
- one practical usage note or tradeoff;
- a clear next refinement choice when the brief leaves meaningful alternatives.

## Boundaries

- Recommend only Google Font families and variants accepted by `suggest-fonts`.
- Treat the tool schema as authoritative; do not invent or silently substitute unsupported variants.
- Do not claim to edit preview copy, locks, or similarity controls. Those are widget actions; only model-visible lock state may guide a later recommendation.
- Do not claim verified glyph coverage, loading performance, or accessibility compliance. The app does not expose the measurements needed for those guarantees.

View saved version →

---
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.
---

# Legibility-First Type System

Build the system from the body text outward, then preview the complete hierarchy with the app.

## Verify the app tool

Confirm 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.

## Establish the reading conditions

Identify or sensibly infer:

- content type, density, and typical reading duration;
- audience needs and likely devices;
- language or script requirements;
- brand constraints and the desired amount of personality;
- whether the accent role is functional or decorative.

Ask only when a missing constraint creates a material legibility risk. State any conservative assumptions.

## Select the trio

1. 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.
2. Add a heading that creates an obvious hierarchy without sacrificing recognition at smaller sizes. Prefer weight, proportion, or category contrast over decoration alone.
3. 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.
4. Use italics only where the selected family supports the chosen weight and the brief has a useful emphasis role for them.
5. 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.

If 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.

## Give usage guardrails

After the widget appears, provide adjustable starting guidance:

- body text around 16–18 CSS pixels with roughly 1.5–1.7 line height;
- a readable line length, usually about 45–75 characters;
- clearly stronger heading hierarchy without relying on ultra-light weights;
- limited use of all caps, italics, and decorative accents;
- testing with real content, zoom, narrow screens, and the intended scripts.

Adapt these ranges to the user's medium instead of presenting them as universal requirements.

## Deliver the result

Provide:

- the visual trio from `suggest-fonts`;
- a body-first explanation of the three roles;
- the most relevant reading and hierarchy guardrails;
- any unresolved script, size, or environment caveat;
- a suggested role to lock before exploring a refinement.

## Boundaries

- Treat the `suggest-fonts` schema as authoritative for families and variants.
- Do not claim WCAG conformance, dyslexia suitability, measured readability, glyph coverage, or performance results. The app does not test those properties.
- 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.
- Distinguish legibility guidance from medical or accessibility certification.

View saved version →

---
name: typography-direction-comparison
description: Develop, preview, and compare distinct Google Font directions for one brand or product brief. Use when a user asks for multiple typography concepts, alternatives, mood-based routes, or an A/B-style creative comparison before choosing a trio. Default to three clearly differentiated directions unless the user requests another manageable count; use a separate `suggest-fonts` call and widget for each direction.
---

# Typography Direction Comparison

Create alternatives that represent meaningful strategic choices, not minor substitutions within one idea.

## Verify the app tool

Confirm that `suggest-fonts` is available before defining or describing font directions. If it is unavailable, stop and say that the Font Pairing app must be enabled to generate the previews; do not present speculative families as completed directions. Describe a preview as rendered only after its tool call returns structured font output.

## Frame the comparison

Identify the shared audience, context, brand traits, constraints, and evaluation criteria. Default to three directions. Honor an explicit smaller count, and keep a larger request manageable by grouping or narrowing it before generating excessive widgets.

Define and name every direction before selecting fonts. Make each direction differ on at least two useful dimensions, such as:

- traditional versus contemporary;
- expressive versus restrained;
- serif-led versus sans-led;
- high versus subtle role contrast;
- editorial warmth versus product precision.

Keep non-typographic constraints consistent so the comparison remains meaningful.

## Generate the directions

For each direction:

1. State its name and one-sentence intent.
2. Select a coordinated heading, accent, and body trio that embodies that intent.
3. Invoke `suggest-fonts` once for that direction. Use only schema-listed families and supported weight/style combinations, and identify the direction in the optional `reason`.
4. Add one concise strength and one tradeoff after its widget.

Do not reuse two of three families across directions unless a fixed or locked font is part of the brief. When a font is fixed, vary the surrounding roles enough to create genuinely different systems.

## Compare and recommend

After all requested widgets appear:

- compare the directions against the same criteria;
- identify the strongest context for each;
- recommend one direction and explain the decisive tradeoff;
- ask the user to choose a direction or name the element to preserve.

On the next refinement, work only from the chosen direction unless the user requests another comparison. Preserve model-visible locked fonts and invoke `suggest-fonts` again only for the revised trio.

## Deliver the result

Provide:

- named and clearly differentiated directions;
- one `suggest-fonts` widget per direction;
- a compact strengths-and-tradeoffs comparison;
- one reasoned recommendation;
- a direct refinement choice.

## Boundaries

- The app renders one trio per tool call; do not claim the widgets form a single side-by-side canvas.
- Treat the `suggest-fonts` schema as authoritative and correct any rejected variant instead of describing an unrendered preview as successful.
- Do not claim that a subjective recommendation is an objective score or user-test result.
- Do not claim to operate locks, similarity, or preview-text controls. Use only model-visible state and explicit follow-up instructions.