Communitygithub.com

anti-ai-design — 36スタイルUIゲート(AIクロム排除)

汎用AI美学を遮断するクロスプラットフォームUIスキル。36スタイル、22禁止パターン、トークン固定のCJXバンドル。

anti-ai-design — 36スタイルUIゲート(AIクロム排除) とは?

Landing Pages手順2:anti-ai-design。Ship Page後にAIクロムを遮断し、seo-landingへ。

対応~Claude Code✓Codex CLI~Cursor
npx skills add huyhoangnhh98/anti-ai-design

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

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

ドキュメント

anti-ai-design

自動オーケストレーションによるUIデザインスキル。必須のアンチAIルールを適用し、ありふれたAI生成のような出力ではなく、不可能なほど美しく、視覚的に特徴的な画面を生成します。

使用するタイミング

以下のようなリクエストがあった場合に、このスキルを有効にしてください。

  • ランディングページ、ヒーローセクション、マーケティング画面
  • ダッシュボード、管理パネル、データリッチなインターフェース
  • モバイルアプリ画面(iOS、Android)、またはレスポンシブWeb UI
  • オンボーディングフロー、サインアップフォーム、プロダクトウォークスルー
  • コンポーネントライブラリやデザインシステムの画面
  • 「見た目を良くして」「これをリデザインして」「〜のUIを作成して」

譲れないインタラクション契約

デザイン出力を生成する前に、以下の3つの決定をこの順序で解決する必要があります。

  1. プラットフォーム範囲 — ユーザーに、どのプラットフォーム向けに生成するかを尋ねます:mobile、tablet、desktop。
    • 複数選択は許可されます。
    • ユーザーがmobileとdesktopのみを選択した場合、tabletは生成しないでください。
    • プラットフォームがすでに明示的かつ明白に述べられている場合は、それを言い換えて確認し、先に進みます。
  2. カラーディレクション — 以下の順序でブランドカラーの方向性を決定します。
    • ユーザーが正確な色を提供した場合は、それを使用します。
    • そうでなく、ユーザーがブランド/テーマの雰囲気を提供した場合は、2〜3の適切なパレットの方向性を提示し、選択を促します。
    • それ以外の場合は、プロダクトカテゴリに適合するパレットを自動選択し、自動選択されたことを明確に述べます。
  3. スタイルディレクション — 2〜3のスタイルオプションを提示し、ユーザーに選択してもらいます。

会話の中にすでに明白な回答が含まれている場合を除き、これらの決定をスキップしないでください。

実行モード

インタラクティブ(デフォルト)

  • 欠落している各選択肢を順番にユーザーに尋ねます:プラットフォーム → カラー → スタイル。
  • 次のフェーズに進む前に、ユーザーの応答を待ちます。
  • スタイルの方向性には、RECOMMENDEDラベルを付けたオプションカードを提示します。

非インタラクティブ

ユーザーが以下の場合に有効になります。

  • mode: non_interactive または同等のフラグを付けてスキルを呼び出した場合、
  • ワンショットのCLIコマンド、バックグラウンドのCodexジョブ、スクリプト化されたパイプラインを実行している場合、または
  • 事前の会話コンテキストなしでプロンプトを提供した場合(リクエストの前にチャットターンがない場合)。

自動選択ルール(この順序で適用):

  1. プラットフォーム — 指定がない場合は、デフォルトでdesktopにします。モバイルファーストのシグナル(モバイルアプリの説明、React Nativeの言及、「phone」コンテキスト)が存在する場合は、デフォルトでmobileにします。
  2. カラーディレクション — 代替案を提示せずに、検出されたプロジェクトタイプに最適なパレットを選択します。
  3. スタイルディレクション — このプロジェクトコンテキストの2〜3の候補スタイルから、RECOMMENDEDとマークされるものを選択します。オプションカードは提示しないでください。

生成前の必須出力ヘッダー(非インタラクティブのみ):

自動選択:
- プラットフォーム: [選択されたプラットフォーム]
- パレット: [パレット名] — プライマリ [16進数値]
- スタイル: [スタイル名] — [一行の雰囲気]
バンドル生成に進みます。

質問を明確にしないでください。オプションカードを提示しないでください。ヘッダーの後は、直接フェーズ3に進みます。

出力契約 — CJXバンドル、単一の疎なHTMLではない

デフォルトの出力は、単一の疎なHTMLファイルではなく、プロジェクトのバンドルディレクトリです。

<app-slug>-design/
  html/
    landing-page.html
    mobile-<screen>.html
    tablet-<screen>.html
    desktop-<screen>.html
  css/
    foundation.css
    shared.css
    landing-page.css
    mobile-<screen>.css
    tablet-<screen>.css
    desktop-<screen>.css
  js/
    app.js
    landing-page.js
    mobile-<screen>.js
    tablet-<screen>.js
    desktop-<screen>.js

バンドルルール

  • html/には、生成された画面/プラットフォームの組み合わせごとに1つのHTMLファイルが含まれます。
  • css/foundation.cssには、固定されたデザイントークンのみが含まれます。
  • css/shared.cssには、共有プリミティブ、ユーティリティ、モーション、ガラスレシピ、フォーカス状態、共通のレイアウトパターンが含まれます。
  • 画面固有のCSSは、画面固有のファイルに格納されます。
  • js/app.jsには、共有UIヘルパー、状態トグル、モックデータ処理、アクセシビリティセーフなインタラクションが含まれます。
  • 画面固有のJSは、必要な場合にのみ画面固有のファイルに格納されます。
  • ユーザーが後で単一ファイルのエクスポートを要求した場合は、自己完結型のHTMLエクスポートを追加で提供してもかまいませんが、デフォルトの契約はCJXバンドルです。

プラットフォームファイル命名規則

  • ランディングページはセマンティックなままにします:landing-page.html、landing-page.css、landing-page.js
  • アプリ画面はプラットフォームのプレフィックスを使用します。
    • mobile-<screen>.html
    • tablet-<screen>.html
    • desktop-<screen>.html
  • 選択されたプラットフォームのファイルのみを生成します。
  • ユーザーがmobileとdesktopを選択した場合、出力バンドルにtablet-*ファイルを含めてはいけません。

単一のレスポンシブHTMLではなく、なぜ別々のファイルなのか

デフォルトで別々のプラットフォームファイルを使用する理由は以下の通りです。

  • 各プラットフォームは、IA、ナビゲーション、密度、CTAの配置が実質的に異なる可能性があるため、
  • 各ターゲットが分離されていると、レビューと引き継ぎが容易になるため、
  • 画面の意図が明確な場合、CJX検証がより明確になるため、
  • デスクトップ/タブレット/モバイルでは、異なるブレークポイントだけでなく、異なる階層が必要になることが多いため。

単一のレスポンシブHTMLは、ユーザーが明示的に1ファイルでの配信を要求した場合にのみ許容されます。

サブスキルルーティング

現在のステップに必要なリファレンスファイルのみをロードします。一度にすべてのファイルをロードしないでください。

タスクロード詳細
デザインスタイル/アートディレクションの選択references/design-styles-catalog.md11カテゴリ、36スタイル
トレンド/アートパックの選択references/design-trends.md6トレンド、3アートディレクションパック
デザインレシピの適用references/design-recipes-catalog.md15の完全なデザインレシピ
プラットフォームレイアウトルールの適用references/platform-rules.mdMobile/iOS 26/Desktop/Tabletルール
ファンデーショントークンの固定と注入references/foundation-tokens.mdトークン固定手順とフォーマット
半径グラマーとネスト階層の強制references/radius-choreography.mdセマンティック半径ロール、ネストサーフェスルール、スタイルファミリ半径グラマー
UX / カスタマージャーニールールの適用references/ux-guidelines.mdUX強制、CJXパターン
モーションコレオグラフィーとインタラクション意図の強制references/motion-choreography.mdモーション目的、ホバーポリシー、状態遷移、プラットフォームモーションルール
バンドルアセット所有権とマニフェスト監査の強制references/output-bundle-rules.md共有対画面アセットルール、マニフェスト、自己監査
出力バンドルの生成references/output-template.mdバンドル構造、HTMLテンプレート、ファイル契約

自動オーケストレーションフロー

これらのフェーズを順番に実行します。各フェーズには条件付きロジックがあります。正確にそれに従ってください。

フェーズ1 — コンテキスト検出

  1. 会話と添付ファイルをスキャンして、プロジェクト名、既存のブランドカラー、フォント、テクノロジースタック、ターゲットプラットフォーム、画面の目的を特定します。

  2. プロジェクトタイプを以下のいずれかに分類します:SaaSプロダクト · 電子商取引 · モバイルアプリ · ポートフォリオ · ダッシュボード · マーケティングサイト · その他。

  3. 要求された画面を抽出し、その数を数えます。

  4. プラットフォーム範囲をmobile、tablet、desktopのうち1つ以上に解決します。

  5. プラットフォーム範囲が欠落している、または曖昧な場合: 複数選択可能な選択肢を含む、ちょうど1つのプラットフォーム選択質問をします。

    • モバイル
    • タブレット
    • デスクトップ
  6. ユーザーがすでにプラットフォームを指定している場合は、再質問せず、それらをそのまま引き継ぎます。

  7. プロジェクトで見つかった既存のブランドトークン(色、フォント、スペーシングスケール)をメモします。これらは後でトークンの固定に使用します。

  8. プロジェクトタイプに基づいてカラースキームの優先順位を解決します。

    ダークモードファースト(ダークがプライマリキャンバスで、ライトはオプションのオーバーライド):

    • ダッシュボード · 管理パネル · データ集約型SaaS · フィンテック · 開発者ツール · アナリティクス · モニタリング · 暗号/Web3 · メディア/ストリーミング · ゲーム

    ライトモードファースト(ライトがプライマリキャンバスで、ダークはオプションのオーバーライド):

    • 電子商取引 · マーケティングサイト · ポートフォリオ · ヘルスケア · 教育 · フード&ビバレッジ · ライフスタイル

    プロジェクトタイプが曖昧であるか、どちらのリストにも適合しない場合は、デフォルトでライトモードファーストとし、ダークモードをアドオンとして提供します。

    この決定をcolor_scheme_priority: dark_first | light_firstとして引き継ぎます。フェーズ2のパレットオプションとフェーズ4のトークン固定は、この優先順位を反映する必要があります。

フェーズ2 — カラー + デザインディレクション

  1. スタイル選択の前にカラーディレクションを解決します。

  2. ユーザーが明示的なパレットを提供しなかった場合は、プロダクトカテゴリに適合し、フェーズ1のcolor_scheme_priorityを反映した2〜3のパレットディレクションを提供します。

    • dark_firstプロジェクトの場合:ダークパレットオプション(例:OLEDダークラグジュアリー、エレクトリックスレート、ディープネイビー)でリードし、ライトオプションは最後の選択肢としてのみ含めます。
    • light_firstプロジェクトの場合:ライトパレットオプション(例:コマースウォームエナジー、トラストクールニュートラル)でリードし、ダークオプションはブランドに合う場合のみ含めます。
    • ユーザーに1つ選択するよう求めます。
  3. ユーザーが選択を拒否した場合は、最適なパレットを自動選択し、その理由を一文で述べます。

  4. references/design-styles-catalog.mdをロードします。

  5. カタログから、プロジェクトタイプ、選択されたパレット、およびコンテキストに最も一致する2〜3のスタイルを選択します。

  6. 選択された各スタイルについて、以下の形式でオプションカードを生成します。

    [N]. **スタイル名** — RECOMMENDED(該当する場合)
    雰囲気: [一行の雰囲気/ムード]
    主要な美学: [3つの特徴的な視覚特性]
    
  7. 最適な適合に基づいて、正確に1つのオプションをRECOMMENDEDとしてマークします。

  8. 番号付きリストをユーザーに提示し、選択を求めます。先に進む前にユーザーの応答を待ちます。

  9. ユーザーがリストにない別のスタイルを要求した場合は、それに対応して先に進みます。

フェーズ3 — バンドル生成

  1. 選択されたプラットフォームのreferences/platform-rules.mdをロードします。
  2. CJXバンドル形式のreferences/output-template.mdをロードします。
  3. アセット所有権、共有クラスの配置、マニフェスト、バンドル自己監査のためのreferences/output-bundle-rules.mdをロードします。
  4. CSSを記述する前に、半径グラマー、ネストサーフェス階層、ロールベースの曲率を解決するためにreferences/radius-choreography.mdをロードします。
  5. 最終出力を生成する際に、状態の完全性が必須であるため、references/ux-guidelines.mdをロードします。
  6. 以下のすべてのアンチAIデザインルールを適用します。
  7. 選択された各プラットフォームに、プラットフォームルールを個別に適用します。
  8. コンポーネントCSSを記述する前に、選択されたスタイルディレクションの半径グラマーを解決します。
    • 必要に応じてピルを含む、2〜4のプライマリ半径ティアを選択します。
    • それらをセマンティックロール(shell、surface、inset、control、tight、pill)にマッピングします。
    • バンドル全体で一貫したグラマーを維持します。
    • 同じ素材のネストサーフェスは、曲率が段階的に減少するようにします。
  9. 以下を含むバンドルディレクトリを生成します。
    • html/
    • css/
    • js/
    • manifest.json
  10. 必要な画面/プラットフォームの組み合わせごとに、1つのHTML/CSS/JSの3点セットを生成します。
  11. 要求された画面と選択されたプラットフォームのみを生成します。
  12. ランディングページは、同じファイルが適切に機能する場合はクロスプラットフォームのセマンティックのままにしてもかまいませんが、レイアウトがプラットフォームによって大きく変わる場合は、プラットフォーム固有のランディングバリアントも生成します。
  13. すべてのHTMLファイルは以下を行う必要があります。
    • ../css/foundation.cssを参照する
    • ../css/shared.cssを参照する
    • その画面のCSSファイルを参照する
    • 共有の../js/app.jsを参照する
    • 必要な場合はその画面のJSファイルを参照する
    • 主要な構造要素すべてにdata-ai-idを使用する
    • 文脈に沿ったリアリスティックなコピーを使用する(決してlorem ipsumを使用しない)
  14. 生成されたすべてのアプリ画面は、ux-guidelines.mdの4つのUX状態を含むか、明示的に処理する必要があります。
    • loading(読み込み中)
    • empty(空)
    • error(エラー)
    • success(成功)
  15. これらの状態は、メインキャンバスに表示されるか、JSコントロールを介してトグル可能なモック状態として実装される場合がありますが、出荷されるバンドルに存在する必要があります。
  16. デフォルトの表示状態を意図的に解決します。
    • ジェネレーター画面は、ユーザーが明示的にプリロード済み/デモ対応の成功キャンバスを要求した場合を除き、デフォルトでemptyにする必要があります。
    • 結果/レビュー画面は、ナラティブが明示的に別の状態を必要とする場合を除き、デフォルトでsuccessにする必要があります。
    • ユーザーが入力またはロードする前に、ジェネレーター画面が完了した出力を暗示してはなりません。
  17. ユーティリティ画面のリアリズムルールを、ジェネレーター、結果、ダッシュボード、フォームが主体の画面に適用します。
    • スペクタクルよりも、信頼性、スキャン容易性、およびアライメントのために最適化します。
    • プライマリフォーム、状態キャンバス、結果ボード、およびCTAグループは、安定したノーマルフローレイアウトに保ちます。
    • ユーティリティ画面のプライマリ構造として、オーバーラップまたは絶対配置されたコンテンツベアリングカードを使用しないでください。
    • デコラティブな非対称性は、タスクの明確さやCTAの発見可能性を弱めないように、二次的に保ちます。
    • ユーティリティ画面のヒーロータイポグラフィは、演劇的なラッピングに依存するのではなく、ターゲットビューポートで信頼性を持って読めるようにします。
  18. 出力が完了したことを宣言する前に、references/output-bundle-rules.mdからバンドル自己監査を実行します。
    • 2つ以上のHTMLファイルで再利用されているすべてのセレクターをshared.cssに移動します。
    • どのページも、兄弟ページのCSSファイルに依存して正しくレンダリングされないようにします。
    • 参照されるすべてのアセットが存在することを確認します。
    • manifest.jsonが生成されたファイルと完全に一致することを確認します。
    • 選択されていないプラットフォームのファイルが存在しないことを確認します。
    • 半径階層が選択されたセマンティックグラマーに従っており、ネストサーフェスが等しい半径のレイヤーにフラット化されていないことを確認します。
    • ユーティリティ画面が、ターゲットビューポートでレイアウトリアリズム監査に合格することを確認します。

フェーズ4 — ファウンデーショントークンの固定

  1. 最初に承認された画面を生成した後、正確なトークン値をcss/foundation.cssに抽出します。
  2. カラー/タイプ/モーションだけでなく、バンドルのセマンティック半径グラマーも固定します。
  3. 以下の正確な形式を使用します。
/* FROZEN FOUNDATION TOKENS — DO NOT MODIFY */
:root {
  --color-primary: <exact value>;
  --color-secondary: <exact value>;
  --color-accent: <exact value>;
  --color-bg: <exact value>;
  --color-surface: <exact value>;
  --color-text: <exact value>;
  --color-text-muted: <exact value>;
  --font-heading: <exact font stack>;
  --font-body: <exact font stack>;
  --space-base: <exact value>;
  --radius-1: <exact value>;
  --radius-2: <exact value>;
  --radius-3: <exact value>;
  --radius-4: <exact value>;
  --radi

…

[翻訳のために一部省略]

関連スキル