pretty-ui

AIが構築する画面は、誰も選択をしないせいでどれも似たり寄ったりになります。モデルはすべての隙間を自分が見た中で最も一般的な答えで埋めるため、結果としてどのプロダクトにも見えるページができあがります。

pretty-uiはそれを、デザイナーが取るであろう順序で修正します。方向性を選び、それを文書化し、すべてに適用して結果を確認するという順序です。選択はエージェントだけでなく、人間が実際に見て選べる選択肢の中から行います。

実行手順

以下の手順を順番に実行してください。各ステップをユーザーに伝えながら進めてください。

1. プロジェクトを読む

何が作られているのかを特定する: 読んでスクロールするページ（ランディングページ、マーケティングサイト、ポートフォリオ）、人が作業するWebアプリ画面（ダッシュボード、設定、受信箱）、またはモバイルアプリ。
スタックを特定する: プレーンなHTML、Tailwind、shadcn/ui、React、Vue、Svelte、React Native、SwiftUI、Compose、Flutterのいずれか。そのスタックで作業し、移行は絶対に行わない。
既存のビジュアルシステムを探す: DESIGN.md、AGENTS.md、CLAUDE.md内のデザインノート、Tailwindやshadcnのテーマ変数、ブランドガイド、ロゴ。ブランドにすでに色とフォントがある場合は、それらを維持する。 その場合、ステップ3での方向性は、ブランドそのものではなく、ブランド内でレイアウト、タイプスケール、密度、アクセントを変化させる。
実際のコンテンツを収集する: プロダクト名、何をするものか、誰のためのものか、実際の数字、実際のスクリーンショット。プレースホルダーコンテンツはすべてのデザインをありきたりにする。

2. 監査（既存のUIがある場合のみ）

references/tells.mdを読む。UIをレンダリングするファイルに対してチェッカーを実行する:

node <skill>/scripts/check.mjs <ファイルまたはフォルダ>

結果をユーザーに提示する。重要度ごとにグループ化し、ファイルと行番号を示す。チェッカーでは見つけられないものについてもコードを読んで追加する: 3つの同一カード、すべてが中央揃え、明確な焦点の欠如、フィラーコピー。もし画面がすでに十分デザインされている場合は、その旨を伝え、リデザインではなく2～3の小さな改良を提案する。

3. 3つの方向性を提示する

references/systems.mdを読む。そこには24の完全なデザインシステムがリストされており、12はWeb用、12はモバイルアプリ用で、それぞれに公開されたDESIGN.mdがある。

意図的に異なる3つのシステムを選ぶ: 例えば、明るくエディトリアルなもの、暗くて密なもの、柔らかく親しみやすいもの。プラットフォーム（Webかアプリ）とプロダクトの世界観に合わせる。同じような見た目の3つのバリエーションを決して提示しない。
各システムのDESIGN.mdをそのURLから取得する。
同じ主要画面を、各方向性で、同じ実際のコンテンツを使って、自己完結型のHTMLファイルとして構築する:
- pretty-ui/directions/a-<slug>.html、b-<slug>.html、c-<slug>.html
- Webページは1440×900、モバイル画面は390×844。インラインCSS、Google Fontsリンク、外部画像は使用しない。
簡単に比較できるようにする:
- Codex Designのキャンバスツールが利用可能な場合（例：create_canvasやadd_node）、3つのファイルを1つのキャンバスに並べて開く。
- そうでない場合は、node <skill>/scripts/compare.mjs pretty-ui/directions/*.html --out pretty-ui/directions/index.htmlを実行し、そのファイルを開くようにユーザーに伝える。
ユーザーに1つ選んでもらうか、部分を組み合わせてもらう（「AのタイポグラフィとCのカラー」）。もしユーザーがあなたに決めてほしいと言った場合は、プロダクトに最も適したものを選び、その理由を一文で説明する。

ブランドが固定されている場合、3つの方向性はブランドの色とフォントを使用し、代わりにレイアウト、スケール、密度で差別化する。

4. システムを書き留める

選択されたシステムをプロジェクトルートにDESIGN.mdとして保存する。そのフォーマット（YAMLフロントマターとトークン、続いて概要、色、タイポグラフィ、レイアウト、シェイプ、コンポーネント、Do's and Don'ts）を維持する。
ユーザーが要求した変更（ブランドカラー、異なる見出しフォントなど）は、コードだけでなくファイルにも適用する。
AGENTS.md（およびプロジェクトにあればCLAUDE.md）に一文を追加する: すべての画面でDESIGN.mdに従うこと: 色、タイプ、スペーシング、半径、コンポーネント。 CodexはAGENTS.mdを自動的に読み取るが、DESIGN.mdは読み取らない。
shadcnまたはTailwindプロジェクトの場合、トークンをテーマ変数（--background、--primary、--radiusなど）にマッピングする。各システムページには、すぐに使えるshadcnテーマへのリンクがある: npx shadcn@latest add https://codexdesign.io/r/<slug>.json

5. パスごとに適用する

デザイナーのレッドラインレビューのように、画面全体を一度に1レイヤーずつ作業する。ユーザーが別途要求しない限り、機能、コンテンツ、セクションの順序は維持する。

トークン。 ハードコードされた色、サイズ、半径をシステムのトークンで置き換える。
タイポグラフィ。 最大2ファミリー。システムのスケールを使用する。画面上で最も重要な1行が明らかに最大になるようにする。揃える数字には表組み用数字（tabular figures）を使用する。
スペーシングとレイアウト。 システムの1つのスペーシングユニットとその倍数。すべてをグリッドまたは画面パディングに揃える。関連するものは密にグループ化し、グループ間は広く離す。
カラー。 ニュートラルカラーが画面を支える。プライマリカラーはユーザーがアクションを起こす場所に、ビューあたり約1回表示される。チャートはシステムのチャートカラーを順番に使用する。
コンポーネント。 ボタン、入力、カード、リスト、ナビゲーションはシステムのコンポーネントセクションに従う。実際のアイコン（Lucide、Phosphor、SF Symbols、Material Symbols）を使用し、絵文字をアイコンとして使用しない。
コピーライト。 プロダクトに由来する平易で具体的な言葉。フィラー（「シームレス」「アンロック」「スーパーチャージ」）は削除する。見出しは、そのものが何であるか、何をするかを伝える。
詳細。 ホバー、フォーカス、プレス状態。空、読み込み中、エラー状態。テキストのコントラストは少なくとも4.5:1。
モーション。 何かを説明する場合のみ: 状態変化、画面間の遷移。すべてのセクションにフェードイン、装飾的なパルスは禁止。

モバイルアプリの場合は、references/app.mdも読むこと。

6. チェック

変更したファイルに対して再度チェッカーを実行し、すべてのエラーと、意味のある範囲でできるだけ多くの警告を修正する。
結果を確認する。Playwrightやブラウザツールが利用可能な場合は、1440px幅と390px幅（アプリの場合はデバイスサイズ）でスクリーンショットを撮り、以下の点を修正する: 焦点の欠如、窮屈なグループ、テキストの改行不良、低コントラスト。
リデザインの場合は、共有可能なビフォーアフターページを作成する:

node <skill>/scripts/compare.mjs before.html after.html --labels "Before,After" --out pretty-ui/before-after.html

7. 報告

ユーザーに簡潔に伝える: 選択された方向性とその理由、変更したファイル、チェッカーが検出したビフォーアフターの内容、そしてユーザーの判断が必要な残りの事項（実際の写真、ロゴ、ユーザーだけが書けるコピーなど）。

常に適用されるルール

1つにコミットする前に選択肢を示す。決して黙ってスタイルを選ばない。
ユーザーのブランド、コンテンツ、スタックを維持する。
プロダクトごとに1つのデザインシステム。DESIGN.mdに記述し、すべての場所で従う。
紫色やバイオレットのグラデーション、グラデーションテキスト、ガラスモーフィズムパネル、光るシャドウ、絵文字アイコン、すべての見出しの上のピルバッジ、または同一のアイコンカードの行は、ユーザーが明示的に望まない限り使用しない。
ある決まり文句を別のものに置き換えない。クリーム色にセリフ体とテラコッタのアクセント、またはほぼ黒に1つのアシッドグリーンのアクセントは新しいデフォルトである。プロダクトの世界観がそれを必要とする場合にのみ使用する。
装飾を取り除くことは作業の半分である。スペースを実際のコンテンツ、重要なものにはより大きなタイポグラフィ、そしてプロダクト自体から取った1つの記憶に残る要素で満たす。

ファイル

references/systems.md: 24のデザインシステム。プラットフォーム、スタイル、DESIGN.mdのURLを含む。
references/tells.md: UIがAI製に見える原因と、代わりにすべきこと。
references/app.md: iOS、Android、クロスプラットフォームアプリ画面のルール。
scripts/check.mjs: HTML、CSS、JSX、TSX、Vue、SvelteファイルにおけるAIらしさの静的チェッカー。Node 18以上、依存関係なし。
scripts/compare.mjs: 複数の画面を並べて表示する1つのHTMLページを作成する。方向性の選択やビフォーアフターの表示に使用する。

pretty-ui (デザインされたUI)