mcpField
T
typography-system

typography-system

github.com/sanky369デザイン・UI31258 回インストール15 週間前に更新
リポジトリ

typography-system について

既存のコードベースに文字サイズのスケール、フォント、可読性のルールを構築して適用するフロントエンドデザイン向けスキルです。既存のスタイルシステムを調べ、実際のテキスト要素までトークンを反映します。

主な機能

  1. 01サイズ、フォント、行間の調査
  2. 02画面密度に応じたスケール選択
  3. 03行間付きタイポグラフィトークン作成
  4. 04テキストスタイルの適用と移行
  5. 05コントラストと可読性の確認

活用シーン

  1. 01分散した文字サイズの統一
  2. 02ダッシュボード向けの緻密な組版
  3. 03長文コンテンツの可読性改善

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sanky369/vibe-building-skills --skill typography-system

インストール後、Claude Code で/typography-systemを入力して読み込まれたか確認します。

同梱ファイルreferences/type-details.md

詳細

タイポグラフィシステム

このコードベースで実際に機能するタイプスケールを作成してください — 既存のスタイリングシステムに組み込まれたトークンとして定義し、実際の見出し・本文・UI テキストに適用します。タイポグラフィについての論説ではありません。基本原則: サイズはプロダクトの密度に合わせて選ばれたモジュラースケールから導出します。可読性の制約(行の高さ、一行の文字数、コントラスト)は譲れないものであり、見た目の美しさより優先されます。

いつ使うか / 引き継ぎ

  • タイプスケール、フォントの選定・読み込み、見出しの階層、可読性の修正、流体タイポグラフィに使用します。
  • トークン基盤がまだまったくない場合 → まず skills/frontend-design/design-foundation を実行してください(またはその最初のスライスとしてタイプトークンを作成します)。
  • テキストカラーがコントラストに失敗する問題は skills/frontend-design/color-system と共通の領域です — ここで触れたペアはここで修正し、パレット全体に関わる作業はそちらに送ってください。
  • 見出しのサイズは適切なのにページの可読性が依然として低い場合 → skills/frontend-design/visual-hierarchy-refactoring。

ステップ 1 — コードベースを調査する

  1. フォントサイズを数える。 font-size:\s*[\d.]+(px|rem)、Tailwind の text-(xs|sm|base|lg|xl|\dxl) および任意値の text-\[ を grep します。種類が 8〜10 を超える場合は乱立しています。出現頻度とともにリストを記録します。
  2. フォントを見つける。 font-family|@font-face|fonts.googleapis|next/font を grep し、tailwind.config.* / @theme の fontFamily を確認します。ファミリー数と読み込んでいるウェイトを数えます。
  3. 行の高さと一行の文字数を確認する。 line-height|leading- および max-width.*ch|max-w-prose を grep します。
  4. 既存のトークンを確認する。 design-foundation が実行済みならそのファイルを拡張します。並行するシステムを新たに作らないでください。
  5. プロダクトの密度を画面そのものから分類します: データテーブル / ダッシュボード / 多数のコントロール = 高密度、ランディング / マーケティング = ゆったり、長文の閲覧 = エディトリアル。

ステップ 2 — ヒアリング

不足しているものだけを一度にまとめて質問します: ブランドの印象を数語で(または「任せる」)、そして現在のフォントを維持するか、変更も許容するか? 密度はコードから推測し、基本サイズは高密度データでない限り 16px とします(高密度データの場合は本文 14px も許容されます)。止まらないでください — 画面が確認できる場合は、前提を述べて構築を進めます。

ステップ 3 — スケールを構築する

プロダクトの密度によって比率を選びます(これが核心の判断ルールです):

プロダクト比率理由
高密度データアプリ、ダッシュボード、管理画面1.125〜1.2(長二度)巨大な見出しを使わずに多くのレベルを収める必要がある
標準的なプロダクト UI / SaaS1.25(長三度)バランスが良い。迷ったときのデフォルト
マーケティングサイト、ランディングページ1.25〜1.333見出しに存在感が必要
エディトリアル / ブランド色が強い、大きなヒーロー1.414〜1.618レベルが少なく、劇的なジャンプ

基本サイズ × 比率^n で生成し、常識的なピクセル値にスナップします(16px からの 1.25 スケール → 16, 20, 25, 31, 39, 49, 61。必要に応じて丸めます)。キャプション / ラベル用に基本サイズの下へ xs(12) と sm(14) を追加します。スケールは実際に使用する最大サイズで打ち切ります — 設定アプリに 76px のディスプレイトークンを出荷しないでください。

行の高さはサイズと反比例させます: 本文 1.5〜1.7、小見出し 1.3、大きな見出し 1.1〜1.2、キャプション / ラベル 1.4。行の高さはサイズトークンの中に含めます(Tailwind の fontSize タプルはこれをネイティブに実現します)。

流体見出し: 約 31px 以上のサイズでは、ブレークポイントごとの上書きではなく clamp(最小値, 推奨 vw 式, 最大値) を使用します。本文テキストは固定(16px)のままにします — 基本サイズより下を流体にしないでください。

フォント: ファミリーは 2 つまで、ウェイトは 3〜4 つ(400/500/600/700 のサブセット)に制限します。選ぶ場合: 本文には定番の UI サンセリフ(可能なら可変フォント)を選び、見出しには必要に応じて述べた印象に合うディスプレイフォントを 1 つ選びます。フレームワークのオプティマイザー(next/font など)または preload + font-display: swap で読み込みます。ペアリング表とフォント機能の詳細: references/type-details.md。

標準的な形(Tailwind v3。検出したスタックに合わせて調整してください)
fontSize: {
  xs:   ['0.75rem',  { lineHeight: '1.4' }],           // 12 — captions, labels
  sm:   ['0.875rem', { lineHeight: '1.5' }],           // 14 — secondary UI text
  base: ['1rem',     { lineHeight: '1.6' }],           // 16 — body
  lg:   ['1.125rem', { lineHeight: '1.6' }],           // 18 — lead paragraphs
  xl:   ['1.25rem',  { lineHeight: '1.3', fontWeight: '600' }],  // 20 — h4/h5
  '2xl': ['1.5625rem', { lineHeight: '1.3', fontWeight: '600' }], // 25 — h3
  '3xl': ['clamp(1.6rem, 1.2rem + 1.6vw, 1.9375rem)', { lineHeight: '1.2', fontWeight: '700' }], // h2
  '4xl': ['clamp(1.9rem, 1.3rem + 2.4vw, 2.4375rem)', { lineHeight: '1.1', fontWeight: '700' }], // h1
}

ステップ 4 — 適用と移行

  1. トークンをプロジェクトのシステム(Tailwind 設定 / @theme / CSS 変数)に書き込みます。
  2. ページごとの単発クラスではなく、ベース要素または共有コンポーネント(見出し、p、ラベル、ボタン)に適用します。
  3. 長文テキストを制約します: 長文コンテナに max-width: 65ch を設定します。
  4. ステップ 1 で洗い出した上位の逸脱サイズを、トラフィックの多い 1〜3 ファイルで移行し、残りはマッピングします。

必須の出力形式

コードに加えて、以下のサマリーを提出してください:

## Type tokens
[file path + full code in the project's system]

## Scale decision
- Density: [dense/standard/marketing/editorial] — evidence: [what you saw]
- Ratio: [x] · Base: [16px] · Levels: [list, snapped px values]
- Fonts: [family/weights] — [kept existing / chosen because …] · Loading: [mechanism]

## Migration map
| Found | Count | Replace with |
| text-[15px], 15px | 12 | text-sm (14px) |
| ... |

## Applied now
[components/files actually restyled]

## Verify
[Contrast pairs checked with ratios; measure per breakpoint]

品質基準(提出前に確認)

  • 合計サイズが 8〜10 以下で、すべてスケール上にあり、移行したすべての値がちょうど 1 つのトークンに対応している
  • 本文は 16px 以上(14px 以上が許されるのは密度の高いデータ UI のみで、長文テキストには決して使用しない)
  • 行の高さ: 本文 1.5〜1.7、見出し 1.1〜1.3、1.1 を下回らない
  • すべてのブレークポイントで本文テキストの 1 行の長さが 45〜75ch
  • テキストと背景のコントラストが通常テキストで 4.5:1 以上、大きなテキスト(24px 以上、または 18.7px 以上の太字)で 3:1 以上 — 算出した比率を明記すること
  • フォントファミリーは 2 以下、実際に読み込むウェイトは 4 以下。font-display: swap またはフレームワーク相当の設定
  • 見出しレベルが一目で区別できる(隣接するレベルが比率ステップ AND/OR ウェイトで異なる)
  • 流動的な clamp() は大きな見出しにのみ使用し、本文サイズは固定
  • レタースペーシング: 39px 以上の見出しではやや負の値(−0.01〜−0.02em)、すべて大文字のラベルではやや正の値(+0.05em)

統合

  • 消費元: skills/frontend-design/design-foundation のトークンファイル(そのタイポグラフィスライスを拡張); skills/frontend-design/layout-system のレイアウトコンテナ(1 行の長さはそちらで管理)。
  • 生成先: skills/frontend-design/visual-hierarchy-refactoring(サイズ/ウェイトの階層)および skills/frontend-design/component-architecture(コンポーネントのテキストスタイル)が消費するタイプトークン。
  • コントラストのペアは skills/frontend-design/color-system に渡され、skills/frontend-design/accessibility-excellence によって監査されます。

参考文献

  • references/type-details.md — パーソナリティ別のフォントペアリング表、可変フォント、OpenType 機能(表形式数字、スモールキャップス)、記事/UI タイポグラフィの全パターン、および完全な比率 → スケール表。フォントの選択や長文コンテンツのスタイリング時に参照してください。

コメント