typeset

Overview of typeset skill

What typeset does

The typeset skill improves UI typography when text feels default, flat, inconsistent, or hard to scan. It focuses on font choice, hierarchy, sizing, weight, spacing, and readability so interfaces feel intentional instead of generic.

Who should use typeset

This skill is best for designers, frontend builders, and AI-assisted product teams working on app screens, landing pages, dashboards, or content-heavy UI. It is especially useful when you already have a layout, but the type system still looks unpolished.

The real job to be done

Most users do not need abstract typography theory. They need the model to look at a screen or codebase and tell them what is weak, what to change, and how to make text easier to read and easier to prioritize. typeset is built for that practical job.

What makes typeset different

Unlike a generic prompt like “make the typography better,” typeset gives a structured review lens: font suitability, hierarchy clarity, scale consistency, and readability. The most important differentiator is that it explicitly depends on broader design context first, via /frontend-design and, if needed, /teach-impeccable.

What matters before you install

This is not a full design system generator and not a font-discovery engine. The value of the typeset skill is strongest when you can provide existing UI context, current styles, and the target product tone. If you want concrete typography critique rather than vague styling ideas, it is a strong fit.

How to Use typeset skill

Install context for typeset

The upstream SKILL.md does not provide its own install command. In Claude Code skill setups, users commonly add the parent repository skill and then invoke typeset by name. The baseline example for this repo is:

npx skills add https://github.com/pbakaus/impeccable --skill typeset

If your environment uses a different skill loader, add the pbakaus/impeccable repository and target the .claude/skills/typeset skill.

Read this file first

Start with .claude/skills/typeset/SKILL.md. For this skill, that file is the main source of truth. There are no extra scripts, references, or helper resources surfaced in the repository evidence, so most of your adoption decision should come from how usable that single workflow is for your team.

Mandatory dependency before invoking typeset

The biggest adoption caveat is that typeset is not meant to run cold. The skill requires you to invoke /frontend-design first because that contains the design principles and context-gathering protocol. If design context does not exist yet, the instructions say you must run /teach-impeccable before continuing.

This matters because users evaluating typeset install often miss that the skill is part of a chained workflow, not a standalone typography prompt.

What input typeset needs

To get useful output, provide at least some of the following:

• screenshots or screen descriptions
• current font families
• CSS or design tokens for type sizes and weights
• product type: SaaS app, marketing page, dashboard, mobile UI
• brand personality: formal, playful, premium, technical, editorial
• problem statement: “headings don’t stand out,” “everything feels samey,” “body text is tiring”

Without these inputs, typeset usage tends to stay high-level.

Turn a rough goal into a strong typeset prompt

Weak prompt:

• “Improve the typography.”

Stronger prompt:

• “Use typeset for UI Design on this analytics dashboard. Current stack uses Inter only, body text is 14px, headings are 16/18/20 with weak contrast, and dense tables feel hard to scan. Recommend a clearer type hierarchy, better body sizing, weight strategy, and whether we should keep one family or introduce a second accent face.”

The stronger version works because it gives context, current state, and evaluation criteria.

What the skill evaluates in practice

From the repository evidence, typeset checks:

• whether fonts are generic defaults
• whether the font matches the brand personality
• whether too many families are used
• whether headings, body, and captions are visually distinct
• whether size steps are too close together
• whether weight contrast is meaningful
• whether the type scale is consistent
• whether body text is readable
• whether sizing strategy fits the UI context

That makes the skill more useful for audits and refinement than for blank-page concepting.

Suggested workflow for real projects

1. Gather design context with /frontend-design.
2. If context is missing, run /teach-impeccable.
3. Invoke typeset with a target screen, flow, or component set.
4. Ask for both diagnosis and recommended changes.
5. Apply the typography changes in code or design tool.
6. Re-run typeset on the revised version to check whether hierarchy and readability actually improved.

This iterative loop is where the typeset guide becomes more valuable than a one-shot prompt.

Best-fit use cases for typeset for UI Design

typeset for UI Design is strongest when:

• an app looks “too default”
• a dashboard has muddy text hierarchy
• mobile UI text feels cramped
• a landing page lacks visual rhythm
• a design system has arbitrary font sizes and weights
• a brand refresh needs typography to signal tone more clearly

It is less compelling for long-form editorial typography, print layout, or deep font licensing decisions.

Practical tips that improve output quality

Ask the skill to produce output in a format you can apply:

• a proposed type scale
• heading/body/caption mappings
• recommended font count limits
• specific weight assignments
• readability fixes for small text
• notes on where rem or clamp() sizing makes sense

The repository excerpt explicitly distinguishes app UI scales from fluid sizing strategies, so asking for implementation-aware guidance is reasonable.

How to verify the result after using typeset

Do not stop at “looks nicer.” Check:

• can users distinguish heading levels immediately?
• did body text reach readable minimums?
• are size jumps clearer than before?
• did weight contrast become visible without overusing bold?
• does the chosen font fit the product personality?

If the answer is still “sort of,” your prompt likely lacked enough product or screen context.

typeset skill FAQ

Is typeset beginner-friendly?

Yes, if you already know the screen or product you want to improve. No, if you expect the skill to invent your design direction from nothing. Its dependency on /frontend-design means beginners get better results when they first establish basic brand and UI context.

Is typeset better than a normal prompt?

Usually yes for targeted typography critique. A normal prompt may suggest generic advice like “increase contrast” or “use better fonts.” The typeset skill is more useful because it frames a repeatable audit around hierarchy, scale, readability, and font fit.

Do I need screenshots or code?

You do not strictly need both, but one of them helps a lot. Screenshots help the model judge hierarchy and visual rhythm. CSS, tokens, or component code help it recommend specific size and weight changes you can actually implement.

When should I not use typeset?

Skip typeset if your main problem is layout, spacing, color contrast, or UX flow rather than typography. Also skip it if you have no design context yet and are unwilling to run the prerequisite workflow. In those cases, a broader design skill is the better first step.

Does typeset choose fonts for me?

It can help assess whether your current fonts feel too generic or mismatched to the brand, but it is not presented as a font catalog or procurement tool. Treat it as a typography improvement skill, not a complete typeface selection service.

Is typeset only for polished visual redesigns?

No. It is also useful for practical cleanup: raising body text size, widening hierarchy gaps, reducing font family sprawl, or making dashboards easier to scan. Those are often higher-value than dramatic visual changes.

How to Improve typeset skill

Give stronger brand and product context

The fastest way to improve typeset results is to explain what the interface should feel like. “Modern” is too vague. Better inputs look like:

• “B2B finance dashboard, trustworthy and dense”
• “Creative portfolio, expressive but not chaotic”
• “Developer tool, technical and crisp”

Typography decisions become better when the skill knows the intended tone.

Provide the current type system, not just the problem

If you share your existing sizes, weights, and families, the skill can diagnose structural issues instead of guessing. For example:

• 14 / 16 / 18 / 20 sizes with all text in Inter
• headings at 500 and body at 400
• captions at 12px causing readability issues

This lets typeset usage move from opinion to actionable revision.

Ask for a before-and-after plan

Instead of “improve it,” ask for:

• what is wrong now
• what to change first
• a proposed revised scale
• a rationale for each change
• risks or tradeoffs

That structure reduces vague advice and makes first-pass output easier to implement.

Watch for common failure modes

The most common failure cases are:

• too little context, so advice stays generic
• typography being blamed when layout is the real issue
• over-focusing on font swapping instead of hierarchy
• asking for “premium” or “modern” without audience context
• trying to solve every text role at once across unrelated screens

Narrowing the target screen or component set usually improves results.

Ask for implementation-ready output

If you work in code, ask the skill to express recommendations as tokens or CSS-oriented changes. If you work in design tools, ask for a role-based system such as display, heading, body, label, and caption. Better output format means less translation work after the review.

Iterate after the first pass

After applying changes, run typeset again with the revised screen and ask:

• which hierarchy issues remain
• whether body text is now readable enough
• whether weights are still too subtle
• whether the system scales across mobile and desktop

This second pass is often where the skill becomes most useful, because it can critique concrete improvements rather than speculate.

Use typeset alongside broader design review

Because typeset depends on /frontend-design, treat it as one layer in a larger UI review process. Use the broader design skill to establish principles and anti-patterns, then use typeset to tighten the text system specifically. That division of labor matches the repository’s intended workflow and avoids using the skill outside its strongest scope.