Communitygithub.com

unslop-components

アプリUIをフォームやテーブル、KPIカードの羅列から解放し、データの形状に基づいたクリエイティブでドメイン固有のコンポーネントを採用するためのスキルです。

unslop-components とは?

このスキルは、AIエージェントが生成するアプリケーションUIが、画一的な「管理画面テンプレート」にならないようにするためのガイドラインとプロセスを提供します。従来のテーブル、カードグリッド、統計タイル、フォームフィールドといったデフォルトのUIを禁止し、代わりにデータの形状(ルートマップ、ストリップ、レーン、マトリックス、タイムライン、グラフ、ストリームなど)に合わせたシグネチャコンポーネントを1画面につき1つ定義することを推奨します。Claude Code、Cursor、CodexなどのAIエージェントがアプリ画面を構築する際に、まず`unslop-foundation`(カラーパレット、アイコンスタイル、イラストシステム、モーション言語)を基盤とし、このスキルのプロセスに従うことで、記憶に残る、ドメイン固有のUIを実現します。さらに、ステータス表示には色だけでなく形状や塗りの2つのチャネルを使うこと、デフォルトは読み取り専用で編集はワンクリック奥に配置すること、Playwright MCPを用いて実際にスクリーンショットを確認しながらデザインすることなど、実践的な品質チェック(ゲート)が含まれています。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/anfrageozmarketing/unslopUI/tree/HEAD/skills/unslop-components

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

unslop-components は何をしますか?

AIが生成したアプリは、どれも同じシルエットを共有しています:ページタイトル、4つのKPIカードの行、テーブル、ドロップダウン付きのフォーム。それは正しく、そして忘れられます。コンポーネントは、コンポーネントライブラリが提供するものではなく、データが何であるかによって形作られるべきです。

最初に基盤(unslop-foundation)を築いてください:パレットトークン、アイコンスタイル、イラストシステム、モーション言語、そして承認済みコンポーネントシート。ここでのコンポーネントはそれらのトークンと部品を使用します。色やスタイルを独自に発明してはいけません。

禁止リスト(デフォルトの見た目)

まずコンポーネントで考えてください:プロダクトの構成要素に名前を付け、それらを構築してレビューし、それから画面を構成します。データが本当にそうである場合を除き、メインコンテンツが以下のいずれかである画面を出荷してはいけません:

  • 境界線やヘアラインで区切られた行やグループ(スペースとトーンで区切ること)
  • ラベル付きフォーム(フィールドのグリッド+保存ボタン)を編集手段として使用すること(代わりにunslop-foundation/references/designer-standard.mdの編集パターンを使用すること)
  • KPI/統計カードの行(1文で表現するか、数値をそれが測定するものの中に表示すること)
  • セル内に編集用ドロップダウンがあるテーブル(テーブルは多くの行の多くの属性を比較するためのもの)
  • 同一カードの均一なグリッド
  • プライマリーインターフェースとしてのフォーム(フォームはデータを入力するためのものであり、データを見るためのものではない)
  • ステータスを色付きテキストや名前だけのピルで表現すること(ステータスに形状を与えること、下記参照)
  • 進捗の円グラフ、ゲージ、装飾としてのドーナツリング

プロセス(画面ごと)

  1. データの形状に名前を付ける。 シーケンス/旅程、全体の部分、比較、関係性、経時変化、ランキング、位置、階層、または注意を要するもののストリーム。
  2. 形状に合った形式を references/patterns.md から選ぶ。「この画面はルートマップである。なぜならデータがエリアごとの順序付けられたフローだから」と1行書く。
  3. 画面ごとに1つのシグネチャコンポーネントを定義する。 ユーザーが覚えているであろうもの。それが豊かさを担い、その周りのすべては控えめなテキストと細い線にする。
  4. ステータスに視覚言語を与える。 少なくとも2つのチャネル(形状/塗りと色、色だけではない)を使用し、すべての画面で同じように使う。
  5. まず表示し、次に編集する。 デフォルトビューは読み取り優先。編集はワンクリック奥(詳細ブロック、ドロワー、詳細ページ)にあり、すべての行にあるわけではない。
  6. コントロールよりも直接操作。 凡例でもあるフィルター。「表示」ボタンの代わりにそのものをクリック。ドラッグは、ドロップダウンをより高速なものに置き換える場合のみ。
  7. 密度に変化をつける。 1つの大きな瞬間、静かな中間、小さな補足的な詳細。5つの等しいボックスではない。
  8. 下記のゲートに対してチェックする。

ゲート

  • 画面のメイン要素がテーブル、カードグリッド、統計行、フォームのいずれでもないこと。
  • 選択したコンポーネントをデータの形状に結びつける1行の理由があること。
  • ステータスが形状/塗りと色を使用し、画面間で一貫していること。
  • 読み取り優先:クリックなしで表示されるドロップダウンや入力がほんのわずかしかないこと。
  • コンポーネントが360pxでも機能し(意図的に折り返し、スタック、スクロール)、キーボードで到達可能でフォーカスが可視であること。
  • 動きの抑制が尊重されていること。装飾のためにアニメーションするものがないこと。
  • あなたがそれを見たこと: Playwright MCP(claude mcp add playwright npx @playwright/mcp@latest)を使用して360pxと1280pxでスクリーンショットを撮影していること。見ることができなかった場合はその旨を述べること。コードだけで画面をクリエイティブまたは完成したと呼んではいけません。

テーブルが正しい場合

多数の行、多数の比較可能な列、並べ替えが重要な場合(監査ログ、価格表、エクスポート)。その場合はテーブルをデザインします:表組みの数字、整列した列、控えめな罫線、行のホバー、ゼブラストライプやボックス化されたセルはなし、セル内のコントロールもなし。

ファイル

  • references/patterns.md - データ形状からコンポーネントカタログ、ステータス言語、実例(製品フローのルートマップ)

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

関連スキル