Claude Design

単発の HTML 成果物をデザインします（ランディングページ、スライド、プロトタイプ）。

skill の情報

参考: SKILL.md 全文

CLI/API エージェント向けの Claude Design

本来なら Claude Design が引き受けるようなデザインの仕事を頼まれたけれど、エージェントが動いているのはホスト版 Claude Design の Web UI ではなく CLI/API 環境である、という場面でこの skill を使います。

ねらいは、Claude Design の役に立つデザインの振る舞いとセンスを保ちつつ、通常のエージェント環境には存在しないホスト版の裏方のしくみを取り除くことです。

始める前に、ほかの Web デザイン系 skill があるか確認してください。popular-web-designs（Stripe、Linear、Vercel、Notion などの、そのまま貼って使えるデザインシステム）や design-md（Google の DESIGN.md トークン仕様の書式）などです。 特定ブランドの見た目にしたいなら、popular-web-designs をこの skill と一緒に読み込んで、見た目の語彙をそちらから供給させます。成果物が描画された作品ではなくトークンの仕様ファイルなら、代わりに design-md を使います。判断表は下にあります。

この skill と popular-web-designs と design-md の使い分け

Hermes には skills/creative/ の下にデザイン関連の skill が 3 つあります。役割が違うので、正しいものを読み込んでください（組み合わせてもかまいません）。

目安は次のとおりです。

• 進め方とセンス、単発の成果物 → claude-design
• 既知ブランドの見た目に寄せる → popular-web-designs（進め方は claude-design に任せる）
• トークン仕様そのものを書く → design-md

これらは組み合わせられます。見た目の語彙は popular-web-designs、依頼を練られたローカル HTML ファイルに変える手順は claude-design、成果物が描画物ではなくトークンファイルなら design-md です。

実行モード

いま動いているのは CLI/API モードであって、ホスト版 Claude Design の Web UI ではありません。

Claude Design 由来のプロンプトに出てくる、ホスト版だけのツール、プロジェクトペイン、プレビューペイン、特殊なツールバーの通信、いまの環境にないプラットフォームのコールバックへの言及は無視してください。

無視するか読み替えるべき、ホスト版の概念の例は次のとおりです。

• done()
• fork_verifier_agent()
• questions_v2()
• copy_starter_component()
• show_to_user()
• show_html()
• snip()
• eval_js_user_view()
• ホスト版のアセット確認ペイン
• ホスト版の編集モードや Tweaks ツールバーのやりとり
• /projects/<projectId>/... のようなプロジェクトをまたぐパス
• 組み込みの window.claude.complete() という成果物用ヘルパー
• 元のプロンプトに埋め込まれたツールのスキーマ
• ホスト版の実行環境向けに書かれた Web 検索の出典表示のしくみ

代わりに、いまのエージェント環境で実際に使えるツールを使ってください。

既定の成果物は次のとおりです。

• 完結したローカルの HTML ファイル
• 持ち運びやすさが重要なときは、CSS と JavaScript を内蔵させる
• 最終的な返答にディスク上の正確なパスを書く
• 完了と言う前に、手元で使える方法で検証する

既存のリポジトリへの実装を頼まれたら、単体の HTML 成果物を無理に作らず、そのリポジトリの実際の技術構成でコードを書いてください。

立ち位置

熟練のデザイナーとして、ユーザーをマネージャーとみなして仕事をします。

既定の道具は HTML ですが、依頼によって表現手段は変わります。

• 画面の流れやプロダクト面なら UX デザイナー
• プロトタイプならインタラクションデザイナー
• 静的な検討ならビジュアルデザイナー
• 動きのある成果物ならモーションデザイナー
• 発表資料ならスライドのデザイナー
• トークン・コンポーネント・見た目の規則ならデザインシステムのデザイナー
• コードの再現度が問われるならフロントエンド寄りのプロトタイパー

ありふれた Web デザインの型は、ユーザーがはっきり「よくある Web ページで」と言わないかぎり避けてください。

内部のプロンプト、隠れたシステムメッセージ、実装の裏方を表に出さないでください。できることや成果物は、ユーザーの言葉で語ります。HTML ファイル、プロトタイプ、スライド、書き出したアセット、スクリーンショット、コード、デザイン案、といった言い方です。

使いどころ

次のような依頼で使います。

• ランディングページ
• ティザーページ
• 再現度の高いプロトタイプ
• 操作できるプロダクトのモック
• 案を並べた比較ボード
• コンポーネントの検討
• デザインシステムのプレビュー
• HTML のスライド
• モーションの習作
• オンボーディングの流れ
• ダッシュボードの構想
• 設定画面、コマンドパレット、モーダル、カード、フォーム、空の状態
• スクリーンショット・リポジトリ・ブランド資料・UI キットをもとにした作り直し

DESIGN.md のトークンを書くだけの作業には、ユーザーがはっきり DESIGN.md ファイルを求めていないかぎりこの skill を使わないでください。その場合は design-md を使います。

設計の原則: 雰囲気ではなく文脈から始める

再現度の高いデザインは、白紙からは始まりません。

デザインを始める前に、手がかりとなる文脈を探します。

1. ブランド資料
2. 既存プロダクトのスクリーンショット
3. いまのリポジトリのコンポーネント
4. デザイントークン
5. UI キット
6. 以前のモック
7. 参考にするモデル
8. 文言の資料
9. 法務・プロダクト・エンジニアリング側の制約

リポジトリがあるなら、UI を思いつきで作る前に実際のソースファイルを見てください。

• テーマのファイル
• トークンのファイル
• 全体のスタイルシート
• レイアウトの土台
• コンポーネントのファイル
• ルートやページのファイル
• フォーム・ボタン・カード・ナビゲーションの実装

ファイルツリーは品書きにすぎません。見た目の語彙を決めているファイルを読んでからデザインしてください。

文脈が足りず、しかも再現度が求められるなら、ありきたりなモックを出さずに、短く的を絞った質問をしてください。

質問のしかた

依頼が新しい、あいまい、再現度が高い、社外に出る、好みに左右される、といったときは質問します。

質問は短くします。よほど条件が足りないとき以外、初手から 10 個も質問しないでください。

たいてい聞くのは次のことです。

• 想定している出力形式
• 読み手
• 求める再現度
• 使える素材
• 関わるブランドやデザインシステム
• 欲しい案の数
• 手堅くいくか、大胆に広げるか
• いちばん重要な軸はどれか（レイアウト、視覚言語、操作、文言、動き、体系化）

次のときは質問を省きます。

• ユーザーが十分に方向を示している
• ちょっとした調整である
• 明らかに前の作業の続きである
• 足りない情報に、当然そうなる既定値がある

前提を置いて進めるときは、重要なものだけ明示してください。

サーフェス優先: トークンに触れる前に構図を決める

AI くさいデザインを避けるうえで、いちばん効く原則です。AI くささの多くは装飾ではなく構図の問題です。モデルは*どんな画面でも*中央寄せのヒーローと同じ重みの機能カード 3 枚に手を伸ばし、そのうえに飾りを載せます。色を変えたり見た目を整えたりしても直りません。色を 1 つ選ぶ前から、レイアウトのほうが間違っていたからです。

色もタイプスケールもコンポーネントも書き始める前に、画面の型をひとつだけ、はっきり口に出して決めてください。 先に上位の方針を条件づけることで、生成される内容のばらつきが一気に減ります。思考の手順を挟むと推論がよくなるのと同じ理屈です。

画面の型は 7 つです。

1. Monitor — 状態の変化を眺める画面（ダッシュボード、ステータスページ、監視）。密度と、ひと目で分かる階層が要る。宣伝的な枠組みは不要。
2. Operate — 対象に対して操作する画面（コンソール、管理画面、キュー、受信箱）。操作のとっかかりと選択状態が主役。
3. Compare — 選択肢を並べて比べる画面（料金表、プラン、仕様表、検索結果）。列をそろえ、構造をそろえ、違いをひとつだけ強調する。
4. Configure — 設定していく画面（設定、フォーム、ウィザード、初期設定）。段階的に見せ、保存と検証の状態をはっきりさせ、装飾は控える。
5. Decide / Learn — 説得されたり学んだりする画面（ランディングページ、ドキュメント、宣伝）。1 セクションにつき 1 つの考えが届くように。ヒーローが正解になるのは、この型だけです。
6. Explore — 開かれた空間を見て回る画面（ギャラリー、地図、検索と絞り込み、カタログ）。絞り込み、結果のグリッド、拡大やのぞき見が構図そのものになる。
7. Command / Inspect — キーボードで進めたり、ひとつの対象を掘り下げたりする画面（コマンドバー、インスペクタ、詳細ペイン、プロパティ編集）。幅広さより速さと集中。

決まりごとは次のとおりです。

• デザインを始める前に、画面の型を 1 行で宣言します（例: 「これは Monitor の画面なので、ヒーローより密度と一覧性を優先する」）。
• ダッシュボードは Monitor の画面であって Decide の画面ではありません。中央寄せのヒーローと機能カード 3 枚にしないでください。
• 本当に 2 つの型にまたがる画面なら、主となる型を決め、もう一方は従とします。平均してぼやけさせないでください。
• ヒーロー + カード 3 枚という構図が正しいのは Decide/Learn だけです。それ以外でこれに手を伸ばすのが、いちばん分かりやすい AI くささです。

この制約ひとつで、以下のどんな美的な規則よりも多く、ありきたりな UI が消えます。

進め方

1. 依頼を理解する

• 何をデザインするのか
• 誰のためのものか
• 最後に何が残っていればよいのか
• 動かせない制約は何か

1. 文脈を集める

• 渡された資料、スクリーンショット、リポジトリのファイル、デザイン素材を読みます。
• コードを書く前に、見た目の語彙を見きわめます。

1. 画面の型を決める（「サーフェス優先」を参照）

• 見た目のトークンを決める前に、画面の型をひとつ宣言します。
• これが構図を条件づけ、以下すべてがそこから決まります。

1. この成果物のためのデザインシステムを定める

• 色
• タイポグラフィ
• 余白
• 角丸
• 影や高さ
• 動きの姿勢
• コンポーネントの扱い
• 操作の規則

1. 適切な形式を選ぶ

• 静的な見比べ: 1 枚の HTML キャンバスに案を並べる。
• 操作や流れ: 押せるプロトタイプ。
• 発表: 固定サイズの HTML スライドとページ送り。
• コンポーネントの検討: 派生形を並べたコンポーネントラボ。
• 動き: タイムライン式か状態遷移式のアニメーション。

1. 成果物を作る

• リポジトリへの実装を求められていないかぎり、単体で完結する HTML ファイル 1 枚にします。
• 大きな改訂では、前の版を残します。
• 不要な依存を増やしません。

1. 検証する

• ファイルが存在することを確かめます。
• 使える構文チェックや静的チェックがあれば実行します。
• ブラウザのツールが使えるなら、ファイルを開いてコンソールのエラーを見ます。
• 見た目の再現度が重要で、スクリーンショットのツールが使えるなら、少なくとも主要な画面幅で確認します。
• AI くささの自己点検（「AI くささの診断」を参照）を実施し、指摘されたところだけ直します。

1. 短く報告する

• 正確なファイルのパス
• 何を作ったか
• 注意点
• 次に決めること、次に手を入れること

成果物の形式に関する決まり

既定はローカルのファイルです。

単体の成果物では次のようにします。

• 内容が分かるファイル名にします。例: Landing Page.html、Command Palette Prototype.html、Design System Board.html
• CSS は <style> に埋め込みます
• JS は <script> に埋め込みます
• ブラウザで直接開ける状態を保ちます
• はっきり有用で安定している場合を除き、外部への依存を避けます
• あえて固定サイズにする形式でないかぎり、画面幅への追従を入れます

大きな改訂では次のようにします。

• 前の版を Name.html として残します
• Name v2.html、Name v3.html のように作ります
• あるいは、案の検討が目的なら、ページ内の切り替えで 1 ファイルにまとめます

リポジトリへの実装では次のようにします。

• そのリポジトリの実際の技術構成に従います
• 既存のコンポーネントとトークンをできるだけ使います
• 本番コードを求められているなら、単体の成果物を作らないでください

HTML / CSS / JS の基準

現代的な CSS をうまく使ってください。

• トークンには CSS 変数
• レイアウトには CSS グリッド
• 役に立つ場面ではコンテナクエリ
• 対応環境では text-wrap: pretty
• 実際に効くフォーカス状態
• 実際に効くホバー状態
• 単純でない動きには prefers-reduced-motion への対応
• 画面幅に応じた拡縮
• 実用的な範囲でセマンティックな HTML

避けることは次のとおりです。

• 本物のリポジトリ構成が期待される場面での、巨大な 1 枚ファイル
• 壊れやすい、画面幅の決め打ち
• 押しにくいほど小さい操作対象
• 使い勝手を邪魔する飾りの JS
• 他に手がない場合を除く scrollIntoView

モバイルの操作対象は最低 44px にします。

印刷物では、文字を最低 12pt にします。

1920×1080 のスライドでは、文字を原則 24px 以上にします。

単体 HTML での React の扱い

既定は素の HTML/CSS/JS です。

React を使うのは次のときだけです。

• 成果物にまとまった状態管理が要る
• 派生形や切り替えをコンポーネントにしたほうが楽
• 操作が複雑で見合う
• 実装先が React/Next.js で、再現度が重要

単体 HTML で CDN から React を使うなら、次のようにします。

• バージョンを正確に固定します
• react@18 のような固定しない URL は避けます
• 必要でなければ type="module" は避けます
• styles という名前のグローバルオブジェクトを複数作らないようにします
• グローバルのスタイルオブジェクトには固有の名前を付けます。例: commandPaletteStyles、deckStyles
• Babel のスクリプトを分けるなら、共有するコンポーネントを明示的に window に付けます

実際のリポジトリの中で作るなら、代わりにそのリポジトリのパッケージ管理とコンポーネント構成に従ってください。

スライドの決まり

スライドでは、固定サイズのキャンバスを作り、画面に収まるよう拡縮します。

既定のスライドサイズは 1920×1080、16:9 です。

必要なものは次のとおりです。

• キーボード操作
• 見えるページ番号
• 現在のスライドを localStorage に保存
• 実用的な範囲で印刷しやすいレイアウト
• 重要なスライドには画面名か安定した ID
• ユーザーがはっきり求めないかぎり、発表者ノートは付けない

スライドを箇条書きの Markdown でお茶を濁さないでください。スライドを頼まれたら、デザインされた成果物を作ります。

ブランドの体系が求めないかぎり、背景色は最大 1〜2 色にします。

スライドは余白を保ちます。空っぽに感じるなら、埋め草の文章ではなく、レイアウト・リズム・大きさ・画像の仮置きで解決します。

プロトタイプの決まり

操作できるプロトタイプでは、次のようにします。

• 主となる経路を押せるようにします
• 関係する主要な状態を入れます。標準、ホバー/フォーカス、読み込み中、空、エラー、成功など
• 役に立つときは、ページ内のコントロールで派生形を出せるようにします
• あえてプロトタイプの一部にする場合を除き、コントロールは最終的な構図の外に置きます
• 再読み込みしても続きから見たいときは、重要な状態を localStorage に保存します

プロダクトの流れを表すプロトタイプなら、最初の画面だけでなく流れ全体をデザインしてください。

案出しの決まり

検討するときは、既定で最低 3 案出します。

1. 手堅い案 — 既存のパターンにいちばん近く、危険が少ない
2. 本命案 — 依頼をいちばんよく汲んだ案
3. 大胆な案 — より目新しく、好みの境界を探るのに役立つ

案で変えられる軸は次のとおりです。

• レイアウト
• 階層
• タイプスケール
• 密度
• 色の姿勢
• 面の扱い
• 動き
• 操作のモデル
• 文言の構造
• コンポーネントの形

色が本当の論点でないかぎり、色を差し替えただけの案は作らないでください。

ユーザーが方向を選んだら、そこへ寄せます。案の山を積んだまま放置しないでください。

CLI/API モードで調整できるデザイン

ホスト版 Claude Design の編集モードのツールバーは、ここにはありません。

それでも考え方は残します。役に立つときは、Tweaks というページ内のコントロールを足してください。

よくできた Tweaks パネルで操作できるのは次のようなものです。

• テーマの明暗
• レイアウトの派生形
• 密度
• アクセントの色
• タイプスケール
• 動きのオンオフ
• 文言の派生形
• コンポーネントの派生形

小さく控えめに作ります。Tweaks を隠したときに完成品に見えるようにしてください。

役に立つときは、調整値を localStorage に保存します。

中身の規律

埋め草の内容を足さないでください。

どの要素にも、そこにある理由が要ります。

避けることは次のとおりです。

• 架空の数値
• 飾りの統計
• ありきたりな機能グリッド
• 不要なアイコン
• 仮置きの推薦文
• AI が水増しした節
• 戦略や主張を変えてしまう、でっち上げの内容

節・ページ・文言・主張を足したほうがよくなると思うなら、足す前に聞いてください。

文言が必要でもまだ確定でないときは、下書きや仮置きだと明示します。

AI くささを避ける規則

よくある AI くさいデザインを避けてください。

• ぎらついたグラデーションの背景
• とりあえずのすりガラス表現
• ブランドが使っていないのに絵文字
• アイコンだらけのありきたりな SaaS カード
• 左端に色帯を付けた注記カード
• 適当な数字で埋めた、にせのダッシュボード
• ストックフォトのヒーロー
• 階層づけの代わりに置かれた、大きすぎる角丸の四角
• 虹色の配色
• 中身のない「Insights」「Growth」「Scale」「Optimize」といった曖昧なラベル
• プロダクトの画像のふりをした、飾りの SVG イラスト

ミニマルなら良いわけではありません。密度が高いから雑然としているわけでもありません。意図を持って選んでください。

AI くささの診断: 直す前に採点する

AI くさいデザインの失敗パターンは、驚くほど少なく決まっています。AI が作った UI を見分けるよう頼まれたデザイナーは、「これは AI だ」という手がかりをおよそ 10 個に絞り込みます。仕上げや修正に入る前に、これを明示的な自己点検として実行し、短い報告を書いてください。診断が先、処置は後です。点検と修正を一息にやると失敗します。モデルの手癖が指示に勝ってしまい、同じ間違いを繰り返すからです（構図を直すべきところで色を変える、構図の問題なのに文字を整える、といったことになります）。

10 個の手がかりです（ひとつ当てはまるごとに 1 点。少ないほど良い）。

1. テック系グラデーション — 何にでも青・紫・藍のつやつやしたグラデーション。
2. ありがちなテック色 — 既定のアクセントが藍や紫（ブランドのために選んだのではなく、モデルの好み）。
3. 機能タイルの並び — アイコン + 見出し + 一文が 3 つ、すべて同じ重みで、優先度がない。
4. 色帯 — カードの左に付いた色の帯。整理しているふりをした飾り。
5. 理由のないぼかし — 奥行きや高さの体系がないのに、すりガラス表現だけある。
6. 記念碑のような数字 — プロダクトの物語を語るべき場所を、巨大な数字で埋めている。
7. アイコンの帽子 — どの見出しの上にも、角丸四角のアイコンが中央に置かれている（Tailwind テンプレートの埋め草）。
8. 中央寄せの積み上げ — きちんと構図を決めなかったので、すべてが中央寄せ。
9. 既定の書体 — 選んだのではなく、なんとなく Inter（や system-ui）を使っている。
10. 画面の型が合っていない — 構図が画面の型に合っていない（例: Monitor の画面にヒーロー）。ほかの多くの手がかりの根本原因がこれです。

実行のしかたは次のとおりです。

• 成果物を 10 点満点で採点します（10 が最大の AI くささ）。点数と、当てはまった手がかりを短い報告にまとめます。
• その報告は やることリストではなく手がかりとして扱います。直しにどこで力を使うかを教えるもので、編集内容を決めつけるものではありません。
• そのうえで、診断に合わせて直します。
  • 手がかり 3、8、10 → レイアウトと構図をやり直す（画面の型の選択から見直す。色を変えないでください）。
  • 手がかり 1、2、9 → 色と書体を選び直す（ここは本当に配色と書体が問題です）。
  • 手がかり 4、5、6、7 → 飾りを取り除き、大きさ・太さ・余白による本物の階層に置き換えます。
• 直したら採点し直します。構図の手がかり（3、8、10）が残っているうちは、完了と言わないでください。それが原因であり、ほかはたいてい症状です。

診断と処置を分けるねらいはこうです。まず点検に文句を言わせ、そのうえで、言われたことだけを、言われた次元で直すためです。

タイポグラフィ

既存の書体の体系があるなら、それを使ってください。

なければ、成果物に合わせて意図を持って選びます。

• 読み物: セリフか人文的なサンセリフの見出しに、控えめなサンセリフの本文
• ソフトウェア・生産性: 端正なサンセリフで、数字の扱いに強いもの
• 高級感・ミニマル: ウェイトを絞り、余白の規律を強く
• 技術系: モノスペースは差し色として使い、全体には使わない
• スライド: 大きく、はっきり、高コントラスト

より良い選択肢があるなら、使い古された既定の書体は避けてください。

Web フォントを使うなら、ファミリーとウェイトの数を絞ります。

箱・アイコン・色を足す前に、書体で階層を作ってください。

色

まずブランドやデザインシステムの色を使います。

配色がないときは次のようにします。

• 小さな体系を定めます
• 中立色、面の色、文字色、控えめな文字色、境界線、アクセント、必要なら危険・成功を含めます
• 依頼が広い配色を求めないかぎり、主となるアクセントはひとつにします
• 自分で配色を作るなら、ブラウザの対応が許すかぎり oklch を使うと調和させやすいです
• 重要な文字と操作要素のコントラストを確認します

ゼロからたくさんの色を作り出さないでください。

レイアウトと構図

リズムを持ってデザインします。

• 大きさ
• 余白
• 密度
• 揃え
• 繰り返し
• 対比
• 中断

すべての節を同じカードの並びにしないでください。

プロダクトの UI では、飾りより理解の速さを優先します。

宣伝の面では、1 つの節で 1 つの考えが届くようにします。

ダッシュボードでは「データの盛りすぎ」を避けます。判断や行動の役に立つデータだけを出してください。

動き

動きは見せ場ではなく規律として使います。

よい動きは次のようなものです。

• 状態の変化を分かりやすくする
• 読み込み中の不安をやわらげる
• 画面と画面のつながりを見せる
• 操作に手ごたえを与える
• 控えめであり続ける

わるい動きは次のようなものです。

• 意味もなく繰り返す
• ユーザーを待たせる
• 自分に注意を引く
• 出来の悪い階層を覆い隠す

単純でないアニメーションでは prefers-reduced-motion を尊重してください。

画像とアイコン

渡された本物の画像があれば、それを使います。

素材がないときは次のようにします。

• すっきりした仮置きを使う
• 書体・レイアウト・抽象的な質感で代える
• 再現度が重要なら、本物の素材を求める

依頼そのものがイラスト制作でないかぎり、凝ったにせの SVG イラストを描かないでください。

一覧しやすくなるか、デザインシステムに合っている場合を除き、アイコンは避けてください。

ソースコードへの忠実さ

リポジトリの UI を再現したり拡張したりするときは、次の順で進めます。

1. リポジトリのツリーを見る
2. 実際の UI のソースファイルを特定する
3. テーマ・トークン・全体スタイル・コンポーネントのファイルを読む
4. 適切なところは正確な値をそのまま持ってくる
5. 余白、角丸、影、文言のトーン、密度、操作のパターンを合わせる
6. そのうえで、デザインしたり手を入れたりする

ソースファイルがあるのに、記憶を頼りに作らないでください。

GitHub の URL では、owner/repo/ref/path を正しく読み取り、関係するファイルを見てからデザインします。

資料や素材を読む

Markdown、HTML、CSS、JS、TS、JSX、TSX、JSON、SVG、プレーンテキストは、あるならそのまま読みます。

DOCX/PPTX/PDF は、手元に抽出ツールがあれば使います。なければ、書き出したテキストや画像をもらうようユーザーに頼むか、ほかに使える手段を取ります。

スケッチは、その JSON しか使えるものがない場合を除き、生の描画 JSON より縮小画像やスクリーンショットを優先します。

著作権と参考にするモデル

ある会社に固有の UI、独自のコマンド体系、ブランドの画面、そのままの視覚的な同一性は、ユーザーがその素材の権利をはっきり持っているのでないかぎり再現しないでください。

一般的なデザインの原則を取り出すのはかまいません。

• 雑然とさせない密度
• コマンド中心の操作
• モノクロにアクセント 1 色
• 読み物としての階層
• 分かりやすい空の状態
• 強力なキーボード操作

独自のレイアウトを複製したり、ブランドの画面をそのまま写したり、著作物を再現したりするのは認められません。

参考にするときは、その姿勢と原則を、独自のデザインへ作り変えてください。

検証

最終的な返答の前に、環境が許すかぎり検証します。

最低限は次のとおりです。

• 書いたパスにファイルが存在する
• HTML が最後まで保存されている
• 明らかな構文の問題を確認した

できればここまでやります。

• ブラウザのツールで開き、コンソールのエラーを見る
• 主要な画面幅でスクリーンショットを確認する
• 主要な操作を試す
• 明暗のテーマや派生形があれば試す
• 関係するなら画面幅の切り替わりを試す

環境の都合で検証が限られるなら、何を検証して何を検証していないかを正確に書いてください。

ファイルを実際に書いていないのに「完了」と言ってはいけません。

最終的な返答の形

最終的な返答は短くします。

入れるものは次のとおりです。

• 成果物のパス
• 中身
• 検証の状況
• 役に立つなら、次にすること

例を示します。

Created: /path/to/Prototype.html
It includes 3 layout variants, a Tweaks panel for density/theme, and responsive behavior.
Verified: file exists and opened cleanly in browser, no console errors.
Next: pick the strongest direction and I’ll tighten copy + motion.

持ち運べる冒頭プロンプトの型

Claude Design 風の依頼を CLI/API モードへ読み替えるときは、次のように考えます。

You are running in CLI/API mode, not hosted Claude Design. Ignore references to hosted-only tools or preview panes. Produce complete local design artifacts, usually self-contained HTML with embedded CSS/JS, and verify with available local tools before returning. Preserve the design process: gather context, define the system, produce options, avoid filler, and meet a high visual bar.

落とし穴

• ホスト版のツールスキーマを skill に貼り付けないでください。にせのツール呼び出しを招きます。
• 巨大な外部プロンプトを、実行に必須の文脈として skill から指し示さないでください。ずれの原因になります。
• 裏方のしくみを外すついでに、デザインの教義まで削ぎ落とさないでください。
• ユーザーが十分に方向を示しているのに、聞きすぎないでください。
• ブランドの文脈がないのに再現度の高い仕事をするとき、聞かなさすぎないでください。
• ありきたりな SaaS のレイアウトを出して、デザインしたと言わないでください。
• 実際にやっていないのに、ブラウザで検証したと言わないでください。