design-taste-frontend

tasteskill v2

モデルが作るページはたいてい、これまで見てきたあらゆるページの平均のようになります。中央揃えの見出しが3行にわたり、その上に小さなラベル、アイコンカードの列、淡いグラデーション、細い罫線が数本、等幅フォントのキャプション。どれも間違いではありませんが、どれも意図して選ばれたものではありません。

このスキルは、次の4つの方法で、そうした既定のスタイルを選択へと置き換えます。

1. スクリプトが方向性を提示し、そこから選べます。 見た目を考案するよう求められると、モデルはいつもカテゴリの既定のスタイルを選びます。scripts/draw.mjs は、調査に基づく20の方向性から3つを提示します。テーマのアイデアを最もよく伝えるものを選ぶと、スクリプトはさらに、実在する247のサイトから抽出したライブラリを使って、タイポグラフィシステム、配色、ヒーロー、セクションの構成を提示します。
2. アイデアはテーマそのものから生まれます。 調査で、優れたサイトと印象に残らないサイトを分けていたのは、スタイリングではなく、対象そのものから着想を得たコンセプトでした。
3. 装飾を省いたハウススタイルです。 実際のブラウザーで scripts/inspect.mjs によって計測し、ルールが守られているかを確認します。守られていることを期待するだけではありません。
4. 自分が作ったものを確認します。 3つの幅でスクリーンショットを撮り、審査員の評価基準で確認し、修正して、もう一度確認します。

テストでわかった注意点がひとつあります。装飾を取り除くのは仕事の半分にすぎません。ラベルや罫線、カードを取り除いても、代わりに何も加えなければ、ページは薄っぺらく見えます。目隠しをした審査員が、手がかりのある充実したページを、何もないページより高く評価するのは当然です。もう半分は中身です。大きめの文字、画面いっぱいに広がる色、本物の画像（見つけるか描くかした、このテーマの世界の写真）、そして各セクションを内容でしっかり満たすことです。このスキルはそれを実現するよう作られています。控えめにすることと引き換えにしないでください。

以下のコマンドでは、<skill> はこのスキルのフォルダーを指します。プロジェクトのルートから実行してください。作業ファイルはそこにある .taste-skill/ に配置されます。スクリプトの実行には Node 22+ と、インストール済みの Chrome、Edge、または Chromium が必要です。追加のものはインストールしません。assets.mjs にはネットワークアクセスも必要ですが、API キーは使いません。

ページまたはアプリ画面

まず、作業が次の2種類のどちらに当たるかを判断します。

• ページは、読んだりスクロールしたりするものです。ランディングページ、マーケティングサイトや製品サイト、ポートフォリオ、イベント、レストラン、1ページものなどが該当します。以下の一連の手順に従います。
• アプリ画面は、操作するものです。ダッシュボード、管理画面や分析画面、設定、請求画面、処理する受信トレイやキュー、ウォレット、フィルター付きリスト、エディター、ビルダーなどが該当します。references/app-screens.md に従います。独自の手順、独自の抽選（draw.mjs --app）、独自のハウスルール（控えめな境界線、小さなラベル、繰り返し使うパネルは通常どおりです。一方、グラデーション、グロー、色付きの四角形に入ったアイコン、虹色のグラフ、根拠のない見栄え重視の数値は使いません）、そして inspect.mjs --app を使います。始める前に、そのファイルを最後まで読んでください。以下のページ向け手順は適用されません。

アプリを紹介する製品サイトはページです。その中のインターフェース断片は、内部の表現にアプリ画面のルールを適用します。ページの色と書体はそのまま使い、アプリのスタイルを専用フォルダーで一度だけ決めます。

node <skill>/scripts/draw.mjs --app --kind <kind> --brief "<the product>" --keep palette,type --out .taste-skill/app

そして、ページに表示する断片（ヒーローの実際に操作できる画面、機能紹介の切り抜き、グラフ）をすべて、そのアプリの実物として作ります。パネル、テーブル、コントロールには assets/app.css、グラフには assets/charts.js を使い、合計が合う実データを用意し、ひとつの知見を明示します。また、ページの設計図で画像がどのように扱われているかに合わせて、切り抜きと拡大縮小を行います。実際に動く製品らしく見える断片は、ソフトウェアのページに載せる画像として最も効果的です。灰色のバーや意味のない数値は最も効果がありません。依頼に両方が含まれる場合（ランディングページと、その背後にあるダッシュボードなど）は、それぞれ独自の手順で作り、配色と書体は共通にします。

一連の手順

以下の順に実行してください。手順1〜5は数分で完了し、ページの出来を左右します。

1. 概要とプロジェクトを把握する

何が実在するのかを調べます。対象、読者、ページを見た人に必ずしてもらうこと、技術スタック、既存のブランド要素（色、フォント、ロゴ）、そして何よりも、実際に使える画像が何かを確認します。プロジェクト独自の写真や製品画像、掲載できる実際のインターフェース、呼び出せる画像生成ツールがあるのか、それとも何もないのかを把握してください。手元にない画像を前提に計画を立ててはいけません。独自の画像がなくても、使えるものが何もないとは限りません。対象の都市、通り、素材、歴史は、オープンアーカイブや博物館で公開されており、クレジットを記載すれば無料で使用できます（ステップ 6、scripts/assets.mjs）。

依頼内容が曖昧な場合は、質問するのではなく、解釈を一行で決めて明示してください。不足している情報によって作業が進められない場合（たとえば、製品名がない場合）に限り、質問します。

次に、メモの中で対象に固有の要素を洗い出します。このクライアントには当てはまり、競合には当てはまらないものを 8〜12 個挙げてください。名前とその意味、住所、番地、通り、近隣の様子、その場所の外観（タイル、看板、塗装の色、店先の書体、光、天気）、依頼にある数字（席数、部屋数、海までの所要時間、価格、年）、その事業を取り巻く制約（月に一度しか製造しない、冬季休業、予約制）、素材と色、習慣と営業時間（5 時に窯に火を入れる、7 時にフェリーが出る）、その世界にある印刷物（時刻表、ラベル、チケット、看板）に目を向けてください。このリストがステップ 4 のアイデアの源になります。ブラインドテストでは、各依頼で勝ったページは、こうしたリストの中の項目（クライアントの名前とその意味、その場所にある通り、その対象ならではの制約）をもとに作られていました。一方、負けたページは、構成は優れていても、カテゴリーにありがちな発想に頼っていました。このリストは画像検索にも役立ちます。そこにある場所、素材、印刷物はどれも、ステップ 6 で検索するためのキーワードになります。

2. 主張を組み立てる

デザインに取りかかる前に、references/copy.md §1 の例のように、ページの各セクションで伝える主張と、その根拠を一行ずつ書き出します。主張によって、どのセクションをどの順番で配置するかが決まります。主張のないセクションは削除してください。こうすることで、ヒーロー、ロゴ、3 つの特長、お客様の声、料金、行動喚起というお決まりの構成を避けられます。

3. 方向を引く

node <skill>/scripts/draw.mjs --sector <sector> --brief "<one line about the subject>" \
  --sections <roles in the order of your argument> [--tone <tone>] [--have <assets>] [--keep palette,type] \
  --options 3

3つの方向が提示され、それぞれの短い概要が表示されます。それぞれを手持ちの素材と照らし合わせてください。このクライアントにしかない何かを伝えられる構成はどれでしょうか？最も見慣れたものではなく、その方向を選び、理由をメモに一行書いてください。テストでは、題材に合わない方向をランダムに選んでしまうことが、弱いページになる最もよくある原因でした。続いて、シート全体を提示します。

node <skill>/scripts/draw.mjs <the same arguments, without --options> --direction <chosen id>

• --sector：node <skill>/scripts/draw.mjs --list sectors。最も近いものを選びます。
• --sections：--list roles の役割（features、showcase、how-it-works、testimonial、proof、stats、 pricing、faq、cta、footer、intro、about、work、gallery、list、contact）。ヒーローは自動的に含まれます。
• --tone（任意）：quiet、bold、warm、technical、playful、luxury、editorial。依頼で明確に指定されている場合にのみ渡します。
• --have：実際に存在する素材をカンマ区切りで指定します：photography（場所、人、制作物を撮影したプロジェクト独自の写真）、product-photo（特定の製品の写真、またはそれを作成できる画像ツール）、product-ui（実際のスクリーンショット）、illustration、video。何もない場合は省略してください。すると、それらに依存する構成は避けられ、シートには画像枠を正直に埋める方法が示されます（ソフトウェアはHTMLで組み立てた独自のインターフェースを表示し、写真のない製品は、実際の世界の写真の中に描画して配置します。製品写真を偽造することはありません）。オープンなコレクションで見つけた写真はプロジェクト独自のものではないため、--have には含めないでください。
• --keep palette,type：ブランドの色や書体がすでに決まっている場合に指定します。すると構成だけが提示され、ブランドの値を各役割に割り当てます。

コマンドは方向シートを出力します。これは、このビルドのアートディレクションです。

• 採用してください。 もともと作ろうとしていたレイアウトと混ぜないでください。見慣れないと感じるなら、それでよいのです。見慣れたレイアウトを防ぐために、このスキルが存在します。
• スロットを再抽選（--redraw hero | type | palette | photos | scenes | section:<role> | direction）するのは、理由を明確に説明できる場合だけにしてください。明示されたブランドの制約に反する、または存在しない素材が必要になる場合です。より安心できるものにするためだけに再抽選してはいけません。再抽選するたびに、レポートに記録してください。
• 引いたセクションでは実際のコンテンツを収められない場合（3つのプランを比較する構成なのに価格が1つしかない、5つの推薦文を求めているのに1つもないなど）、コンテンツを無理に合わせないでください。--alternatives <role> で他の候補を一覧表示し、コンテンツの前提に合うものを選び、--redraw section:<role>=<id> で採用してください。
• パレットが題材に合っているか確認してください。 引いたパレットは、色の組み合わせであると同時に、比率のセット（地色1色、文字色1色、アクセント1色、背景領域）でもあります。その色が題材自体の素材と衝突する場合（ピートウイスキーにキャンディのようなパステルカラー、山小屋にネオンカラーなど）は、パレットを一度再抽選してください。題材にそれ自体の明確な色がある場合（素材、通りに塗られた色、窓の外の風景など）は、引いた比率を維持して、色は題材から採用し、その理由をレポートに記してください。
• node <skill>/scripts/draw.mjs --show を使えば、いつでも再表示できます。長時間のセッションでは、各セクションを作成する前に読み直してください。

4. アイデアを見つける

方向性は、構成の方法です。アイデアは、そのページをこの題材ならではのものにする要素です。次の文をメモに書き、両方の空欄を題材そのものから埋めるまで、制作を始めないでください。

このページでは、**［題材ならではの何か］が、［方向性が求める仕掛け］**になります。

最初の空欄を埋める手がかり：

• その成果物。 それは何を生み出しますか？ 実際の成果物を素材としてページに載せます。（詩を印刷するカメラなら、印刷物を紙片として届けていました。）
• その物や形。 断面やシルエットで見ると、物理的にはどんな姿ですか？ 拡大したり、切り取ったり、フレームや唯一のモチーフにしたりします。
• その名前。 文字の中に写真を収めたり、壁のように積み重ねたり、2つの隅に分けたりできますか？
• その場所。 そこに行きたいと思わせる眺めはありますか？
• その儀式。 スクロールに合わせてページ上で展開できる一連の動作はありますか？
• その実物。 その世界にすでに存在する印刷物は何ですか？ チケット、メニュー、ラベル、レシート、招待状、フォルダー、マニュアルなどです。
• その対極。 その題材に欠けている感覚を持つのは、どの別カテゴリーですか？

最初の空欄は、カテゴリーではなく、棚卸しした情報（ステップ1）から埋めます。競合テスト： 最も近い実在の競合を文に当てはめます（2つ先の通りにある別のパン屋、別のオーク家具メーカー、同じ山にある別の山小屋など）。それでも文が成立するなら、そのアイデアはカテゴリー全般に当てはまります。パン一斤はどのパン屋にも当てはまりますが、この店の名前の由来になった通りにある7つのドアは、この店だけのものです。「すっきりしていてモダン」はアイデアではありません。調査の評価パネルが最も低く評価したサイトは、アイデアが「定番の型以外にはなし」と記録されたものでした。

動きのある要素を1つ。 アイデアをもとに、訪問者ができること、または訪問ごとに変わることを、ページに1つ用意します。木材を選ぶと、その木材を使った椅子が表示される。その人の名前を入力すると、鋳造所の書体で切り出されて表示される。ローン額を設定すると、実際の月々の返済額が表示される。山小屋のストーブが今点いているか、最終フェリーまであとどれくらいかがわかる。サイズを選ぶと、部屋に置いたときの見え方がわかる。ブラインドテストでは、勝ったページにはすべてこれが1つあり、審査員もまずそれに言及しました。ルールは次のとおりです。題材の実際の内容を使うこと、スマートフォンで親指を使って操作できること、スクリプトなしでもシンプルな代替表示があること、読書を妨げないこと、そして遊び場ではなく、要素は1つだけであること。これはステップ9で動きを追加するのではなく、ステップ6でページの一部として作ります。

シーンにもアイデアを反映させます。 シート上のスクロールシーンは、題材が決まるのを待つ仕掛けです。制作前に、棚卸しした情報をもとに各シーンで何を見せるか決めます。フライスルーではこのスタジオ独自のタイトルカードの中を通り抜ける。ルートではこの荷物が実際にたどる道を示す。全画面に広がる画像では、宿泊客が目を覚ます部屋を見せる。誰のものにもなり得る画像を並べたシーンは、スクリーンセーバーです。

5. 文章を作成する

マークアップする前に、references/copy.md に従って、ページ全体のコピーをプレーンテキストで作成します。

• すべての見出しは、どの画面幅でも2行以内に収めます。 文章を決める前に、copy.md §2 に従って文字数を計算してください。どの画面幅でも十分な文字サイズで表示できるのは、約32文字までです。調査したギャラリーのヒーロー見出しは、単語数の中央値が5語、文字数の中央値が32文字でした。
• 見出しのすぐ下（32〜48px下）に、それと一緒に表示する補足文を1文置きます。最初の画面の下部に固定したり、アニメーションで表示を遅らせたりしてはいけません。見出しが名前や比喩表現の場合、この文で対象が何なのかを明確に説明します。最初の画面には、何をするアクションなのかがわかる名前を付けた、実際に機能する主要ボタンを1つ置きます。
• 最初の画面では、訪問者が最初に抱く疑問に大きな文字で答えます。 イベントなら、どのようなイベントか、いつ、どこで開催されるかを示します（日付は見出しまたは2番目に大きい文字で示し、小さな文字だけで記載してはいけません）。製品なら、何であり、価格はいくらか、または何ができるかを示します。人物なら、誰で、何をしている人かを示します。訪問者が求めている各セクション（出演者、メニュー、部屋、料金など）には、それぞれ見出しとナビゲーション上の項目を設けます。
• コンテンツをすべて書きます。 ブリーフで求められている各セクションに、必要な情報を漏れなく記載します。メニューは価格も含めてすべて、部屋はそれぞれの詳細も含めてすべて、登壇者と講演もすべて、料金は含まれる内容も含めて記載し、実際に寄せられる質問には一つひとつ回答します。内容の薄いセクションがあるために、洗練されたページが情報量の多いページに負けることがよくあります。
• ブリーフに不足がある場合は、デザインの情報量を十分に示すため、具体例（料理名、部屋名と料金、プロジェクト名など）を補います。確認用として、これらをレポートに記載してください。実績を捏造してはいけません。顧客、引用、レビュー、報道、ロゴ、事業統計は作り上げないでください。

6. それでも、ページを構築する

アニメーションを使わない前提でページを構築します。完成して見せるためにアニメーションが必要なページは、まだ完成していません。作業の順序は次のとおりです。

1. トークン。 シートにある色とタイポグラフィの役割を、CSS カスタムプロパティとして定義します。それ以降はすべてトークンのみを参照します。<skill>/assets/base.css はニュートラルな基盤として利用できます（リセット、トークン名、可変フォントサイズの段階、グリッド、フォーカスと選択のスタイル、モーションヘルパーを含みます）。独自の見た目はありません。

2. 設計図に正確に沿ったヒーロー。 デスクトップ幅とスマートフォン幅の両方で作ります。ほかの要素を作る前に、大きなものは大きく、小さなものは小さくします。

3. 各セクションを、それぞれの設計図に沿って、プロジェクトのコンテンツで作ります。 形状は保ち、題材を変えます。隣り合うセクションで同じレイアウトを使ってはいけません。アイデアをすべてのセクションに引き継ぎます。 料金、FAQ、フッターも例外ではありません。調査で最もよく見られた失敗は、優れたサイトでさえ、最初の画面は独自性があるのに、その後がありきたりなブロックになることです。

4. 画像。 次の優先順位で選びます。

   1. プロジェクト独自のもの。
   2. 画像ツールがある場合は生成したもの。
   3. オープンコレクションにある、題材の世界を写した実際の画像。 誠実に使えるものがあれば、必ず活用します。node <skill>/scripts/assets.mjs "<query>" で検索します（Openverse、Wikimedia Commons、Art Institute of Chicago、Met。デフォルトでは商用利用が許可されたライセンスのみ）。カテゴリではなく、所蔵品を検索します。古い絵はがきに写るその街の通り、近隣の古地図、素材のクローズアップ、版画に描かれたその仕事、種類が同じ美術館の収蔵品、植物図譜、星図などです。意図を持って大きく使います。ヒーローにアーカイブ写真を一枚大きく配置する、版画を拡大してページのモチーフにする、問い合わせセクションにその通りの実際の地図を使う、といった方法があります。選ぶ前に一枚ずつ確認します。--get <ref> を実行すると画像が assets/ にダウンロードされ、出典とライセンスが記録されます。--credits を実行するとフッター用のクレジット行が出力されます。見つけた画像はクライアントを取り巻く世界を示すものであり、クライアント自身の商品、部屋、料理、人物、チームとして見せてはいけません。
   4. 題材そのものをもとにコードで描いたもの。 正直に使える画像が存在しないもの（その題材のオブジェクト、タイル、窓、製品のインターフェースなど）は、パレット本来の色を使った、統一感のあるフラットなグラフィック表現で作ります。
   5. シートに掲載された写真。ただし、海辺の家に海の写真を使う場合のように、一般的な写真を正直に使える場合に限ります。題材そのものの代わりとして使ってはいけません。
   6. タイポグラフィと色のみ。

   プロジェクトに独自の映像、または制作過程や製品を写した実際の画像がある場合は、最初の画面に大きく（画面の約40％以上）表示します。写真の出どころや、それが何ではないかについて、ページに説明文を書いてはいけません（「写真には当店のバーは写っていません」など）。キャプションには写真が何であるかを書き、クレジット行はフッターに小さく配置します。ブリーフに合わせて作品を創作するポートフォリオでは、各作品を完成済みの静止画として描きます（独自のタイポグラフィを使ったタイトルカード、エンドフレーム、ポスターなど）。実際の細部まで描き、クライアントの商品をピクトグラムで表したものにしてはいけません。

   最低ライン。インスペクターが確認します。 ページに実際の画像を最低4点、通常は6〜12点掲載します（写真、アーカイブ画像、地図、版画、映像、ラスターアート。ソフトウェアの場合は、切り抜いたインターフェースの断片も数に含めます）。SVG の描画は最低数に含まれません。画像が存在しないものは描きつつ、実際の画像も必ず掲載します。誠実に使える動画があれば、assets.mjs --video "<query>" で検索し、ポスターフレーム付きのミュートループとして使用します。モデルは画像や映像を探す作業を避けがちですが、それらがなければページは不合格です。 references/imagery.mdでは、画像の検索、ライセンスとクレジット、動画、描画、トリミング、加工について説明しています。

5. ライブ要素。 ステップ4で作成したものを、主張の裏付けとなるセクション（多くの場合、ヒーローや予約欄）に組み込みます。実際のコンテンツを用意し、親指サイズのスマートフォン版と、シンプルな代替表示も用意します。

6. スクロールシーン。 シートに指定されている場合（セクション9）、それぞれを担うセクションとともに組み込みます。ページの大きな見せ場、作品の中を飛び抜けるカメラ、画面全体に開く画像、スクロールに合わせて折れ曲がる言葉などです。共有ステージとシーンのファイルを<skill>/assets/scenes/からコピーし、このプロジェクト独自の画像と言葉でシーンを埋め、ページのトークンを設定してページの見た目に合わせます。シーンは構成そのものです。ページの長さと、各画面に表示されるものを決めるため、今の段階で組み込み、見た目を確認するたびにチェックします。最後に付け足すものではありません。シーンをページに配置し、内容を入れ、調整して確認する方法はreferences/scenes.mdに記載されています。それぞれの実例はassets/scenes/demo/<id>.htmlにあります。

7. 情報の充実度。 デスクトップの各画面をポスターとして見てください。主役がひとつあり、それがコンテンツを支えています。ほとんどが何もない背景の画面は、休息ではなく、作り込みが足りないセクションです。意図的な休息はページあたりひとつまでとし、空白に近い画面が2つ以上あるとインスペクターはページを不合格にします。本文は16px以上でインク色を使い、グレーは補足的な注記に使います。

8. フレーム。 ページの左右の外側余白は、どの画面幅でも同じ幅にします。各セクションは、ページで確保した幅を使います。テキストが左半分にあるなら、右半分には画像、第2カラム、リスト、または図を置き、何もない状態にはしません。非対称性はグリッドの内側に収め、フレームには持ち込まないでください。空白を置くのは、反対側に何かを配置して埋める場合だけです。ページ上に画面の約半分を超える高さにわたって何もない箇所を作らず、デスクトップでは各セクションの間隔を120〜240pxにします。訪問者が見に来た各セクションは、その内容を示す見出しで始め、最初の画面にはページタイトルをh1で表示します。ページの見た目に違和感があるとき、読者がまず指摘するのは「タイトルがはっきりしない」「空白が不自然」「すべてが片側に寄っている」といった点です。インスペクターはその一つひとつを測定します。

9. 状態とセマンティクス。 実際に機能するリンクとボタン、視認できるフォーカス、代替テキスト、独自の構成を持つスマートフォン向けレイアウトを用意します。

判断の詳細が必要な場合は、references/type.md、references/colour.md、references/layout.mdを読んでください。以下はその要点です。

7. ゲート

node <skill>/scripts/lint.mjs <source files or folder>
node <skill>/scripts/inspect.mjs <url or path/to/index.html>
node <skill>/scripts/scenes.mjs <url or path/to/index.html>     # when the page has scroll scenes

scenes.mjsは、各スクロールシーンの保持時間を0、10 … 100%として、デスクトップとスマートフォン、および動きを減らしたページを撮影します。シートにシーンがある場合、inspect.mjsはスクロール全体も撮影します（desktop-film-NN.jpg）。シーンが一度も始まらない、またはデスクトップで静止したままならFAILです。

lint.mjsはソースをスキャンし、禁止パターンと定型句を検出します。inspect.mjsは実際のブラウザーでページを1440、768、390ピクセルの幅で開き、見出しの行数、文字サイズ、実際に読み込まれたフォント、色、罫線、影、グラデーション、コントラスト、オーバーフロー、フレーム（左右の余白の均等さ、片側に固まったセクション、何もない広い領域、タイトル、タイトルのないセクション、画面端に接したテキスト）を測定し、スクリーンショットを.taste-skill/inspect/に保存します。すべてのFAILを修正してください。各WARNは、デザイナーに一文で説明できない限り、誤りとして扱ってください。FAILがなくなるまで再実行します。測定結果に異議を唱えたり、検出されないように隠したりしないでください。インスペクターは一時的なローカルサーバーを介してローカルファイルを配信します。ファイルシステムから直接ページを開く必要もある場合は、作業を終える前に一度その方法でindex.htmlを開いてください。

8. 確認する

ゲートを通過したということは、禁止されているものが何も計測されなかったというだけです。ページの出来が良いという意味ではありません。インスペクターが一覧に挙げたスクリーンショットをすべて開き（各ビューポートで、画像ビューアーまたは Read ツールを使います）、references/critique.md に従って評価します。14の評価項目、Awwwards の重み付けスコア、上限を確認してください。指定の形式で批評を書き留め、上位3つの問題を修正し、インスペクターを再実行して、もう一度確認します。最大3ラウンドまでです。

画像だけを基準に評価してください。スクリーンショットに問題が見えているなら、コードに何と書かれていようと、それは実際の問題です。

9. 動きを加える

ここでモーションレイヤーを構築します。これは必須であり、単なるフェード以上のものです。インスペクターは、ページの読み込み中やスクロール中に実際に動く要素を数え、8未満のページは失敗と判定します（16未満の場合は警告します）。スクロールシーンはすでに構築済みです（手順6）。それらを囲むレイヤーは、次の4つの要素で構成されます。

1. シートに記載されたシグネチャーとなる動き：1つだけ、丁寧に仕上げます（配られたシーンを使ってもかまいません）。
2. **すべてのセクションの各要素が登場する動き：**見出し、テキスト、画像の順に、60〜90msずつずらして、透明度を変えながら16〜32px上昇させます。セクションが画面に入ったときに一度だけ発動させます。ブロック全体を一度にフェードさせるのではなく、スクリプトが失敗してもコンテンツが非表示のままにならないようにしてください。
3. **すべてのコントロールへのフィードバック：**ボタン、リンク、カード、動作する要素に、押下時、ホバー時、フォーカス時の反応を加えます。
4. **動く画像を1つ：**見つけたクリップをミュート状態でループ再生する、写真をゆっくり拡大または移動させる、あるいはヒーロー画像をスクロールに連動させて動かします。

変化させるのは transform と opacity だけにします。すべての動きに、移動をなくしつつコンテンツは維持する prefers-reduced-motion の代替動作を用意します。画面全体の色やレイアウトを変える動き（章ごとの色の変化や、固定表示されるストーリーなど）は構成の一部です。そのため手順6で構築し、確認の各ラウンドで目に入るようにしてください。references/motion.md にトークンと、検証済みのレシピがあります。その後、インスペクターをもう一度実行し、すべてのスクリーンショットを確認して、表示されなかったコンテンツがないか確かめます。

10. 報告する

次のすべてを満たすまで報告しないでください。テスト実行では、これらの項目が省略された結果、良くない出来になりました。

• 最終版のページで inspect.mjs を実行し、1440、768、390の各幅で FAIL 0件と表示されていること。
• 最後の変更後に一覧に挙げられたスクリーンショットを、最初の画面だけでなくすべて開いていること。
• スクロールシーンがある場合、最終版のページで scenes.mjs を問題なく実行し、すべてのシート（デスクトップ、スマートフォン、モーション低減）を読んでいること。
• 初見の人が最初の画面を5秒見れば、これは何か、何をすればよいかを説明できること。
• すべてのセクションに見出しがあること。左右の余白が揃っていること。ページに何もない状態が続く箇所がないこと。
• 最後のラウンドの批評を、references/critique.md §4 の形式で書き留めていること。

ユーザーには簡潔に、次の内容を伝えてください。選ばれた方向性（名前とシード値）と、その理由を添えた再生成の有無。アイデアを表す一文と、動作する要素。最後の批評ラウンドの最終スコアと、まだ基準に届いていない点。見つけたすべての画像とクリップについて、タイトル、作者、ライセンス、出典ページ（assets.mjs --credits で一覧を出力できます）、およびページ上でクレジットを記載した位置。差し替え可能な、同梱写真と写真の代わりに使っているイラスト。公開前に差し替える必要のあるサンプルコンテンツ。実行していないチェックを実行したと主張してはいけません。

共通ルール

以下のルールは方向性にかかわらず、すべてのビルドに適用されます。inspect.mjs で計測されます。

ルール	代わりに
見出しは、どの画面幅でも2行以内にします。 すべての h1～h6 と、タグの種類を問わず最初の画面のメインの文言が対象です。	言葉を削ります。そのあとで行幅を広げます。サイズの調整は最後です。
最初の画面に明確なタイトルを置きます。 ページに1つだけある h1 にタイトルを入れ、各セクションに見出しを付けます。	何を紹介するのかを伝えます。名前とその機能、製品とその用途、イベントとその日時・場所を示します。
左右の外側余白を均等にし、片側にセクションが寄って、画面の反対側が空いたままにならないようにします。	空白の向こう側に何かを置いて埋めます。セクションの画像、2列目のカラム、リスト、図などを配置します。
画面の半分ほどを超える高さの空白を作りません。	通常のセクション間隔を使います。意図的に間を取る場合は、ページごとに1か所、配置を考えた画像か色面を使います。
主張は段落にします。 導入文や大きく表示する引用は <p> または <blockquote> でマークアップし、主張文のサイズ（デスクトップでは36px以下、スマートフォンでは24px以下）に保ち、約25語、3行程度に収めます。	それより大きなものは見出しなので、2行ルールを適用します。ブラインドテストでは、42pxの文が4行にわたると、審査員はそれを4行の見出しとして読みました。
見出しの上に小さなラベルを置きません。 見出しの上に小さなラベルやピル型バッジを置かず、「New ·」のチップも使いません。	情報を見出しか最初の文に入れるか、省きます。
実際のコードブロック以外では等幅フォントを使いません。	本文用の書体を使います。数字を揃える場合は、表形式の数字を使います。
通し番号を付けません。 01／02／03、（001）、「Step 2」は使いません。	順序は位置、サイズ、または言葉で示します。順序が重要な場合は、実際の <ol> を使います。
細い罫線を使いません。 極細の区切り線、1pxの枠線、グリッド線、十字線、トンボは使いません。	余白、背景色の明暗差、サイズの変化、塗りつぶした図形を使います。
グラデーションを使いません。 背景、ボタン、テキストのいずれにも使いません。	ベタ塗りの色か、実際の写真を使います。写真上のテキストの下に置く中立色のスクリーンは例外です。
静止している要素に影を付けません。 光彩も使いません。	面と面の明度差を使います。影は、メニューやダイアログなど、実際に浮かぶ要素だけに使います。
アシスタント風の配色を使いません。 黄みがかったクリーム色の背景にテラコッタやさび色を合わせず、バイオレットやインディゴも使いません。	指定された配色を使います。
小さく、大文字で、字間を広げたラベルを使いません。	読みやすいサイズで、文頭のみ大文字にします。
アイコンを上部に置いた機能カードや、同じカードを並べた列を使いません。	指定されたセクションの設計図を使います。
ガラス表現を使いません。 背景をぼかしたパネルや、浮遊するピル型ナビゲーションは使いません。	シンプルなバーに、ワードマーク、少数のリンク、1つのアクションを置きます。
絵文字、グラデーションのぼかし、装飾的な図形、灰色のバーで作った偽のダッシュボードを使いません。	実際の画像、実際のインターフェースの一部、または何も使わないようにします。
見出しの中で、アクセントとなる単語にスタイルを付けません（イタリック、セリフ体、色、下線など）。	文字の書体と色は統一します。強調は言葉そのものに任せます。
書体は最大2種類にし、通常は1種類にします。	指定されたタイポグラフィシステムを使います。

インスペクターの対象外となり、それぞれの規則を保つ場所が3つあります。<pre>／<code> 内の実際のコード（ここでは等幅フォントが適切です）、実際のテーブルとフォームフィールド（線を使ってもかまいません）、そしてルート要素に data-ui 属性がある実際のインターフェースの一部（製品独自の枠線やメニュー。「references/imagery.md」§7を参照）。

なぜこれらのルールなのか、率直に説明します。いくつかは調査で測定されたものです。247サイトのうち、パネルの評価が7.5以上のサイトでは、アイコン付き機能カードの使用率は1％で、6.5未満のサイトの28％に比べて低く、ピル型バッジは14％対34％、グラデーションは22％対52％、影は24％対48％、字間を広げた小さな大文字ラベルは16％対57％でした。それ以外はオーナーの好みで、現在のギャラリーの流行とは逆です。等幅フォントのラベル、通し番号、極細のグリッド線は、実際には評価の低いサイトより受賞サイトでよく使われています。だからこそ生成ツールがそれらを真似し、今では見せかけの演出に見えるのです。ここでは例外なく禁止します。日付入りの記録は references/tells.md にあります。 装飾を取り除くと、余白が生まれます。そこに別の装飾を足してはいけません。スケールを大きくする（主役を大きくする）、コンテンツを余すことなく配置する、この題材のために描いた画像を使う、またはベタ塗りの色面にします。意図的な空白は、1ページにつき多くても1か所にします。

デザインの法則

簡潔版。別途「独自スタイル」と記されていない数値は、調査に基づいています。

文字

• 見た目に使うサイズは2つか3つです。非常に大きなものを1つ、小さなものを1つ、その中間はありません。調査対象サイトの見出しと本文のサイズ比の中央値は4.3です。最良のサイトでははるかに大きく（上位サイトの最大文字サイズは中央値で8.4vw、低評価サイトでは5.0vw）、差がついています。
• ディスプレイ用書体：字間は-0.02～-0.05em、行送りは0.85～1.05。本文：16～20px、行送りは1.45～1.6、1行あたり45～75文字。
• 1ページに使うサイズは最大5つです。書体は1ファミリーが標準（調査対象サイトの3分の1）。2ファミリーまでが上限です。
• 基本は左揃えです。中央揃えは1か所までにします。

余白

• グリッドは1つ、狭いマージンは1組（16～32px）に統一し、全体で使います。大きな要素は端まで広げます。ページ全体で、テキストブロックの左端は2～3種類に揃えます。
• グリッド内では非対称にし、フレーム内では対称にします。左右の外側のマージンは同じ幅にし、中心からずれた見出しには、グリッドの反対側に要素を配置して応えます。
• セクション間の間隔は、セクション内のどの間隔よりも明らかに大きくします。デスクトップでは120～240pxです（調査での中央値は約240）。
• 各セクションの構成は隣り合うセクションと変え、カードグリッドは使いません。

色

• 背景色を1色、文字色を1色、アクセントカラーを1色にします。アクセントカラーはアクションに使い、使うとしても、ほかに1か所だけです。
• 本文は文字色をそのまま使います。ページ全体を柔らかなグレーでまとめると、未完成に見えます。
• 面の区別には、色調をわずかに変えます。線や影は使いません。
• セクション全体の背景色を変えることはできます。色が徐々に変化する表現は使いません。

画像

• 小さな画像を6枚使うより、主役となる画像を1枚使うほうが効果的です。最高評価のサイトでは、ファーストビューの少なくとも半分をヒーロー画像が占めるケースが68％です。
• トリミングの比率と処理方法を統一し、方向性に別段の指定がない限り、角は四角にします（調査対象サイトの73％は画像の角を丸めていません）。
• 画像は、プレースホルダーやアイコン、抽象図形よりも効果的です。この題材のために、その色彩で、丁寧に描いた画像なら、さらに効果的です。その世界を実際に写した画像を見つけて、クレジットを記載すれば、なお効果的です。
• 見つけた画像はすべてプロジェクトにダウンロードし、ページにクレジットを記載して、レポートに一覧を載せます。クライアント自身が所有する画像としては扱いません。
• 見出しやステートメントに何かを重ねてはいけません（インスペクターで不合格になります）。

コンポーネント

• ボタン：塗りつぶし1色のフラットなデザインにし、角を四角くするか、完全な丸型にするかを最初に決めて統一します（上位サイトでは四角が52％、ピル型が23％です。9～16pxの「ソフト」な角丸は、低評価サイトの標準です）。優れたヒーローの多くはボタンを設置しないか、設置しても1つだけです。
• ナビゲーション：ワードマーク、装飾のないリンクを3～5個、アクションを1つにします。バー状の装飾は加えません。
• フッターは、サイトマップではなく、デザインされた締めくくりです。優れたサイトの多くでは、名前を全幅で再び表示します。

特殊なケース

既存のブランドまたはデザインシステムがある場合。 --keep palette,type を渡し、ブランドの色と書体を各役割に割り当て、ドローからは構成だけを取り入れます。基本ルールは引き続き適用されます。ブランド自体が禁止されている要素（ロゴがグラデーションに配置されている、アクセントカラーがバイオレットなど）を必要とする場合は、ブランドアセットを維持し、その旨をレポートに記載したうえで、そのルールに限ってインスペクターに --allow <rule> を渡します。

既存のページまたはアプリ画面の再設計、スタイル変更、レビュー。

1. 変更前を記録します。 プロジェクトをそのまま実行し、専用フォルダーに検査結果を出力します （inspect.mjs <url> --out .taste-skill/before。アプリ画面の場合は --app を指定します）。ソースのリントも実行します。コードを確認し、フレームワーク、スタイル設定方法（Tailwind v3 または v4、CSS modules、styled-components、plain CSS）、コンポーネント、そして維持すべきもの（ルート、フォーム、データ、動作、ブランド独自のアセット）を把握します。
2. レビューの場合はここで終了します。 references/critique.md を使って変更前のスクリーンショットを批評し、インスペクターの測定値とともに指摘事項を列挙して、ページを最も改善する3つの変更を示します。
3. スタック、コンテンツ、機能している部分を維持します。 フレームワークやスタイルライブラリーは移行しません。何かを追加する前に依存関係ファイルを確認します。スタイル変更ではレイアウトを維持し、決定済みの方向性からタイポグラフィ、色、コンポーネントを取り入れます（ブランドで固定されているものは --keep で維持します）。再設計では、方向性全体を決定し、既存のコンポーネント内で設計図に沿ってセクションを再構築します。いずれの場合も、実際のページコンテンツを使って作業のステップ2から進めます。
4. 作業の順序は、リスクを抑えて効果を最大化できる順にします。 タイポグラフィ（書体とサイズ）、色（ベースカラー、文字色、アクセントカラーをそれぞれ1つずつ）、フレーム（余白、セクションのリズム、最初の画面のタイトルと各セクションの見出し）、状態（ホバー、フォーカス、読み込み中、空、エラー）、そして標準コンポーネント（アイコンカード、ピル型バッジ、グラデーションのブロブ、カードグリッド）を決定済みの設計図に沿ったものに置き換えます。
5. 検証します。 .taste-skill/after に再度検査結果を出力し、すべての幅で変更前と変更後を比較します。変更前に機能していたリンク、フォーム、メニューをすべて操作し、変更前と変更後の測定値を並べてレポートします。

ページではなく、コンポーネントまたは単一のセクションの場合。 従うべき方向性がない場合を除き、ドローは省略します。周囲のデザインに合わせ、基本ルールと法則を適用し、結果の検査も行います。

チェックアウト機能もフォームのバックエンドもない場合。 ブリーフで指定されている場合、プライマリーボタンは実際の遷移先にリンクします。そうでなければ、件名と本文を記入したメールを開きます（mailto: に訪問者の選択内容を入力します）。ショップの場合は #checkout を指定し、ローンチ前に接続が必要であることをレポートに記載します。決済フォームを偽装してはいけません。

Chrome または Node 22 がない場合。 lint.mjs を実行し（Node 18+）、利用可能なブラウザーツールでスクリーンショットを撮影して批評します。インスペクターを実行できなかったことをレポートに記載します。

ネットワークに接続できない場合。 assets.mjs がソースに到達できなければ、画像を描画し、オープンコレクションを検索できなかったことをレポートに記載します。

ファイル

ファイル	読むタイミング
references/app-screens.md	ダッシュボード、管理、設定など、アプリ画面を扱うとき：各画面固有の手順、ルール、トークン、チェック項目を確認します。
references/copy.md	主張とコピー一式を作成するとき（手順 2 と 5）。2 行の算術式も確認します。
references/type.md	文字を設定するとき：スケール、トラッキング、文字幅、フォントの読み込み、組み合わせを確認します。
references/colour.md	パレットを適用するとき：役割、比率、トーンの段階、ダークなページ、コントラストを確認します。
references/layout.md	グリッド、余白、リズム、セクションの変化、ナビゲーション、フッター、スマートフォンの構成を確認します。
references/imagery.md	画像を選び、探し、クレジットを付け、トリミングし、調整するときや、画像がない場合の対応を確認します。
references/motion.md	手順 9。予算、トークン、レシピ、動きを抑える設定を確認します。
references/scenes.md	手順 6。シートでスクロールシーンを扱うとき：ページへの配置、内容の補充、調整、スマートフォン対応、確認、カタログを確認します。
references/critique.md	手順 8。確認方法、採点方法、優先して修正する項目を確認します。
references/tells.md	生成ページによく見られる特徴と、それぞれの置き換え先を記した日付入りの一覧です。
references/research.md	調査：手法、数値、優れたサイトと劣ったサイトの特徴を確認します。推測せず、出典として引用してください。
scripts/draw.mjs	方向性を選び直して再出力します。参照例を増やすには --photos、--site <id> を指定します。アプリのスタイルを選ぶには --app を指定します。
scripts/assets.mjs	手順 6：オープンコレクションから、対象の世界観に合う実際の画像を検索します。クレジット付きでダウンロードするには --get、クレジットを表示するには --credits を指定します。
scripts/lint.mjs · scripts/inspect.mjs	ゲートです。
scripts/scenes.mjs	スクロールシーンのゲートです。各シーンの保持時間の 0〜100％、デスクトップ、スマートフォン、動きを抑える設定を確認します。
assets/base.css · assets/base.js	土台として使える、任意のニュートラルな基盤です。
assets/scenes/	スクロールシーン：共有ステージ（stage.js、stage.css）と、ライブラリ内の各シーンの .js、.css、および動作するデモページ（demo/）が含まれます。
assets/app.css · assets/charts.js	アプリ画面用：ニュートラルなシェル、パネル、テーブル、コントロール、およびアプリのルールに沿って描画する小さな SVG チャートです。
library/	draw が読み込むデータ：方向性、ヒーロー、セクション、文字システム、パレット、写真、調査対象のサイト、モーション、スクロールシーン（scenes.json）、アプリのスタイル、シェル、画面パターン（app.json）が含まれます。すべてを一度に読まず、スクリプトを使ってください。