Communitygithub.com

WithZeng/design-skills

マーケティングサイト、ランディングページ、プロダクトホームページ、アプリのUIやログイン/サインアップページをエンドツーエンドでデザイン・構築します。ユーザーの承認を得たスクリーンショットと画像生成ドラフトを元に、統一されたページシステム、アートディレクションとモーションプラン、適切なコンポーネント・アニメーションライブラリ、i18n、アクセシビリティ/E2E検証を行います。

design-skills とは?

このスキルは、公式Webサイト、ランディングページ、アプリUI(ワークベンチ、チャット/エージェントUI、ダッシュボード、認証ページ)のデザイン、リデザイン、スタイル変更、またはブラッシュアップを依頼された際に使用します。まずユーザーからプロダクト概要、対象ユーザー、セクション、サンプルデータ、参考サイトを収集し、参考サイトがない場合は適切なギャラリーやUIライブラリから候補を提示します。**コード編集はドラフト承認後**という原則に従い、画像生成ツールで方向性、ページ全体、詳細セクション、サブページ、インタラクションのストーリーボードを順に作成し、その都度ユーザーの承認を得ます。承認されたドラフトのみを実装し、本番反映前にプレビュールートで検証します。ページの一体感を生む「ページシステム」(背景、セクションモジュール、タイプスケール、カラーパレットの統一)を徹底し、アートディレクションとモーションはプロジェクト固有の要件から導出します。また、豊かなインタラクションのためにコンポーネント・アニメーションライブラリを積極的に活用し、アクセシビリティ(コントラスト比4.5:1、reduced-motion対応)とE2Eテストを組み込みます。Claude Code、Coder、Cursor、CodexなどのAIエージェント向けに設計されており、`references/`ディレクトリ内の詳細ドキュメントと連携して動作します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/WithZeng/design-skills/tree/HEAD/skills/website-design

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

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

ドキュメント

Webサイトデザイン

Scientifyサイトリデザイン(2026年10月)から得た教訓:ドラフトを提示して承認を得てからでないとデザインは決まらず、すべてのセクションに単一のページシステムを適用し、モーションライブラリがもたらすコントラストやマークアップのバグを検証で発見できた。

ワークフローとゲート

  1. ブリーフィング。 プロダクト、対象ユーザー、セクション、実際のサンプルデータ、ユーザーが気に入っている1~2の参考サイトを収集する。参考サイトがない場合は、サイトタイプに合ったものをreferences/ui-references.md(ギャラリー、実際のプロダクトUIライブラリ、コンポーネントソース)から2~3選び、承認を得る。参考サイトはスクリーンショットを撮り、--ref画像として保存する。推奨を求められた場合は、番号付きスクリーンショットと2~3の組み合わせを提示して選んでもらう(方法:ui-references、「参考サイトのキャプチャ」)。
  2. コードの前にドラフト。 ユーザーがドラフトを承認するまで、ビジュアル変更のためのコード編集は決して行わない。image-genスキルを使用する。順序:
    1. 方向性が未確定の場合、方向性ごとに1枚の概要画像(通常2枚)。ユーザーが1つを選んでから詳細作業に入る。次に、フルページの長尺画像(1024x1536)1枚でページシステムを確定する。
    2. 各セクション/パネルの詳細画像をフル解像度で1枚ずつ。
    3. サブページ、次にインタラクションのストーリーボード(インタラクションあたり3~4コマ)をモーション用に。 各バッチを表示し、フィードバックを収集し、反復する。プロンプトテンプレート:references/draft-prompts.md。
  3. 構築 承認されたドラフトのみを、プレビュールートの背後で行い、ユーザーがライブページの差し替えを指示するまで公開しない。パターン:references/build-patterns.md。
  4. 検証 コミット/PRの前に必ず行う:references/verification.md。
  5. ドラフトとスクリーンショットはプロジェクトのgitignoreされたスクラッチフォルダ(例:tmp/design/vN/)にラウンドごとに保存し、プロンプトは画像の隣に保存する。

ページシステム(「割裂感」を排除したもの)

すべてのセクションが同じシステムを再利用するとき、ページはひとつのまとまりとして感じられる。承認されたドラフトからシステムの値を決定し、すべてのプロンプトとコードトークンに書き込む:

  • ページ全体で1つの背景処理。各セクションが独自のバンドやグラデーションを作り出すのを避ける。
  • 1つのセクションモジュール(コンテナ、角丸、塗りつぶし、境界線、パディング、幅)とその内部の少数のレイアウトセットを、セクションごとに再利用する。
  • 1つのタイプスケール:すべてのセクションタイトルで同じサイズとウェイト、1つのボディスタイル、一貫したスペーシング。
  • 1つのシグネチャー要素がアートディレクションを担う(通常はヒーローセクション)。それ以外はレイアウト上は控えめにするが、インタラクションには応答する。その要素が何かはテンプレートではなくブリーフから来る:下記「アートディレクション」を参照。
  • 表示されるすべてのプロダクトUIは同じアプリ(同じナビゲーション、テーマ、データ)であり、ページが1つのプロダクトとして読まれるようにする。
  • システムの一貫性を保つために十分に制限されたパレット(あるサイトは純粋なモノクロームを使用した)。ロゴは元の色を維持する。実際のブランドロゴを常に使用し、四角の中の文字プレースホルダーは決して使わない。
  • コンテンツ:プロダクトのドメインから得た現実的なデータ(もっともらしい名前、数字、タイミング)と、プロジェクトごとに決定されたファイルとオブジェクトの命名規則。ロレム・イプサム、偽の推薦文や統計、バズワードのスローガンは不使用。

アプリUIと認証ページ

同じゲートがプロダクト内部にも適用されるが、異なるリファレンスとトークンを使用する:

  • リファレンスは実際のプロダクトUI(例:Refero、類似プロダクトのサイトのスクリーンショット、チャット/エージェント画面のコンポーネントドキュメント)から取得し、ランディングページギャラリーからは取得しない。
  • アプリ自身のトークンとコンポーネントを再利用する。マーケティングサイトのパレットをインポートしない。まず少数の共有プリミティブ(パネル、ページコンテナ幅、ダイアログ幅、セグメントコントロール)を固定し、それを使って画面を再スタイルする。
  • ログイン/サインアップはホスト型認証ウィジェット(例:Clerk)を使用する:そのアピアランスAPIとローカライゼーションを通じてスタイルし、build-patterns(「認証ページ」)の落とし穴を確認する。

アートディレクション(立体感とモーション)

立体感と動きのある部分をサイト自身の要件からデザインし、他のビジュアルと同様にドラフトする。以前のサイトのレシピや固定値を再利用しない。

  1. ブリーフから導出する。 訪問者が得るべき1つのアイデア(動作中のプロダクト、変革、スケール、精度、静けさ)は何か?対象ユーザーは誰か、ブランドトーンは何か、どのデバイスとパフォーマンスバジェットか?シグネチャー要素はそのアイデアを、理想的には実際のプロダクトを使って示すべきである。
  2. ページシステムとトーンに合った2~3のオプションを探索する。 例:パースペクティブの中のプロダクトウィンドウ、パララックスによるレイヤー深度、ワークフローを語るスクロール駆動シーン、イラストや3Dオブジェクト、データ/ビジュアルメタファー、またはリッチなマイクロインタラクションを伴う静かなフラットページ。各オプションを画像として、モーションの場合はストーリーボードとしてドラフトする。ユーザーが選択する。
  3. 仕様化してから構築する。 選択されたオプションについて、何が動くか、何がトリガーか(ロード、スクロール、ポインター、時間、クリック)、静止状態、動きを減らしたバージョン、モバイルバージョンを書き留める。角度、タイミング、強度はテンプレートからではなく、承認されたドラフトをブラウザで調整する。
  4. コストを確認する。 可読性、コントラスト、レイアウト安定性、読み込み時間を損なわないこと。JSなしおよび動きの抑制設定下で優雅に低下すること。

ライブラリからの豊かなインタラクション

静的なページは安っぽく感じられる。コンポーネントとアニメーションライブラリを積極的に使用して、すべてのインタラクションを生き生きとさせる:

  • すべての状態にフィードバックがある:ホバー、プレス、フォーカス、ローディング/実行中、成功/エラー、出現/消失、レイアウト変更。これらをインタラクションストーリーボードで計画し、後付けにしない。
  • 手書きのエフェクトよりも、よく構築された既製のコンポーネントを優先する。各インタラクションをパターンにマッピングし、次にこのプロジェクトのために選択されたライブラリからコンポーネントを選ぶ(references/ui-references.md、「インタラクションパターン」)。
  • プロダクトデモは動く:実際のタスクが進行し、結果が到着し、数値が変化し、シーンが切り替わる。
  • 目的を持たせる:モーションは状態を説明するか、変更されたものに視線を向ける。重い装飾効果はマーケティングページに属し、ワーク画面には適さない。すべての場所で動きの抑制設定を尊重する。

ライブラリの選択

プロジェクトに合わせてコンポーネントとアニメーションライブラリを選択する。必須のものはない。

  • 既存のプロジェクト:すでに持っているものを使用する。不足を補う場合のみライブラリを追加し、既存のものと重複するライブラリは決して追加しない。
  • 新しいプロジェクト:プロジェクトタイプ、フレームワーク、ニーズに応じて選択する(基準と候補はreferences/build-patterns.mdの「ライブラリの選択」を参照)。明確な理由がない限り、1つのベースコンポーネントシステムと1つのメインアニメーションライブラリを維持する。
  • 不透明なパッケージよりも、プロジェクトに編集可能なソースとしてインストールできる(レジストリ/CLIまたはコピー)ソースを優先する。これにより、コンポーネントがプロジェクトのトークンに従うようになる。

苦労して得たルール(詳細はbuild-patternsに)

  • すべてのテキストトーンは、それが置かれているサーフェス上で4.5:1のコントラスト比を満たさなければならない。ページ背景だけでなく、パネルの塗りつぶし上の最も薄いトークンもチェックすること。
  • ファーストビューへのエントランスで不透明度フェードを使用しない。また、「非アクティブ」状態に不透明度の減衰を使用しない。アクセス監査はアニメーション中にトリガーされ、コントラストを指摘する。トランスフォームのみのエントランスと色変更を使用する。
  • アニメーションラッパーは<ul>/<ol>と<li>の間に配置してはならない。<li>の内部でアニメーションさせる。
  • スライディングピル:ラベルを絶対配置のピルの上にあるrelativeなspanに配置する。-z-10 + isolateは使用しない。
  • カウンターはサーバー上で最終値をレンダリングし、ビューポート内にある場合のみアニメーションさせる。
  • 多言語サイトでは、モックウィンドウ内のデモUIや再生されたセッションを含む、すべての可視文字列がi18nを通過する。
  • グリッドは明示的な単一カラム/minmax(0,1fr)トラックを必要とし、ページルートはモバイルのオーバーフローを避けるために水平オーバーフローをクリップする必要がある。

関連スキル