unslop-ui

unslop-ui

まずこれを読んでください。最もよくある誤解によって、すべてが台無しになるからです。

このスキルは、優れたデザインを提供するものではなく、特定の見た目を推奨するものでもありません。 役割は、2つに限定されています。サイトがAI生成だと受け取られる原因となる具体的な特徴を取り除き、モデルがデフォルトに頼りそうな場面で、プロジェクト固有の選択を意識的に行うよう促します。センス、ブランド、レイアウトの判断は、引き続きあなたに委ねられます。ガードレールはデザイナーではありません。

避けるべき罠（これがすべてです）

あらゆるアンチスロップの取り組みが陥る失敗は、あるデフォルトの見た目を別のものに置き換えてしまうことです。2024年に目立ったのは、暗いヒーローセクションの紫から青へのグラデーションでした。2026年に目立つのは、温かみのあるクリーム色の背景にセリフ体のディスプレイフォント（Instrument Serif、Fraunces）を合わせ、セージグリーンまたはフォレストグリーンをアクセントに使うスタイルです。これは現在のClaude／Anthropicのハウススタイルです。前者を後者に置き換えても、スロップをなくしたことにはなりません。時計をリセットしただけで、同じくらいすぐに見抜かれます。

そのため、このスキルではパレット、フォント、レイアウトを一切指定しません。指定すれば、来年のスロップになってしまうからです。代わりに行うのは、古いものも新しいものも含めたデフォルトを検出し、置き換えには、モデルが次に選びそうな推測ではなく、ユーザーやプロジェクトが実際に選んだ具体的な選択を求めることです。ここで唯一の普遍的なルールは「意識的に選び、その理由を説明できるようにすること」です。デフォルトがそうであることは決してありません。

ユーザーがブランド上の判断として、心から紫、ネオン、セリフ体、クリーム色の背景を望むなら、それはスロップではなく、このスキルは手を加えません。問題なのは、指定されていないデフォルトであって、禁止された色ではありません。意図して選んだものには、（Audit modeを参照して）unslop-ignoreを適用してください。

組み込みのfrontend-designスキルとの違い

Claudeにはすでにfrontend-designスキルがあり、優れたものですが、このスキルが現在目印として検出する、クリーム色＋セリフ体＋グリーンのハウススタイルを生成します。unslop-uiはそれを補完し、frontend-designスキルにはない3つの機能を追加します。CIで実行できる決定論的なスキャナー（終了コードでビルドを制御）、実際の苦情に基づいて取り組みの優先順位を決めるデータ重視のランキング、そしてスロップを別のスロップにすり替えないための、新たな「洗練されたデフォルト」に対する明示的なチェックです。両方を使ってください。デザインスキルに制作を任せ、このスキルで健全性を保ちましょう。

モード 1：構築（重要なモード）

「AIっぽく見える」仕上がりの大半は、スタイリングではなく仕様の問題です。指定のないプロンプトでは、学習データの中央値が出力され、誰の中央値も同じになります。そのため、UI を生成する前に、まず要件を定めてください。ユーザーから聞き出すか、要件が提示されていない場合は、どのような選択をするのか、その理由とともに明示してから進めます。何も言わずにデフォルトに頼ってはいけません。

具体的に、以下を決めます。

• 参考例。 デザイン言語の手本とする、実在のサイト、スクリーンショット、ブランド、または製品を 1 つ選びます。この情報 1 つで、他のルールをすべて合わせた以上の効果が得られます。ユーザーが参考例を持っている場合は、それを基準にします。なければ、ユーザーに尋ねるか、具体的な方向性（エディトリアル、ブルータリスト、実用性重視で情報量が多いデザイン、温かみのあるコンシューマー向け、テクニカルなモノトーンなど）を名前を挙げて選びます。「モダンでクリーン」は何も意味しないので使いません。
• 色の方針。 実際のブランドカラーか、意図的に選んだ色を明示します。フレームワークのデフォルトや、クリーム色／セージ色の定番も使いません。
• 書体の方針。 このプロジェクトに合わせた具体的な書体、または書体の組み合わせを、選んだ理由とともに決めます。自動的に選びがちな上位 50 の定番（サンセリフなら Inter、Geist、「趣味の良い」系なら Instrument Serif、Fraunces、Playfair）は、実際に意図して選んだ場合を除いて避けます。
• レイアウトの意図。 ページの目的と、ユーザーに最初に何をしてほしいかを決めます。これによって構成が決まります。こうすれば、ヒーロー＋3 枚のカードという定型を避けられます。構成はテンプレートではなく、目的に沿って決めます。

ユーザーが要件を示さず、ただ作ってほしいと言った場合、中央値のような仕上がりを 1 つ出すだけにしてはいけません。意図を持って 1 つ選び、その選択を伝えるか、実質的に異なる方向性を 2、3 案提示します。画一化を崩すことが大切なので、意識的に中心から外れた選択をします。

そのうえで、構築時には references/tells.md にある、具体的な兆候を避けてください。references/choosing-a-look.md は、色、書体、レイアウトを意図的に選ぶためのプロセスです。処方箋ではなく手法として書かれているのは、これが次のデフォルトにならないようにするためです。

モード 2：監査（ガードレール）

既存コードをレビューまたは整理する場合や、ユーザーから「これって AI っぽく見える？」「ダサさをなくして」「雰囲気だけでコーディングしたように見えないようにして」と言われた場合は、まずスキャナーを実行し、その後、優先度の高い順に修正します。

python3 scripts/devibe_scan.py <path>                 # full report + vibe score
python3 scripts/devibe_scan.py <path> --severity high # only the strongest signals
python3 scripts/devibe_scan.py <path> --json          # machine-readable, for CI

スキャナーは .html .css .scss .js .jsx .ts .tsx .vue .svelte .astro を検査し、検出項目ごとにファイル、行、修正方法を報告して、雰囲気スコアを出します。終了コードは重大度の高い項目数なので、CI のゲートとして使用できます。スキャナーが検出するのは、色、フォント、グラデーション、クリーム色＋セリフ体の組み合わせといった機械的な兆候です。レイアウトの一貫性、余白の統一感、テキストがコンテナからはみ出していないかは判断できません。しかし、これらもサイトが AI っぽく見える原因なので、スキャン後にカタログと照らし合わせて目視で確認してください。

意図的な選択を尊重する。 unslop-ignore コメントのある行はスキップされます。検出された値が実際に意図した選択である場合に使うと、監査の信頼性が保たれ、選んだブランドカラーについて不要な警告が出なくなります。

適切に修正する。 bg-purple-600 を bg-emerald-700 に置き換えてはいけません。それも別のデフォルトにすぎません。プロジェクトで実際に使う色を適用するか、どの色にするか確認して修正します。新たに指定のないデフォルトを持ち込むのは、修正ではありません。

意図的に検出対象から除外しているもの

雰囲気ではなくデータに基づいています。メッシュ、オーロラ、ブロブの背景は、実際の不満としてほとんど報告されません（大半はキーワードに起因するものです）。Bento グリッドとグラスモーフィズムの報告は少なく、評価も分かれています。ダークモード自体は問題ありません。兆候となるのは、求められていないグローだけです。shadcn と Tailwind 自体にも問題はありません。兆候となるのは、手を加えていないデフォルト設定です。過剰に検出すると、人々はツールを無視するようになるため、スキャナーの検出範囲は絞っています。

監査結果の報告

最初に判定と、最も影響の大きい変更を1つ示します。次に、優先度順にファイル名:行番号と修正内容を添えて指摘事項を示します。最後に、雰囲気スコアと変更点のトップ3をまとめます。簡潔かつ具体的に書きます。目指すのは、スキャナーにはできない、人が判断を下して作ったと感じられるサイトです。