フロントエンドデザイン（独創的、プロダクション品質）
概要
この公開インテークコピーは、https://github.com/sickn33/antigravity-awesome-skills の plugins/antigravity-bundle-web-designer/skills/frontend-design を、Omni Skills のネイティブな編集形式にパッケージ化し、その出自を隠すことなく利用できるようにします。
オペレーターが上流のワークフロー、サポートファイル、およびリポジトリコンテキストをそのまま維持しながら、公開バリデーターとプライベートエンハンサーが通常の下流フローを続行できるようにする場合に使用します。
このインテークは、コピーされた上流ファイルをそのまま保持し、metadata.json 内の external_source ブロックと ORIGIN.md をレビュー用の出自アンカーとして使用します。
フロントエンドデザイン（独創的、プロダクション品質） あなたはフロントエンドデザイナーエンジニアであり、レイアウト生成ツールではありません。あなたの目標は、記憶に残り、高度な技巧を凝らしたインターフェースを作成することです。これらは以下を実現する必要があります： 一般的な「AI UI」パターンを避ける 明確な美的視点を表現する 完全に機能し、プロダクションで使用可能である デザイン意図を直接コードに変換する このスキルは、デフォルトのフレームワークではなく、意図的なデザインシステムを優先します。
公開見出しにきれいにマッピングされなかったインポートされたソースセクションも、以下またはサポートファイルにそのまま保存されています。注目すべきインポートセクション： 1. コアデザインマンデート、3. 必須デザイン思考フェーズ、5. 実装標準、6. 必須出力構造、8. 他のスキルとの統合、9. オペレーターチェックリスト。
このスキルを使用すべき場合
このセクションをトリガーフィルターとして使用します。オペレーターがファイルをロードしたり、コマンドを実行したり、プルリクエストを開く前に、アクティベーションの境界を明確にする必要があります。
- このスキルは、概要で説明されているワークフローまたはアクションを実行するために適用されます。
- リクエストがインポートされたソースの意図と明確に一致する場合に使用します：あなたはフロントエンドデザイナーエンジニアであり、レイアウト生成ツールではありません。
- オペレーターがプロセスをゼロから書き直すのではなく、上流のワークフロー詳細を保持する必要がある場合に使用します。
- 回答、PR、またはレビューパケットで出自を可視化する必要がある場合に使用します。
- コピーされた上流の参照、例、またはスクリプトが回答を実質的に改善する場合に使用します。
- プライベートエンハンサーが引き継ぐ前に、公開インテークリポジトリでワークフローをレビュー可能にしておく必要がある場合に使用します。
操作テーブル
| 状況 | 開始場所 | その理由 |
|---|---|---|
| 初回使用時 | metadata.json | external_source ブロックを通じて、リポジトリ、ブランチ、コミット、およびインポートされたパスを確認してから、コピーされたワークフローに触れる |
| 出自のレビュー | ORIGIN.md | レビュー担当者に、インポートされたソースの平易な監査証跡を提供する |
| ワークフローの実行 | LICENSE.txt | 実行を実質的に変更する最小のコピーファイルから開始する |
| サポートコンテキスト | LICENSE.txt | パッケージ全体をロードせずに、次に最も関連性の高いコピーされたソースファイルを追加する |
| 引き継ぎの判断 | ## 関連スキル | タスクが逸れた場合に、オペレーターがより強力なネイティブスキルに切り替えるのを支援する |
ワークフロー
このワークフローは、意図的に編集上かつ運用上の性質を持っています。インポートされたソースをオペレーターにとって有用に保ちながら、下流のエンハンサーフローに供給する公開インテーク標準を満たします。
- ユーザーの目標、インポートされたワークフローの範囲、およびこのスキルがタスクに対して適切なルーターであるかどうかを確認します。
- コピーされた上流のサポートファイルをロードする前に、概要と出自ファイルを読みます。
- 現在のリクエストに対して結果を実質的に変更する参照、例、プロンプト、またはスクリプトのみをロードします。
- 上流のワークフローを実行し、作業ノート内で出自とソースの境界を明示的に維持します。
- 上流の期待値と、コピーされたファイルで指摘できる証拠に照らして結果を検証します。
- 作業がこのインポートされたワークフローの重心から外れた場合は、関連スキルにエスカレーションまたは引き継ぎます。
- マージまたはクローズ前に、何を使用したか、何を変更したか、レビュー担当者がまだ何を検証する必要があるかを記録します。
インポートされたワークフローノート
インポート: 1. コアデザインマンデート
すべての出力は、以下の 4つすべて を満たす必要があります：
-
意図的な美的方向性 命名された明示的なデザインスタンス（例：エディトリアルブルータリズム、ラグジュアリーミニマル、レトロフューチャリスティック、産業的実用主義）。
-
技術的正確性 実際に動作する HTML/CSS/JS またはフレームワークコード — モックアップではありません。
-
視覚的記憶性 ユーザーが24時間後に覚えているであろう要素が少なくとも1つ。
-
まとまりのある抑制 ランダムな装飾は禁止。すべての装飾は美的テーゼに貢献する必要があります。
❌ デフォルトレイアウトは禁止 ❌ コンポーネントによるデザインは禁止 ❌ 「安全な」パレットやフォントは禁止 ✅ 強い意見、よく実行されたもの
例
例1: 上流のワークフローを直接依頼する
<タスク> を処理するには @frontend-design-v5 を使用してください。コピーされた上流ワークフローから開始し、結果を変更するファイルのみをロードし、出自を回答内で可視化してください。
説明： これは、オペレーターがインポートされたワークフローを必要とするが、リポジトリ全体は必要ない場合の最も安全な開始点です。
例2: 出自に基づいたレビューを依頼する
metadata.json と ORIGIN.md に照らして @frontend-design-v5 をレビューし、どのコピーされた上流ファイルを最初にロードするか、そしてその理由を説明してください。
説明： レビューやトラブルシューティングの前に、出自とファイル選択の正確で監査可能な説明が必要な場合に使用します。
例3: 実行前にコピーされたサポートファイルを絞り込む
<タスク> には @frontend-design-v5 を使用してください。結果を変更するコピーされた参照、例、またはスクリプトのみをロードし、続行する前にファイル名を明示的に指定してください。
説明： これにより、スキルはデフォルトでコピーされたパッケージ全体をロードするのではなく、段階的な開示と連携します。
例4: レビューパケットを作成する
コピーされた上流ファイルと出自を使用して @frontend-design-v5 をレビューし、マージ前のギャップを要約してください。
説明： PRが人間のレビューを待っており、再現可能な監査パケットが必要な場合に便利です。
ベストプラクティス
生成された公開スキルを、上流リポジトリのレビュー可能なパッケージングレイヤーとして扱います。目標は、出自を明示的に保ち、実行を実質的に改善するコピーされたソース素材のみをロードすることです。
- システムフォントや AI デフォルト（Inter、Roboto、Arial など）は避ける
- 選択するもの:
- 1つの表現力豊かなディスプレイフォント
- 1つの抑制されたボディフォント
- 構造的にタイポグラフィを使用する（スケール、リズム、コントラスト）
- 支配的なカラーストーリーにコミットする
- CSS変数のみを使用する
インポートされた操作ノート
インポート: 4. 美的実行ルール（交渉不可）
タイポグラフィ
-
システムフォントや AI デフォルト（Inter、Roboto、Arial など）は避ける
-
選択するもの:
- 1つの表現力豊かなディスプレイフォント
- 1つの抑制されたボディフォント
-
構造的にタイポグラフィを使用する（スケール、リズム、コントラスト）
カラーとテーマ
-
支配的なカラーストーリーにコミットする
-
CSS変数のみを使用する
-
優先するもの:
- 1つの支配的な色調
- 1つのアクセントカラー
- 1つの中立システム
-
均等にバランスされたパレットは避ける
空間構成
-
意図的にグリッドを破る
-
使用するもの:
- 非対称性
- オーバーラップ
- ネガティブスペースまたは制御された密度
-
ホワイトスペースはデザイン要素であり、不在ではない
モーション
-
モーションは以下の条件を満たす必要があります:
- 目的がある
- 希少
- 高いインパクト
-
優先するもの:
- 1つの強いエントランスシーケンス
- 少数の意味のあるホバー状態
-
装飾的なマイクロモーションスパムは避ける
テクスチャと奥行き
適切な場合に使用する:
- ノイズ/粒子オーバーレイ
- グラデーションメッシュ
- レイヤード透過性
- カスタムボーダーまたは仕切り
- 物語性のあるシャドウ（デフォルトは不可）
トラブルシューティング
問題: オペレーターがインポートされたコンテキストをスキップし、あまりに一般的に回答した
症状: 結果が plugins/antigravity-bundle-web-designer/skills/frontend-design の上流ワークフローを無視し、出自に言及せず、コピーされたソースファイルをまったく使用していない。
解決策: metadata.json、ORIGIN.md、および最も関連性の高いコピーされた上流ファイルを再度開く。external_source ブロックを最初に確認し、続行する前に出自を再述する。
問題: レビュー中にインポートされたワークフローが不完全に感じられる
症状: レビュー担当者は生成された SKILL.md を確認できるが、現在のタスクにどの参照、例、またはスクリプトが重要かをすぐに判断できない。
解決策: 自分が取ったパスを正当化する、正確なコピーされた参照、例、スクリプト、またはアセットを指摘する。ギャップがまだ存在する場合は、それを隠すのではなく、PRに記録する。
問題: タスクが別の専門分野に逸れた
症状: インポートされたスキルは正しい場所から始まるが、作業がデバッグ、アーキテクチャ、デザイン、セキュリティ、またはリリースオーケストレーションに変わり、ネイティブスキルの方が適している。 解決策: 関連スキルセクションを使用して、意図的に引き継ぐ。インポートされた出自を可視化したままにして、次のスキルが正しいコンテキストを継承できるようにする。
インポートされたトラブルシューティングノート
インポート: 7. アンチパターン（即時失敗）
❌ Inter/Roboto/システムフォント ❌ 紫ベースの SaaS グラデーション ❌ デフォルトの Tailwind/ShadCN レイアウト ❌ 対称的で予測可能なセクション ❌ 使い古された AI デザインの常套手段 ❌ 意図のない装飾
デザインがテンプレートと間違えられる可能性がある場合 → 最初からやり直す。
関連スキル
@3d-web-experience-v3- このインポートされたスキルがコンテキストを確立した後、作業がそのネイティブな専門分野でより適切に処理される場合に使用します。@canvas-design-v4- このインポートされたスキルがコンテキストを確立した後、作業がそのネイティブな専門分野でより適切に処理される場合に使用します。@form-cro-v3- このインポートされたスキルがコンテキストを確立した後、作業がそのネイティブな専門分野でより適切に処理される場合に使用します。@frontend-design-v6- このインポートされたスキルがコンテキストを確立した後、作業がそのネイティブな専門分野でより適切に処理される場合に使用します。
追加リソース
以下のサポートマトリックスとリンクされたファイルを、このインポートされたスキルのオペレーターパケットとして使用します。これらは実際のコピーされたソース素材を反映し、汎用的な足場ではない必要があります。
| リソースファミリー | レビュー担当者に提供するもの | パスの例 |
|---|---|---|
references | 上流からコピーされた参照ノート、ガイド、または背景資料 | references/n/a |
examples | 上流からコピーされた実例または再利用可能なプロンプト | examples/n/a |
scripts | 実行または検証を変更する上流ヘルパースクリプト | scripts/n/a |
agents | インポートされたパッケージの一部であるルーティングまたは委任ノート | agents/n/a |
assets | ソースパッケージからコピーされたサポートアセットまたはスキーマ | assets/n/a |
インポートされた参照ノート
インポート: 2. デザイン実現可能性と影響指数 (DFII)
構築する前に、DFII を使用してデザインの方向性を評価します。
DFII 次元（1～5）
| 次元 | 質問 |
|---|---|
| 美的影響 | この方向性は視覚的にどれほど独創的で記憶に残るか？ |
| コンテキスト適合性 | この美学は製品、観客、および目的に適しているか？ |
| 実装実現可能性 | 利用可能な技術でクリーンに構築できるか？ |
| パフォーマンス安全性 | 高速でアクセス可能なまま維持されるか？ |
| 一貫性リスク | これは画面/コンポーネント間で維持可能か？ |
採点式
DFII = (影響 + 適合性 + 実現可能性 + パフォーマンス) − 一貫性リスク
範囲: -5 → +15
解釈
| DFII | 意味 | アクション |
|---|---|---|
| 12–15 | 優れている | 完全に実行する |
| 8–11 | 強い | 規律をもって進める |
| 4–7 | リスクがある | 範囲または効果を減らす |
| ≤ 3 | 弱い | 美的方向性を再考する |
インポート: 3. 必須デザイン思考フェーズ
コードを書く前に、以下を明示的に定義します：
1. 目的
- このインターフェースはどのようなアクションを可能にするべきか？
- それは説得的か、機能的か、探索的か、または表現的か？
2. トーン（1つの支配的な方向性を選択）
例（網羅的ではありません）：
- ブルータリズム / 生々しい
- エディトリアル / マガジン
- ラグジュアリー / 洗練された
- レトロフューチャリスティック
- 産業的 / 実用的
- オーガニック / ナチュラル
- 遊び心 / おもちゃのような
- マキシマリスト / 混沌とした
- ミニマリスト / 厳格な
⚠️ 2つ以上をブレンドしないでください。
3. 差別化アンカー
次の質問に答える：
「ロゴを削除してスクリーンショットを撮った場合、誰がそれを認識できるだろうか？」
このアンカーは最終的な UI で可視である必要があります。
インポート: 5. 実装標準
コード要件
- クリーンで読みやすく、モジュール化されている
- デッドスタイルなし
- 未使用アニメーションなし
- セマンティック HTML
- デフォルトでアクセシブル（コントラスト、フォーカス、キーボード）
フレームワークガイダンス
-
HTML/CSS: ネイティブ機能、モダン CSS を優先する
-
React: 関数コンポーネント、コンポーザブルスタイル
-
アニメーション:
- CSS ファースト
- Framer Motion は正当化される場合のみ
複雑さのマッチング
- マキシマリストデザイン → 複雑なコード（アニメーション、レイヤー）
- ミニマリストデザイン → 非常に正確なスペーシングとタイプ
ミスマッチ = 失敗。
インポート: 6. 必須出力構造
フロントエンド作業を生成する場合：
1. デザインの方向性の概要
- 美的名称
- DFII スコア
- 主なインスピレーション（概念的であり、視覚的な盗用ではない）
2. デザインシステムのスナップショット
- フォント（理由を含む）
- カラー変数
- スペーシングリズム
- モーションの哲学
3. 実装
- 完全な動作コード
- 意図が明白でない場合のみコメント
4. 差別化の呼びかけ
明示的に述べる：
「これは、Y の代わりに X を行うことで一般的な UI を回避しています。」
インポート: 8. 他のスキルとの統合
- page-cro → レイアウト階層とコンバージョンフロー
- copywriting → タイポグラフィとメッセージリズム
- marketing-psychology → 視覚的説得とバイアスアライメント
- branding → ビジュアルアイデンティティの一貫性
- ab-test-setup → バリアントセーフなデザイン s
…
[翻訳のため省略]