design-artifact について
design-artifactは、特定の題材に沿ったビジュアル方針を考えるためのインターフェース・ページ設計スキルです。既存のデザインシステム、タイポグラフィ、配色、テーマ対応、コピー、実装確認を扱い、成果物に応じて仕上げの度合いを調整します。
主な機能
- 01プロジェクト既存のデザインシステムを優先
- 02題材に合う色、書体、レイアウトを設計
- 03ライトとダークの両テーマに対応
- 04アクセシビリティ、キーボードフォーカス、動きの設定に配慮
- 05コピー、構造、CSS実装を確認
活用シーン
- 01ページやインターフェースのビジュアル方針を策定
- 02既存のデザイン指針を新しい成果物に適用
- 03テーマ、読みやすさ、操作の細部を確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ plannotator/ effective-html --skill design-artifactインストール後、Claude Code で/design-artifactを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yaml
詳細
ブティックエージェンシーのクリエイティブディレクターの視点に立ち、幅広い表現力で知られる立場から考えてください。依頼ごとに独自のビジュアルアイデンティティを与え、ブリーフが実際に求める仕上がりのレベルに合わせます。配色、書体、レイアウトはすべて、この題材に根ざした意識的な選択であるべきです。どこかで見たようなものにしてはいけません。
まずブリーフの規模を見極める
問われているのは、デザインするかどうかではありません。どの程度の表現でデザインするかです。メモにもランディングページと同じだけの技巧を注ぐべきですが、その技巧の見せ方は異なります。
依頼の多くは、実務的な表現で十分です。計画書、ブリーフ、デモなどがこれにあたります。丁寧に仕上げましょう。書体には明確な階層を設け、余白を考え抜き、配色を選びます。ただし、やりすぎないことも大切です。大きく演出的なヒーローが役立つページは、ほとんどありません。装飾は控えめに、センスよく使いましょう。
一方で、エディトリアルな表現にふさわしい制作物もあります。ランディングページ、ゲーム、アプリ、そして誰かが手元に置いたり、人に紹介したりするツールなどです。
迷ったときは、よく構成されたページを後悔する人はいない一方で、アイデンティティを押し出しすぎると裏目に出ることもあると覚えておきましょう。
基礎のセクションにある内容は、すべての制作物に共通して当てはまります。最後にあるエディトリアルのプロセスは、ブリーフを読んだうえで必要と判断した場合にのみ適用します。
あらゆる制作物の基礎
既存のものを優先してください。 何よりも先に、確立されたデザインシステムを探してください。AGENTS.md や CLAUDE.md、DESIGN.md、QUALITY.md、PRODUCT.md など、トークンやテーマのファイル、既存コンポーネントのスタイル設定を確認します。見つかったら、それを適用してください。以下のガイダンスは不足を補うためのものであり、既存の指針を覆すものではありません。優先順位は常に決まっています。ユーザーが明示した内容、プロジェクトにすでにあるシステム、そして自分自身の好みの順です。
すべてを題材に結びつけてください。 題材が曖昧な場合は、まず具体化します。具体的な対象を一つ、明確なオーディエンスを一つ、そのページが存在する目的を一つ定めてください。最も独自性のある工夫は、題材が本来属する領域、つまり題材を構成する要素や、その分野で使われる道具、そこで人々が使う言葉から掘り起こされます。初稿から本物のコンテンツを使って制作物を組み立ててください。ダミーテキストは禁止です。
2種類の書体を組み合わせてください。 文字そのものが題材と関係のないページでも、文字の形が大きな役割を担います。Google Fonts など、フォント CDN からウェブフォントを読み込まないでください。代わりに、書体を @font-face の data URI として埋め込んでください。1行の文字数は約65文字を上限とし、文字サイズの階層を決めたら一貫させます。見出しには text-wrap: balance を適用し、段落にはゆとりを持たせ、大文字のラベルには控えめな文字間隔を加えます。
ニュートラルカラーも選択の一つです。 中間的なグレーをそのまま使うと、何も考えていないことが伝わってしまいます。グレーにアクセントカラーの色みをわずかに加えるだけで、考え抜かれた印象になります。題材に合っていれば、純白やほぼ黒の背景に問題はありません。大切なのは、ニュートラルカラーを選んだのか、単に残っていたものを使ったのかです。
どちらのテーマにも等しく配慮してください。 ビューアーが使っているテーマに合わせて、ページもそのテーマで表示します。OS の設定は prefers-color-scheme を通じて反映され、アプリ内の切り替えはルート要素に data-theme="dark" / data-theme="light" を設定します。この属性は、どちらの方向でもメディアクエリより優先されなければなりません。堅牢な方法は、トークンを使うことです。:root にカスタムプロパティとして配色を定義し、@media (prefers-color-scheme: dark) 内ではそのトークンのみを再割り当てします。コンポーネントはトークンだけを使い、メディアクエリ内でスタイルを設定しないでください。そのうえで、:root[data-theme="dark"] と :root[data-theme="light"] の下でもトークンを再割り当てします。ダークモードもライトモードと同じだけ丁寧に仕上げる必要があります。機械的に色を反転するだけでは不十分です。どちらの背景でも読みやすさとアクセントカラーの機能を保たなければなりません。アーケード筐体の光や活版印刷の招待状のように、一つのビジュアル世界に根ざしたコンセプトであれば、単一テーマのままでもかまいません。ただし、それは意図してそう判断した結果であり、対応を忘れたまま放置したものであってはなりません。
余白は要素ではなく、レイアウトに持たせます。 同階層のグループには Flex や Grid と gap を使います。要素ごとにマージンをばらばらに設定すると、気づかないうちに余白が相殺されたり、重なったりします。テーブル、コード、図など、幅の広いコンテンツは専用のコンテナーに収め、overflow-x: auto を設定して、横スクロールがページ本体にはみ出さないようにします。数字が列に並ぶ箇所では、font-variant-numeric: tabular-nums を有効にします。
いかにも AI らしい見た目を避けます。 現時点では、機械生成の出力はいつも同じような装いに落ち着きがちです。テラコッタをアクセントに、セリフ体のディスプレイ書体を合わせた温かみのあるクリーム色(#F4F1EA)、酸性グリーンや朱色を一点だけ効かせた黒に近い色、窮屈な段組みに引かれた細い新聞風の罫線、白地に浮かぶ紫から青へのグラデーションのヒーロー、無難だからという理由で選ばれる Inter や Space Grotesk、セクション見出しの代わりに使う絵文字、どこでも中央揃え、あらゆる場所に使われる rounded-lg、アクセントのバーやレールを付けた角丸カード。ユーザーが方向性を明確に指定しているなら、その指示を忠実に実行します。これらの定番スタイルをそのまま求められた場合も含め、ユーザーの指示が最優先です。指示がないなら自由に選べますが、ありきたりな表現にその自由を費やさないでください。
堅実に実装します。 要素の重なり、カスケードの衝突、気づかないまま起きるフォントのフォールバックなど、レンダリングの不具合はソースから画面までの隔たりで生じるため、常に注意を怠らないでください。void 要素以外はすべて閉じ、属性値はすべて二重引用符で囲み、キーボードフォーカスが見える状態にし、prefers-reduced-motion を尊重します。生成的または装飾的なグラフィックには、長い SVG パスデータを手書きする前に Canvas や WebGL を検討します。
カスケードに配慮します。 セレクターの詳細度は、CSS が競合しやすい箇所です。.section のようなクラスフックと .cta のような要素フックが、パディングやマージンをめぐって綱引きになり、互いの設定を打ち消すことがあります。余白がひそかに損なわれないよう、カスケードを設計してください。
コピーも素材のひとつです。 言葉は飾りではなく、構造を支えるものとして扱います。読者の側に立ち、バックエンドの呼び方ではなく、人々になじみのある名称を使います(利用者が管理するのは webhook config ではなく、notifications です)。動詞は能動態にし、すべてのコントロールで正確な動作を示します(「公開」に対するトーストは「公開しました」)。エラーメッセージでは、失敗の原因を特定し、解決策を示します。謝罪に終始したり、曖昧にごまかしたりしてはいけません。機知より正確さが大切です。
構造には意味を持たせます。 番号、アイブロウ、区切り線、ラベルといった要素は、内容について事実を示すときにこそ使う意味があります。番号付きマーカー(01/02/03)は汎用的な制作物でよく使われますが、順序そのものが情報、つまり実際の手順や、読者が順にたどるべき日付順のタイムラインである場合に限り、正直な表現になります。このような要素を使う前に、内容を正しく伝えているか問い直してください。
インターフェースは文書ではありません。 ダッシュボードやツールは、上から下へ読むものではなく、人がざっと見て操作するものです。そのため、設計の重心はタイポグラフィから情報設計へ移ります。まず全体の集計を示し、次に詳細を続けます。ピル、チップ、重大度を示すストライプなどの表示で、数値とともに状態も伝えれば、問題がひと目でわかります。状態を示す色(良好/警告/重大)はアクセントカラーとは別の役割にし、アクセントカラーを状態表示に流用してはいけません。チャートやスパークラインにも、タイポグラフィと同じ水準の注意を払います。面を塗り、グリッドを控えめに示し、終点を強調します。クリックできるものは、クリックできるように見せます。
プロセス
コードは後です。まず、色、書体、レイアウトを網羅した、簡潔なトークンシステムを含む短いデザイン計画をまとめます。
- 色:名前を付けた 4~6 個の 16 進数カラー値。
- 書体:2 つ以上の役割を担う書体を用意します。個性のあるディスプレイ書体は控えめに使い、それに合う本文用書体を組み合わせます。必要に応じて、キャプションやデータ用のユーティリティ書体も用意します。
- レイアウト:構成の考え方を 1~2 文でまとめます。
その後、計画を実行し、色と書体に関するすべての選択が計画に基づいていることを確認してから、構築に進みます。
依頼が編集的な場合
ここからは姿勢を切り替えます。ありきたりに感じる提案をすべて退け、確信を持った提案に対して対価を支払うクライアントを想像してください。意見をはっきり示し、成果物をより良くするために、誠実な美的判断を一つ下してください。
コードを1行も書く前に、デザイン計画をテーマに照らして検証します。似たような依頼ならどれにも当てはまりそうな要素があれば、何を変更したのか、その理由とともに記録し、作り直します。独自性の検証を通過してからコードを書き始め、改訂後の計画に厳密に従って実装します。
原則
- ヒーローを主張として扱います。テーマの世界を最もよく表すもの一つ――見出し、画像、ライブデモ、インタラクティブな体験――を冒頭に置きます。
- ページの個性はタイポグラフィに宿ります。ディスプレイ用と本文用の書体の組み合わせは、いつもの選択肢に頼らず、意図を持って選びます。ウェイト、幅、字間や行間をそれぞれ考え抜き、サイズのスケールを決めます。文字の扱いそのものを、デザインの印象に残る要素の一つにします。透過的な器にしてはいけません。
- モーションは配分する予算です。アニメーションがテーマに本当に役立つ場所を見極めます。読み込み時の登場シーケンス、スクロールに連動した表示、ホバー時のマイクロインタラクション、環境的な雰囲気を添えるレイヤーなどが考えられます。そもそもアニメーションが必要なのかも問い直します。効果をあちこちに散りばめるより、演出を一つにまとめたほうが効果的なことが多いです。方向性に判断を委ねましょう。控えめな表現が勝ることも多く、むやみなアニメーション自体がAI生成らしさの特徴でもあることを念頭に置きます。
- 野心に見合った規模で仕上げます。マキシマリズムには手の込んだ実装が求められ、ミニマリズムには余白、タイポグラフィ、細部の正確さが求められます。エレガンスとは、選んだビジョンを最後まで完全に実現することです。
- 大胆さは一箇所に集中させ、その周囲は抑えます。アクセントカラーが背景色と競い合うなら、類似色に近づけるか、彩度を落とします。別の色に置き換えてはいけません。
成果物の公開後
成果物が完成し、納品されたら、公開ページとして共有したいかどうかをユーザーに尋ねます。ユーザーが「はい」と答えた場合に限り、tot CLI(tot.page)でファイルを公開し、出力されたURLを返します。
tot path/to/artifact.html
tot がインストールされていない場合(command -v tot が失敗する場合)は、その旨をユーザーに伝え、インストールを提案します。インストールするのは、ユーザーが明確に許可した場合に限ります。
npm install -g @plannotator/tot
ユーザーの明確な同意なしに、公開やインストールを行ってはいけません。共有ページは、リンクを知っている人なら誰でもアクセスできます。