ui-anti-slop-codex

UI アンチスロップ Codex

Codex に UI 作業を、ありきたりな画面を埋める作業ではなく、プロダクトデザインのタスクとして扱わせます。対象の画面を分類し、ビジュアルの契約を定め、リポジトリ内のデザイン上の指針を活用して実装した後、最終納品前にレンダリングされた UI を確認します。

ワークフロー

ユーザーが議論のみを明示的に求めている場合を除き、すべての UI タスクで次の手順に従います。

1. リポジトリの実態を把握する

   • 既存の UI ファイル、ルート、グローバルスタイル、コンポーネントライブラリ、アイコンライブラリ、パッケージマネージャー、スクリーンショット、デザインドキュメント、DESIGN.md を確認します。
   • 新しいビジュアルシステムを作るよりも、既存のデザインシステムやローカルコンポーネントを優先します。
   • DESIGN.md がある場合は、ビジュアルを決める前に読みます。タスクで DESIGN.md を作成または編集する場合は、references/design-md-protocol.md を読み込みます。

2. 画面の種類を分類する

   • 作業が次のいずれか、または複数に該当するか分類します：ランディングページ、マーケティングサイト、プラットフォームアプリ、ダッシュボード、管理者向けまたは内部向けツール、エディターまたはクリエイター向け画面、チェックアウトまたは料金ページ、ドキュメントまたは開発者向けページ、モバイル UI、ゲームまたはインタラクティブな画面。
   • 該当する画面について、references/surface-contracts.md を読み込みます。
   • リポジトリを確認しても画面や対象ユーザーが実際に曖昧なままの場合は、最も重要な質問を1つだけ尋ね、推奨する回答も提示します。リポジトリから確認できる事実は尋ねないでください。

3. 参考デザインの系統を選ぶ

   • ユーザーが明示した参考デザインを最優先します。
   • それ以外の場合は、画面、対象ユーザー、ビジネス上の目的、情報密度に合う系統を references/reference-families.md から選びます。
   • 参考デザインはデザインの語彙として扱い、模倣の許可とは見なしません。

4. UI の編集前にビジュアルの契約を明示する

   • 簡潔で実務に役立つ内容にします：

Visual Contract
- Surface:
- User job:
- Reference family:
- Design source:
- Density:
- Layout:
- CRUD create mode:
- Required states:
- Forbidden tells:
- Verification:

• Design source には、既存のリポジトリ内 UI、DESIGN.md、ユーザーが指定した参考デザイン、生成した参考デザイン、推定した系統のいずれが出典かを明記します。
• 画面にレコード、テーブル、管理者向けワークフロー、ダッシュボード、またはプラットフォームの CRUD が含まれる場合は、CRUD create mode が必須です。インライン、モーダル、ドロワー、専用ページのいずれかを指定し、タスクの複雑さとレコードの一覧性に基づいて選択理由を説明します。
• Forbidden tells は、汎用的なリストではなく、この画面に特有のものを挙げます。

5. 契約に沿って実装する

   • まず実際に使える画面を構築します。タスクがプラットフォーム画面なのにランディングページを作ったり、公開ランディングページのタスクなのにプロダクトのコックピットを作ったりしないでください。
   • 利用可能な場合は、既存のコンポーネント、トークン、フォント、アイコンセット、チャートライブラリ、ルーティング、状態管理のパターンを使います。
   • リポジトリに利用できるデザインの出典がない場合、またはユーザーが再デザインを依頼した場合に限り、新しいビジュアル表現を追加します。

6. 最終納品前にビジュアルを確認する

   • references/codex-verification.md を読み込みます。
   • 可能であればアプリを実行するか、成果物を開きます。
   • ブラウザツールを利用できる場合は、デスクトップとモバイルのスクリーンショットを撮影します。
   • レンダリング結果をビジュアルの契約に照らして批評し、目に見える問題を修正してから最終回答を返します。

コア原則

• 画面を最優先します。ビジュアルスタイルは画面の役割に合わせます。
• トークンを最優先します。DESIGN.md またはデザイントークンが存在する場合、それをデザインの信頼できる情報源とします。
• 装飾より製品の実証を重視します。実際の製品 UI、実際のメディア、実際のデータ状態、または明示的なプレースホルダーを使用します。div で作った偽のスクリーンショットは避けます。
• 密度は使用頻度に合わせます。毎日使うツールでは素早く情報を確認できることが重要です。公開ページでは、提供価値とその裏付けを明確にします。
• CRUD の閲覧と CRUD の作成は、異なる操作モードです。インライン入力が製品の中核的な動作でない限り、主要なテーブルやリストの横または下に、常時表示される作成フォームを配置しないでください。
• 1 つの画面には 1 つのビジュアルシステムを使用します。無関係な配色、アイコンファミリー、角丸、シャドウ、タイポグラフィのトーンを混在させないでください。
• 根拠のない汎用的なデフォルトは禁止します。デフォルトの紫色のグラデーション、装飾的なカード、架空の指標、入れ子のカード、曖昧な文言、テキストが見えないボタン、説明のない大きな余白は、仕様上の正当な理由がない限り使用しません。
• 検証も作業の一部です。テキストの重なり、モバイル表示の崩れ、読みにくいグラフ、コントラスト不足のボタン、仕様と矛盾するデザインがある状態で完了にしないでください。

リファレンスの参照方法

• DESIGN.md が存在する場合、ユーザーが DESIGN.md に言及した場合、再利用可能なデザインシステムを作成する場合、または広範な再デザインに永続的なビジュアルルールが必要な場合は、references/design-md-protocol.md を読み込みます。
• 画面の分類と必要な UI の動作については、references/surface-contracts.md を読み込みます。
• ビジュアルリファレンスのファミリーを選ぶ場合、またはユーザーがインスピレーションとして製品やブランドを指定した場合は、references/reference-families.md を読み込みます。
• ビジュアル UI の実装またはレビューを完了する前に、references/codex-verification.md を読み込みます。

出力に関する規律

• 大規模な UI 作業では、コードを編集する前にビジュアルコントラクトを提示します。
• 実装中のユーザーへの進捗報告は、短く、コントラクトに沿った内容にします。
• 最終回答では、主な UI の変更、実施した検証、実行できなかった確認事項を報告します。