superdesign

Superdesign は、無限キャンバス上でデザインのインスピレーションを見つけ、デザイン案を生成したり反復改善したりするのに役立ちます。さまざまなデザインタスクに対応する複数の主要モデルを利用でき、並べて比較しながら検討できます。デザインに新しいビジュアル素材が必要な場合は、画像や動画の生成にも対応できます。

---

主なシナリオ（このスキルで対応する内容）

1. デザイン作業に向けてコードベースを分析する — superdesign init で再利用可能な UI コンテキストを .superdesign/init/ に構築します。INIT.md を参照してください。
2. UI をデザイン、再現、改善する — キャンバス上でページ、機能、フロー、新しい製品を作成します。SUPERDESIGN.md を参照してください。
3. 主要なデザインモデルを選択して比較する — list-models を実行してタスクに適したモデルを選択するか、複数のモデルを使って異なる方向性を個別に検討します。
4. デザインシステムと再利用可能なコンポーネントを作成する — ビジュアルの基盤を整え、パターンを抽出し、複数ページにまたがる一貫したエクスペリエンスをデザインします。
5. 公開中のウェブサイトや参照 URL をもとにデザインする — そのデザイン言語を抽出して適用します。WEBSITE.md を参照してください。
6. プレゼンテーションを作成またはエクスポートする — 編集可能なスライドのアウトラインを作成し、チャットで承認を得て、実際のプレゼンテーション案を生成します。スライドに適した編集を行うほか、依頼があり、対応可能な場合は編集可能な PPTX を再構成します。PRESENTATION.md を参照してください。
7. グラフィックを作成する — ポスター、表紙、SNS 投稿、サムネイル、チラシ、広告などを作成します。GRAPHIC.md を参照してください。
8. 補助画像や動画を生成する — 適切な場合はネイティブの画像生成を使用するか、Superdesign の生成モデルから選択します。ASSET_GENERATION.md を参照してください。
9. 既存の作業を続行または直接修正する — RESUME.md を使って保存済みの対象を再開するか、直接作成するのが適切な場合は design-with-your-model.md を使用します。

案を続行する場合は、SUPERDESIGN.md の ITERATION MODE ROUTING に従ってください。replace はバージョン履歴を残しながら選択した方向性を洗練します。branch は、ユーザーが比較を希望する代替案に限って使用します。

Step 0 — 環境の事前確認（CLI を使う前に必ず実施）

Superdesign はすべて CLI 経由で動作するため、シェルコマンドを実行できる必要があります。CLI を確認する前に、まずその機能を確認してください。

この環境でシェルコマンドを実行する方法がない場合（ターミナル／実行ツールがまったくない場合）、または最初の npx --yes @superdesign/cli@latest の事前確認が、コマンド実行機能そのものが利用できないために失敗した場合（実行環境からコマンドを実行できない、またはシェルが存在しないと報告された場合）は、そこで終了してください。再試行したり、その場しのぎの回避策を試したりしないでください。ユーザーには一度だけ伝え、実行環境に応じたメッセージを選んでください。

• Work Mode ツールのない標準の ChatGPT チャット — Work タブが解決策であるため、この文面をそのまま使用してください。

  Chat isn't supported by the Superdesign plugin. Please switch to the Work tab and paste this prompt in for the full experience.
  

• その他の実行環境（シェルが利用できない、または無効になっているコーディングエージェント）— ChatGPT 向けの文面は送らないでください。切り替え先の Work タブはありません。Superdesign はシェル経由で CLI を実行すること、このセッションではシェルコマンドを実行できないことを明確に伝え、シェルを利用できるセッションで再実行するか、https://superdesign.dev のウェブアプリでデザインするよう案内してください。

ステップ 1 — 分析するコードベースはありますか？

開始方法は 2 つあります。初期化や設計作業を始める前に、この簡単で確実なチェックを行い、どちらかを選んでください。

意味のあるコードベースがない（空のワークスペース、作業用／サンドボックスディレクトリ、フロントエンドコードがない）— 次の条件をすべて満たす場合、ワークスペースを「コードベースなし」として扱います。

• .superdesign/init/ のファイルがまだ存在しない、かつ
• フロントエンド依存関係を含む依存関係マニフェストがない（package.json が存在しない、または package.json の依存関係にフロントエンドフレームワーク／UI ライブラリ（react、vue、svelte、angular、next、nuxt、astro など）が含まれていない）、かつ
• フロントエンドのソースが見つからない（.tsx／.jsx／.vue／.svelte ファイル、ルートの index.html と style.css のような .html／.css ファイル、または UI ファイルを含む src/／app/／components/ ディレクトリを簡単に検索しても、何も見つからない）。

→ リポジトリの初期化は完全にスキップしてください。空のサンドボックスを「分析」してはいけません。また、存在しないリポジトリを指定するようユーザーに求めてはいけません。代わりに、まず会話を通じてデザインの背景情報を集めてください。何を作りたいのか、対象のオーディエンス／プラットフォーム、スタイル／ブランドの好み、参考にしたいデザインやインスピレーションについて尋ねてください。その会話内容をもとに、SUPERDESIGN.md の BRAND NEW PROJECT パスでデザインしてください。

実際のコードベースがある（フロントエンドコード、または既存の .superdesign/init/ がある）— デザインを始める前に、リポジトリの初期化を少なくとも 1 回完了している必要があります。ステップ 1.5 で有効な初期化済みターゲットを再利用し、初期化が未完了の場合、またはウォーム状態を利用できない場合に限り、完全な分析を実行してください。

例外 — 単独の抽出： URL からサイトのデザイン DNA を抽出する、または design-system.md を設定／更新することだけがタスクの場合（extract-website → design-system.md、デザイン生成なし）は、リポジトリの初期化を行わずに実行してください（レシピについては WEBSITE.md を参照してください）。外部サイトのスタイルを抽出する際に、ユーザーのコードベースを分析する必要はありません。ただし、既存コードベースの UI 向けデザインを生成する前（既存ページの再現／再デザイン）には初期化が必要です。

例外 — グラフィック： ポスター／マーケティング素材（シナリオ 7）は、実際のコードベースがあっても初期化をスキップしてください。概要にスタイルが含まれており、初期化で得られる情報の大半（コンポーネント、レイアウト、ルート、ページ）は、固定キャンバスのアートワークには関係しません。グラフィックの概要を確認する際に、そのアートワークをこのリポジトリの製品に合わせるかどうかを尋ねます（GRAPHIC.md のステップ 1）。ブランドに合わせる場合に限り「はい」を選ぶと、デザインシステム／ブランドのコンテキストを取り込みます。そのコンテキストがまだ存在しない場合のみ、先に初期化を実行してください。

例外 — プレゼンテーション： スライドデッキ（シナリオ 6）は、通常 UI リポジトリの初期化をスキップします。ルート、コンポーネント、ページの依存関係ツリーは、デッキ作成に役立たないためです。PRESENTATION.md に従ってください。ユーザーが製品に合わせたプレゼンテーションを希望する場合は、関連性の高い製品ドキュメント、デザインシステムのコンテキスト、ブランドアセットを使用してください。コードベースのブランドとの一致が必要で、利用可能なブランド／テーマのコンテキストがまだない場合に限り、初期化を実行してください。

例外 — 画像／動画生成： 単独の生成アセット（シナリオ 8）は、実際のコードベースがあっても初期化をスキップします。ASSET_GENERATION.md を読み、依頼されたアセットに実際に必要なプロジェクト、ブランド、参考資料、または用途のコンテキストだけを集めてください。アセットの作成が、より大きな UI、プレゼンテーション、またはグラフィックデザインのタスクの一部である場合は、そのタスクの通常の初期化／概要確認の手順に従い、新しいビジュアルが必要になった時点でのみアセット生成を使用してください。

ステップ 1.5 — 再発見する前に再開する（実際のコードベースの UI パス）

init アーティファクトやソースファイルを読む前に、.superdesign/resume.json で要求されたルート／機能を確認してください。一致する対象がある場合、ユーザーが「続けて」「変更して」「再設計して」と言ったか、あるいは「ダッシュボードをもっと暗くして」のような直接的な指示だけを出したかにかかわらず、デフォルトで RESUME.md に従います。意図を表す言い回しによって、ウォーム再開とコールドルーティングが決まることはありません。

保存された対象の信頼性と構造のチェックを最初に適用してください。安全で、構造的に有効な対象については、保存済みのプロジェクト、ドラフト、コンポーネントレコード、デザインの方向性、および正確な --context-file バンドルを再利用します。ハッシュが一致する場合はウォーム再開に進み、不一致の場合はコールド再発見を行わずに段階的な更新を行います。リクエストの処理に、アクティブなドラフトのメタデータに含まれていないコードの理解が必要な場合は、RESUME.md の対象を絞ったコンテキスト拡張ルールを使用してください。そのリクエストを理解するためだけに、完全な再発見をやり直してはいけません。

要求された対象に該当する保存済みエントリがない場合、ユーザーが新たな真実の情報に基づいてやり直すことを明示的に求めた場合、状態が安全でない／構造的に無効な場合、または対象を絞った修復によって段階的な修復では対応できないほど古いと判断された場合に限り、コールドパスを使用してください。新しいエージェントセッション、異なる言い回し、フィンガープリントの不一致だけでコールドルーティングに切り替えてはいけません。

初期化：リポジトリの分析（実際のコードベースのパス）

実際のコードベースが存在し（ステップ 1 に従い、ステップ 1 の例外が適用されない場合）、init が完了していない場合は、自動的に次の手順を必ず実行してください。

1. .superdesign/init/ ディレクトリを作成します
2. INIT.md を読みます
3. その指示に従ってリポジトリを分析し、コンテキストファイルを書き出します

init 完了の判定（あらゆる場面で使う、判定可能な単一ルール）： 以下に名前を挙げる 6 つのファイルがすべて存在し、かつ空でない場合に限り、init は完了とみなされます。いずれかのファイルが欠けているディレクトリや、空のファイル（例：init が途中で中断された場合）を含むディレクトリは、完了していません。完全な init を再実行し、6 つのファイルすべてを再生成してください。既存ファイルの上書きは想定されており、問題ありません。

ユーザーに手作業でこれを行うよう求めてはいけません。自動で実行してください。

Init ファイル（コールド／古いコンテキストのパス）

対象を初めてデザインする場合、または RESUME.md によって保存されたコンテキストが古い／使用できないと判定された場合は、対象のコンテキストを収集する前に 6 つのファイルすべてを読んでください。

• components.md — 完全なソースコードを含む、共有 UI プリミティブ
• layouts.md — 共有レイアウトコンポーネント（ナビゲーション、サイドバー、ヘッダー、フッター）
• routes.md — ページ／ルートの対応付け
• theme.md — デザイントークン、CSS 変数、Tailwind 設定
• pages.md — ページコンポーネントの依存関係ツリー（各ページで必要なファイル）
• extractable-components.md — 再利用可能な DraftComponents として抽出できるコンポーネント

有効なウォーム再開では、6 つのファイルがすべて存在し、空でないことだけを確認してください。内容を読んではいけません。対象の保存済みコンテキストバンドルを再利用し、RESUME.md が対象を絞ったコンテキスト拡張を明示的に指示した場合に限り、選択したソースファイルだけを読みます。

既存ページをコールドデザインする場合： まず pages.md で、そのページの依存関係ツリー、つまり --context-file の候補ファイルを確認します。ペイロードが 400 エラーにならないよう、SUPERDESIGN.md のペイロード上限ルールに従って渡してください。次に globals.css のトークン、tailwind.config、design-system.md も追加します。最終的な選択内容は RESUME.md に従って保存してください。

Superdesign CLI（あらゆるコマンドの前に必ず使用）

重要：必要に応じて npx --yes @superdesign/cli@latest で CLI を実行してください。各セッションはコマンド単体で開始します。これが事前チェックです。

1. 事前チェックを一度実行します：

   npx --yes @superdesign/cli@latest
   

   コマンド単体を実行すると、CLI が実行できること、auth: ステータス行（authenticated as team "…" または not authenticated — run superdesign login）、最近のプロジェクト一覧を一度に確認できます。有効なウォーム再開の場合は、保存済みの projectId／activeDraftId をそのまま使用します。それ以外の場合は、既存のプロジェクトを再利用するか create-project を実行するかを判断する際に、最近のプロジェクト一覧を確認します。永続的な再開状態が利用できないか拒否された場合に、下書き ID を復元するには fetch-design-nodes --project-id <id> を代替手段として使用します。

2. auth: 行が未認証を示している場合は、実際のコマンドを実行する前に、ただちにログインします：

   npx --yes @superdesign/cli@latest login
   

   ログインが正常に完了するまで待ってから、続行してください。

3. 実行するコマンドには、同じ npx --yes @superdesign/cli@latest のプレフィックスを付けます。処理の途中でセッションが期限切れになることもあります。後で認証／ログインエラーが発生した場合は、以下の失敗時の手順に従ってください。

ユーザーがすでにログインしていると決めつけないでください。推測したり実際のコマンドで確認したりせず、事前チェックの auth: 行を確認してください。

コマンドが失敗した場合

• 認証／ログインエラー（CLI は実行されたものの、セッションが拒否された場合）：上記の login を実行してから、実行するコマンドを一度だけ再試行します。ログイン自体が失敗した場合（ヘッドレス／ブラウザーなしの認証、期限切れのフロー、ユーザーによる拒否）は、ユーザーにはっきり伝えて停止してください。再試行を続けたり、独自の方法を試したりしないでください。
• extract-website が失敗する、またはタイムアウトする場合（約 60～120 秒かかることがあります）：一度だけ再試行します。それでも失敗する場合は、抽出なしで続行する（会話や既存のデザインシステムをもとにデザインする）方法を提示し、処理を止めないでください。
• **一般的なルール：**失敗したコマンドの再試行は最大一度までです。create-design-draft または iterate-design-draft が再試行後も失敗する場合は、design-with-your-model.md に従って続行してください。それ以外の場合は、失敗を報告して停止します。

コマンドの例

必ず、次のように完全なオンデマンド実行プレフィックスを使用してください：

npx --yes @superdesign/cli@latest create-project --title "X"

コマンド全体の呼び出し例は、実際に使用する箇所に記載されています。SUPERDESIGN.md の SOP と GRAPHIC.md のグラフィック手順を参照してください。フラグの一覧は <command> --help で確認できます。また、ヘルプには記載されていない注意点については、SUPERDESIGN.md の COMMAND CONTRACT を参照してください。

CLI のデフォルト出力は、エージェントに最適化されています（簡潔な TOON と、次の手順を示す help[] ヒント）。完全な機械可読ペイロードが必要な場合に限り、--json を追加してください。

キャンバス URL の提示

各プロジェクト／下書きコマンドのデフォルト出力には、canvas: リンク（プロジェクトのキャンバス、https://superdesign.dev/teams/<teamId>/projects/<projectId>）が含まれます。また、下書きの場合は preview: リンク（https://superdesign.dev/preview/draft/<draftId>）も含まれます。これらはコマンド出力から取得してください。手動で作成しないでください（ID はサーバーによって生成されます）。

プロジェクトまたはデザイン下書きの作成後、および自然なレビューのタイミング（iterate-design-draft または execute-flow-pages の実行後）に、canvas URL をクリック可能なリンクとしてユーザーに提示し、開いてデザインが生成される様子を確認したり、フィードバックを残したりするよう案内してください。キャンバス URL に ?live=1 を追加すると、下書きが生成される様子を表示するライブビューが開きます。

ブラウザーの選択

create-project はデフォルトで、ユーザーのブラウザーにキャンバスを自動で開きます。この設定はそのままにし、キャンバスが開いたことを canvas URL のクリック可能なリンクとともに伝えてください。ユーザーが操作できるブラウザーがない場合（CI、ヘッドレス環境）に限り、--no-open を指定してください。

画像とローカルアセット

生成する前に、ユーザーが添付した画像、またはこの目的に直接関係するローカルアセットのみを確認してください。SUPERDESIGN.md の ASSET PURPOSE ROUTING に従ってください。一時的なスクリーンショットや参考画像はキャンバスの参照ノードに、ロゴ、フォント、再利用可能なブランドイメージは Brand Assets に、最終成果物に使う画像はプロジェクトコンテンツに配置します。生成、反復、フロー生成で実際のピクセルデータを使えるよう、返されたノード ID または Brand Asset キーを --reference-id で渡してください。元のコンポーネントまたは依頼されたデザインにロゴの配置場所がある場合は、必ず SUPERDESIGN.md の Logo invariant を適用してください。適切な Brand Asset のロゴが利用できる場合は、再利用可能なコンポーネント内も含め、該当箇所にロゴを表示してください。頭文字、絵文字、汎用マーク、独自に作成した SVG、テキストのみで代用してはいけません。公開画像の URL が直接貼り付けられた場合、またはウェブサイトが参考資料として指定された場合は、WEBSITE.md を読み、選択したビジュアルのみを同じアップロードフローで取り込んでください。リポジトリを一括アップロードしてはいけません。また、ローカルファイルシステムのパスをドラフト HTML に含めてはいけません。

生成後：次の作業を提案する

すべての画面で、最後に必ず、次の作業を提案する短く親しみやすい一言を添えてください。今回作成したものに合わせた具体的な選択肢を2～3個挙げ、質問は1つにしてください。一般的な選択肢を並べるのではなく、たとえば、別のヒーロー画像やキービジュアルの方向性を試す、別のレイアウトや構成を試す、あるいは追加のバリエーションやアセット案をいくつかサプライズとして生成する、といった選択肢を提案します。生成のたびにクレジットを消費するため、ユーザーが選択してから生成してください。

（グラフィックは、この締めくくりの前に、1ラウンドのビジュアル自己レビューを実施します。GRAPHIC.md の Step 5 を参照してください。UI のドラフトはキャンバス上でユーザーがレビューします。）

仕組み

SUPERDESIGN.md を読み、その指示に従ってください。

画像または動画の生成を依頼された場合は、ASSET_GENERATION.md を読んでください。該当するシナリオでは、上記のリンク先にある他のシナリオ別リファレンスも読み込んでください。