design-studio

デザインスタジオ

統合デザインスキル。1つのエントリーポイント、2つのエンジン、1つのデザインシステムファイル。

DESIGN.md：デザインシステムファイル

再利用可能なビジュアルルールを確立または変更する場合は、DESIGN.md を作成または更新します。ルールを変更しないレビューや小規模な編集では、既存のデザインコンテキストを使用し、依頼されたレビューまたは編集を行います。デザイン作業の前に、既存の DESIGN.md を読みます。

形式

Google DESIGN.md spec に従います。構成：

---
version: alpha
name: <Project Name>
colors:
  primary: "#hex"
  secondary: "#hex"
  tertiary: "#hex"
  neutral: "#hex"
typography:
  h1:
    fontFamily: <Font Name>
    fontSize: 48px
    fontWeight: 600
    lineHeight: 1.1
  body-md:
    fontFamily: <Font Name>
    fontSize: 16px
    fontWeight: 400
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  lg: 32px
components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "#fff"
---

## Overview
<Brand personality, audience, emotional intent>

## Colors
<Palette rationale and usage rules>

## Typography
<Type hierarchy and pairing logic>

## Layout
<Grid system, spacing rhythm>

## Elevation & Depth
<Shadows, layers, or flat alternatives>

## Shapes
<Corner radius language>

## Components
<Button, card, input, chip specs with token refs>

## Do's and Don'ts
<Guardrails>

DESIGN.md のライフサイクル

シナリオ	対応
DESIGN.md が存在せず、タスクでビジュアルルールを確立する	shared/DESIGN-template.md をプロジェクトルートにコピーし、DESIGN.md に名前を変更して、セッション中に内容を記入します
DESIGN.md が存在し、ユーザーが「redesign」 / 「重新設計」と言っている	まず shared/redesign-protocol.md を実行します — Preserve と Overhaul を判別し、現状を監査してから、それに応じて DESIGN.md を書き換えます
DESIGN.md が存在し、ユーザーが変更を希望している	まず読みます。その後、特定のセクションを拡張または変更します。変更しないトークンは維持します。
DESIGN.md が存在し、同じプロジェクトで新しいタスクを行う	まず読みます。ユーザーが別途指示しない限り、既存のトークンとの一貫性を保ちます

厳守事項：作業を始める前に、必ず既存の DESIGN.md を読みます。デザインはゼロからではなく、すでにあるものを基に発展させます。

プロセスファイルの保存場所

プロジェクトルートに置くデザインファイルは DESIGN.md のみです。デザインセッションで作成するすべての作業ファイルは docs/design/ に保存します：

ファイル	エンジン	内容
docs/design/decisions.md	cinematic-ui	フェーズ 1 — ディレクター、映画の参照、シェル禁止リスト、独自性の監査
docs/design/storyboard.md	cinematic-ui	フェーズ 2 — シーンごとの構成案
docs/design/compiled-spec.md	cinematic-ui	フェーズ 3 — 唯一の実装ソース（ウェブ）
docs/design/slide-spec.md	cinematic-ui	フェーズ 3 — PPTX では compiled-spec.md の代わりに使用
docs/design/product-facts.md	practical	デザイン前に収集した、検証済みの製品情報
docs/design/brand-spec.md	shared	固定されたブランドアセットのパスと抽出した色

ディレクトリが存在しない場合は作成します。このスキルとサブスキル内に単独で記載されているファイル名は、docs/design/ を基準に解決します。

これらはセッション中の作業状態であり、プロジェクトアセットではありません。リポジトリのルートを開いたユーザーに見えるのは DESIGN.md とユーザー自身のファイルであり、1回のデザイン作業で作られた6つの中間成果物ではありません。

ルートの選択

DESIGN.md を読んだ後（または作成を決めた後）、適切なエンジンを選びます。

シグナル	エンジン	サブスキル
監督、映画、シネマ、エディトリアルな雰囲気	Cinematic	cinematic-ui/GUIDE.md
ビジュアルな物語性を備えたハイエンドな静的ウェブサイト	Cinematic	cinematic-ui/GUIDE.md
プロトタイプ、モックアップ、インタラクティブなデモ	Practical	practical/GUIDE.md
PPT、スライド、デック、簡報	Practical	practical/GUIDE.md
アニメーション、モーション、MP4、GIF	Practical	practical/GUIDE.md
専門家によるレビュー、批評、採点	Practical	practical/GUIDE.md
インフォグラフィック、データの可視化	Practical	practical/GUIDE.md
アプリ／iOS／Android のプロトタイプ	Practical	practical/GUIDE.md
すばやくデザイン案を作成（3つの方向性）	Practical	practical/GUIDE.md
曖昧な依頼／「いい感じのものを作って」	Practical（フォールバックアドバイザー）	practical/GUIDE.md
特定のブランドに関するブランド素材	どちらでも可 — 共通のブランドプロトコルを使用	出力の種類による
ゼロからの新しいブランドアイデンティティ（ロゴのコンセプト立案、ブランドキットのボード）	Practical	practical/GUIDE.md → practical/references/brand-identity-board.md
高コンバージョンのLP（明示的なCTA／価値提案／コンバージョン目標あり）	引き継ぎ	landing-page-studio スキル — このスキルの共通ルールとスタイルライブラリを読み込んだ後、独自のコンバージョンワークフローを実行します
ウェブベースのデック — ライブプレゼン、発表者モード、URL へのデプロイ（編集可能な PPTX ではないもの）	引き継ぎ	open-slide-studio スキル — このスキルは DESIGN.md とスタイルの方向性を提供し、open-slide ワークスペース、作成の引き継ぎ、納品は同スキルが担当します

曖昧な依頼の場合：次の質問を1つだけします。「ビジュアルの参考として、思い浮かべている映画や監督はありますか？それとも、こちらから方向性を提案しましょうか？」

セッションの流れ（このファイルがすべてのセッションを進行します）

1. コンテキスト — DESIGN.md が存在する場合は読み込みます（上記のライフサイクル表を参照）。タスクでビジュアルルールを定める場合は、shared/DESIGN-template.md を基に作成します。

2. 共通ルール — shared/anti-slop.md、shared/hard-rules.md、shared/guardrails.md、shared/brand-asset.md、shared/verification.md を読み込みます。これらはすべてのルートに適用されます。

3. ルートの選択 — ルートの選択表からエンジンを選び、そのエンジンの GUIDE だけを読み込んでワークフローを実行します。

   • Cinematic → cinematic-ui/GUIDE.md — 監督＋映画 → シネマティックな文法 → ウェブ構成の順に進めます。4つのフェーズは、意思決定 → ストーリーボード → コンパイル済み仕様 → 構築です。ランディングページ、ブランドサイト、エディトリアルレイアウトに最適です。参考資料：cinematic-ui/references/（200人の監督、ヒーローの類型、構図、カラーグレーディング）。
   • Practical → practical/GUIDE.md — タスクルーター → ブランドプロトコル → フォールバックアドバイザー → ジュニアデザイナーの順に進めます。プロトタイプ、プレゼンテーション、アニメーション、レビュー、インフォグラフィックに最適です。参考資料：practical/references/（40種類のスタイル、アニメーションの落とし穴、スライドデック、批評ガイド）。

   GUIDE は実行マニュアルであり、独立したスキルではありません。読み込み済みの共通ルールと DESIGN.md のコンテキストに従って、このセッション内で実行されます。手順4〜6はこのファイルが引き続き管理します。

4. デザイン中 — 新たに追加または変更した再利用可能な色、タイポグラフィ、間隔、コンポーネントのルールを DESIGN.md に記録します。

5. 納品前 — shared/verification.md を実行します。ビジュアルルールを変更した場合は、最終デザインが反映されるよう DESIGN.md を更新します。

6. 再開時 — 最初に DESIGN.md を読み込みます。やり直すのではなく、内容を拡張します。

ハイブリッドタスク

両方のエンジンが該当する場合は、主な出力に合うエンジンを選びます。必要に応じて、もう一方の原則を参照します。ワークフローを混在させてはいけません。

PPTX

どちらのエンジンも PPTX を生成できます。Cinematic はネイティブに PptxGenJS を使用します。Practical は HTML デックを作成し、PptxGenJS でエクスポートします。選択したルートの PPTX リファレンスを読み込みます。