typeset

typeset skill の概要

typeset ができること

typeset skill は、UI のタイポグラフィが無難すぎる、平板に見える、統一感がない、流し読みしづらいといった状態を改善するための skill です。フォント選定、情報階層、サイズ、ウェイト、余白感、可読性に焦点を当て、インターフェース全体を「なんとなく」ではなく意図を持って設計された印象に近づけます。

typeset を使うべき人

この skill は、アプリ画面、ランディングページ、ダッシュボード、テキスト量の多い UI を扱うデザイナー、フロントエンド実装者、AI 活用型のプロダクトチームに特に向いています。とくに、レイアウト自体はすでにあるのに、タイプシステムだけがまだ洗練されて見えない場合に有効です。

実際に解決したい仕事

多くのユーザーが必要としているのは、抽象的なタイポグラフィ理論ではありません。求めているのは、画面やコードベースを見て、何が弱いのか、どこを変えるべきか、テキストをどうすれば読みやすく・優先順位を把握しやすくできるのかを具体的に示してくれることです。typeset は、その実務的なニーズに応えるために作られています。

typeset が他と違う点

「タイポグラフィを良くして」といった汎用プロンプトと違い、typeset は、フォントの適合性、階層の明快さ、スケールの一貫性、可読性という観点で、構造化されたレビューを行います。最大の違いは、単体で使う前提ではなく、まず /frontend-design を通じて広い設計コンテキストを取り込み、必要に応じて /teach-impeccable も使う設計になっている点です。

インストール前に知っておきたいこと

これは完全なデザインシステム生成ツールでも、フォント探索エンジンでもありません。typeset skill の価値がもっとも発揮されるのは、既存 UI の文脈、現在のスタイル、目指すプロダクトのトーンを渡せるときです。曖昧な「雰囲気の提案」ではなく、具体的なタイポグラフィ改善の指摘が欲しいなら、かなり相性の良い skill です。

typeset skill の使い方

typeset の導入コンテキスト

上流の SKILL.md には、この skill 専用の install コマンドは記載されていません。Claude Code の skill 構成では、親リポジトリの skill を追加したうえで、typeset を名前指定で呼び出す使い方が一般的です。このリポジトリでの基本例は次のとおりです。

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

環境ごとに別の skill loader を使っている場合は、pbakaus/impeccable リポジトリを追加し、.claude/skills/typeset skill を対象にしてください。

最初に読むべきファイル

まずは .claude/skills/typeset/SKILL.md を確認してください。この skill では、そのファイルが事実上の一次情報です。リポジトリ上の確認可能な範囲では、追加スクリプト、参照資料、補助リソースは特に表に出ていないため、導入判断の大半は、この単体ワークフローが自チームにとって実用的かどうかで決まります。

typeset 実行前に必須の依存関係

導入時にもっとも見落とされやすい注意点は、typeset をいきなり単独で走らせる想定ではないことです。この skill は、設計原則とコンテキスト収集の手順を含む /frontend-design を先に実行する前提になっています。もし設計コンテキスト自体がまだない場合は、指示どおり /teach-impeccable を先に実行する必要があります。

typeset install を調べている人ほど、この skill を単独のタイポグラフィ用プロンプトだと誤解しがちですが、実際には段階的なワークフローの一部です。

typeset に必要な入力

有用な出力を得るには、少なくとも次のいくつかを渡してください。

• スクリーンショット、または画面の説明
• 現在使っている font family
• 文字サイズやウェイトに関する CSS または design token
• プロダクトの種類: SaaS app、marketing page、dashboard、mobile UI
• ブランドの性格: formal、playful、premium、technical、editorial
• 問題の定義: 「見出しが目立たない」「全体が似た印象になる」「本文が読んでいて疲れる」

これらがないと、typeset usage はどうしても抽象度の高い提案に留まりやすくなります。

あいまいな要望を強い typeset プロンプトに変える

弱いプロンプト:

• “Improve the typography.”

より強いプロンプト:

• “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.”

強いほうが機能するのは、文脈、現状、評価基準が揃っているからです。

実際に typeset が評価するポイント

リポジトリ上で確認できる内容から見ると、typeset は次の観点をチェックします。

• フォントが無難なデフォルト寄りになっていないか
• フォントがブランドの性格に合っているか
• family を使いすぎていないか
• 見出し、本文、キャプションが視覚的に十分区別されているか
• サイズ刻みが近すぎないか
• ウェイト差に意味のあるコントラストがあるか
• タイプスケールに一貫性があるか
• 本文テキストが読みやすいか
• サイズ設計が UI の文脈に合っているか

このため、typeset はゼロからのコンセプト設計よりも、監査やブラッシュアップに向いた skill といえます。

実案件でのおすすめ typeset ワークフロー

1. /frontend-design で設計コンテキストを集める。
2. コンテキストがまだないなら /teach-impeccable を実行する。
3. 対象となる画面、フロー、またはコンポーネント群を指定して typeset を呼び出す。
4. 診断と改善提案の両方を求める。
5. タイポグラフィ変更をコードまたはデザインツールに反映する。
6. 修正版に対して typeset を再実行し、階層や可読性が本当に改善したか確認する。

この反復ループに入ったとき、typeset guide は一発勝負のプロンプトより大きな価値を発揮します。

UI Design 向け typeset がハマるケース

typeset for UI Design が特に強いのは、次のような場面です。

• アプリ全体が「いかにも初期状態」に見える
• ダッシュボードの文字階層が濁っている
• mobile UI の文字が窮屈に感じる
• ランディングページに視覚的なリズムがない
• design system の font size や weight が場当たり的になっている
• ブランド刷新でタイポグラフィからトーンをより明確に伝えたい

一方で、長文の editorial typography、印刷物のレイアウト、踏み込んだ font licensing 判断にはあまり向いていません。

出力品質を上げる実践的なコツ

適用しやすい形式で出力するよう依頼すると効果的です。たとえば次のような形です。

• 提案する type scale
• heading / body / caption の対応表
• 推奨する font count の上限
• 具体的な weight の割り当て
• 小さい文字に対する readability 改善案
• rem や clamp() を使うのが妥当な箇所に関するメモ

リポジトリ抜粋でも、app UI の scale と fluid sizing 戦略は明確に区別されているため、実装を意識した guidance を求めるのは妥当です。

typeset 使用後に結果を確認する方法

「前よりきれいになった」で止めないでください。確認すべきなのは次の点です。

• ユーザーは見出しレベルの違いをすぐ判別できるか
• 本文サイズは読める最低ラインに達したか
• サイズ差は以前より明確になったか
• 太字を多用しすぎずに、ウェイト差が視認できるようになったか
• 選んだフォントはプロダクトの性格に合っているか

ここがまだ「なんとなく改善した程度」に見えるなら、プロンプトにプロダクトや画面の文脈が足りていない可能性が高いです。

typeset skill FAQ

typeset は初心者向けですか？

はい、改善したい画面やプロダクト像がすでにあるなら初心者でも扱えます。逆に、何もない状態から design direction を作ってくれることを期待するなら向いていません。/frontend-design に依存しているため、まずブランドや UI の基本コンテキストを固めてから使うほうが、初心者でも結果が安定します。

typeset は普通のプロンプトより優れていますか？

多くの場合、狙いを絞ったタイポグラフィ批評では yes です。通常のプロンプトだと、「コントラストを上げる」「もっと良いフォントを使う」といった一般論に流れがちです。typeset skill は、階層、スケール、可読性、フォント適合という軸で再現性のある監査フレームを持っているぶん、実務で使いやすくなっています。

スクリーンショットやコードは必要ですか？

両方必須というわけではありませんが、どちらか一方でもあると精度がかなり上がります。スクリーンショットがあれば階層や視覚的リズムを判断しやすくなり、CSS、token、component code があれば、そのまま実装できるサイズやウェイト変更を提案しやすくなります。

typeset を使わないほうがいいのはいつですか？

主な問題がタイポグラフィではなく、レイアウト、spacing、color contrast、UX flow にあるなら、typeset は後回しにしたほうがよいです。また、設計コンテキストがまだなく、前提ワークフローを実行するつもりもないなら適しません。そうしたケースでは、より広い設計 skill から入るほうが正しい順番です。

typeset はフォントまで選んでくれますか？

現在のフォントが無難すぎるか、ブランドとずれているかを評価する助けにはなりますが、font catalog や調達ツールとして提示されているわけではありません。あくまで typography improvement skill であり、完全な typeface selection service ではないと考えるのが適切です。

typeset は洗練された全面リデザイン向けだけですか？

いいえ。実用的な調整にも十分役立ちます。たとえば、本文サイズを上げる、階層の差を広げる、font family の散らかりを抑える、ダッシュボードを流し読みしやすくする、といった改善です。派手な見た目変更より、こうした修正のほうが価値が高い場面は少なくありません。

typeset skill を改善する方法

ブランドとプロダクトの文脈をもっと具体的に渡す

typeset の結果を最短で改善する方法は、その UI がどんな印象であるべきかを具体的に伝えることです。「モダン」は曖昧すぎます。より良い入力例は次のようなものです。

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

意図するトーンがわかるほど、タイポグラフィ判断の精度は上がります。

問題だけでなく現在の type system も渡す

既存の size、weight、family を共有すれば、skill は推測ではなく構造的な問題診断ができます。たとえば次のような情報です。

• 14 / 16 / 18 / 20 のサイズで全テキストが Inter
• heading が 500、body が 400
• caption が 12px で readability に問題がある

こうした情報があると、typeset usage は感想レベルから実行可能な改修提案へ進みやすくなります。

Before / After 前提の改善計画を求める

「良くして」ではなく、次の形で依頼してください。

• 今どこが悪いのか
• 何から先に変えるべきか
• 改訂後の scale 案
• 各変更の rationale
• 想定されるリスクや tradeoff

この構成にすると、曖昧な助言が減り、初回出力の時点で実装しやすくなります。

よくある失敗パターンを意識する

もっとも多い失敗ケースは次のとおりです。

• 文脈が少なすぎて、助言が generic なままになる
• 実際は layout の問題なのに typography のせいにしてしまう
• hierarchy より font の差し替えに意識が寄りすぎる
• “premium” や “modern” を audience context なしで求める
• 無関係な複数画面にまたがるすべての text role を一度に解決しようとする

対象画面や component set を絞るだけでも、結果はかなり改善します。

そのまま実装できる形での出力を求める

コード中心で作業しているなら、token や CSS ベースの変更として提案してもらうのが有効です。デザインツール中心なら、display、heading、body、label、caption のような role-based system で整理してもらうと扱いやすくなります。出力形式が良いほど、レビュー後の変換コストは下がります。

初回提案のあとに再度まわす

変更を適用したあと、修正版の画面に対してもう一度 typeset を実行し、次の点を確認してください。

• どの hierarchy 問題がまだ残っているか
• body text は十分に読みやすくなったか
• weight の差はまだ弱すぎないか
• mobile と desktop の両方で system が成立するか

多くの場合、この 2 回目のパスで typeset はより有効になります。推測ではなく、実際に改善されたものを批評できるからです。

より広いデザインレビューと併用する

typeset は /frontend-design に依存しているため、より大きな UI review process の一層として使うのが適切です。まず広い設計 skill で原則や anti-pattern を整理し、そのうえで typeset で text system を集中的に磨き込む。この役割分担が、リポジトリで意図されているワークフローに合っており、skill を守備範囲外で使ってしまうのも防げます。