stitch-design-taste について
Google Stitch の画面生成向けに `DESIGN.md` を作成するスキルです。プロジェクトのビジュアル方針を、色、タイポグラフィ、コンポーネント、レイアウト、レスポンシブ対応、モーション、アンチパターンの具体的なルールにまとめます。
主な機能
- 01Stitch 向けの意味的な `DESIGN.md` 生成
- 02色とタイポグラフィのルール指定
- 03コンポーネントの挙動とレイアウト原則の記述
- 04レスポンシブ対応とモーションの指針記載
- 05デザイン上のアンチパターンの明示
活用シーン
- 01Stitch の画面生成に向けたデザイン指針の準備
- 02プロジェクトのビジュアル方針をデザインルールに整理
- 03オプションの MCP サーバーを介した Cursor、Antigravity、Gemini CLI 向けの Stitch 指針提供
MCP 対応
Cursor、Antigravity、Gemini CLI とのプログラム連携に、オプションの Stitch MCP サーバーを利用できると記載されています。このスキル自体の機能は `DESIGN.md` の生成です。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ rheinmir/ setup --skill stitch-design-tasteインストール後、Claude Code で/stitch-design-tasteを入力して読み込まれたか確認します。
詳細
[[design-foundation]]を土台とします — 6つの規律とhallmarkのslop-testは共通の土台です(交渉不可)。このスキルはその上に独自の味わいを加えるものであり、土台を置き換えるものではありません。
Stitch Design Taste — セマンティックデザインシステムスキル
概要
このスキルは、Google Stitchの画面生成に最適化されたDESIGN.mdファイルを生成します。実戦で磨かれたアンチスロップなフロントエンドエンジニアリングの指針を、Stitch独自のセマンティックデザイン言語へと変換します。つまり、StitchのAIエージェントが解釈し、プレミアムでありきたりではないインターフェースを生成できるよう、具体的な値を組み合わせた、自然言語による説明的なルールを作成します。
生成されたDESIGN.mdは、厳選された主体性の高いデザイン言語に沿って新しい画面を生成するようStitchに指示するための、唯一の信頼できる情報源となります。Stitchは、特定のカラー値、タイポグラフィの仕様、コンポーネントの動作を補足情報とする**「ビジュアルの説明」**を通じてデザインを解釈します。
前提条件
- labs.google.com/stitchからGoogle Stitchを利用できること
- 任意:Cursor、Antigravity、Gemini CLIとプログラムから連携するためのStitch MCP Server
目標
次の項目を定義したDESIGN.mdファイルを生成します。
- ビジュアルの雰囲気 — ムード、密度、デザイン哲学
- カラー調整 — ニュートラルカラー、アクセントカラー、使用禁止のパターンと16進数コード
- タイポグラフィの設計 — フォントスタック、スケールの階層、アンチパターン
- コンポーネントの動作 — ボタン、カード、入力欄とインタラクションの状態
- レイアウトの原則 — グリッドシステム、間隔の考え方、レスポンシブ対応の方針
- モーションの考え方 — アニメーションエンジンの仕様、ばねの物理特性、継続的なマイクロインタラクション
- アンチパターン — AIデザインでよくある使い古された表現の明示的な禁止リスト
分析と統合の指示
1. 雰囲気を定義する
対象プロジェクトの意図を評価します。次の好みの尺度から、雰囲気が伝わる形容詞を使います。
- 密度:「アートギャラリーのようにゆったり」(1~3)→「日常使いのアプリらしくバランスが取れている」(4~7)→「コックピットのように情報量が多い」(8~10)
- 変化:「予測しやすく対称的」(1~3)→「ずらしを活かした非対称」(4~7)→「アーティスティックでカオス」(8~10)
- モーション:「静的で控えめ」(1~3)→「滑らかなCSSアニメーション」(4~7)→「映画のような振り付け」(8~10)
デフォルトの基準値は、変化8、モーション6、密度4です。ユーザーが説明する雰囲気に応じて柔軟に調整します。
2. カラーパレットを割り当てる
各カラーに、説明的な名前+16進数コード+機能上の役割を指定します。
必須の制約:
- アクセントカラーは最大1色。彩度は80%未満
- 「AIパープル/ブルーネオン」の美学は厳禁です。紫のボタンのグローやネオンのグラデーションは禁止します
- 高コントラストの単一アクセントを組み合わせた、完全なニュートラルのベースカラー(Zinc/Slate)を使います
- 出力全体を通じてパレットは1種類に統一します。暖色系と寒色系のグレーを混在させないでください
- 純粋な黒(
#000000)は使わず、オフブラック、Zinc-950、またはチャコールを使います
3. タイポグラフィのルールを定める
- ディスプレイ/見出し: 字間を詰め、スケールを抑えます。大げさにしません。巨大な文字サイズだけに頼らず、ウェイトと色で階層を表現します
- 本文: ゆったりとした行間にし、1行あたり最大65文字とします
- フォント選定: プレミアムまたはクリエイティブな文脈では
Interは禁止です。Geist、Outfit、Cabinet Grotesk、Satoshiなど、独自の個性を持つフォントを使います - セリフ体の禁止: 一般的なセリフフォント(
Times New Roman、Georgia、Garamond、Palatino)は禁止です。エディトリアルまたはクリエイティブな文脈でセリフ体が必要な場合は、特徴的なモダンセリフ体であるFraunces、Gambarino、Editorial New、Instrument Serifのみを使います。ダッシュボードやソフトウェアUIでは、セリフ体は常に禁止です - ダッシュボードの制約: サンセリフ体の組み合わせのみを使います(
Geist+Geist MonoまたはSatoshi+JetBrains Mono) - 高密度時の例外: 密度が7を超える場合、すべての数値に等幅フォントを使います
4. ヒーローセクションを定義する
ヒーローは第一印象を決めるものであり、創造的で目を引き、ありきたりなものにならないようにします。
- インライン画像タイポグラフィ: 見出しの単語や文字の間に、小さく文脈に合った写真やビジュアルを直接埋め込みます。画像は文字の高さに合わせてインラインで配置し、角を丸くして、視覚的な句読点として機能させます。これが特徴的なクリエイティブ手法です
- 重なり禁止: テキストを画像や他のテキストに重ねてはいけません。すべての要素に、それぞれ明確な空間を割り当てます
- 埋め草テキスト禁止: 「スクロールしてご覧ください」「下にスワイプ」、スクロール矢印アイコン、跳ねるシェブロンは禁止です。コンテンツ自体が自然にユーザーを引き込むようにします
- 非対称の構成: ばらつきが4を超える場合、中央揃えのヒーローレイアウトは禁止です
- CTAは控えめに: 主要CTAは最大1つにします。「詳細はこちら」のような副次的なリンクは設けません
5. コンポーネントのスタイルを説明する
各コンポーネントの種類について、形状、色、影の深さ、インタラクションの動作を説明します。
- ボタン: アクティブ状態で、押し込まれるような触覚フィードバックを与えます。ネオンの外側グローは使いません。カスタムマウスカーソルも使いません
- カード: 高さの違いで階層を表現できる場合にのみ使用します。影の色合いは背景の色相に合わせます。高密度のレイアウトでは、カードの代わりに上罫線の区切りや余白を使います
- 入力欄/フォーム: ラベルは入力欄の上に配置し、補足テキストは任意、エラーテキストは下に配置します。間隔は標準的なものにします
- 読み込み状態: レイアウトに合った寸法のスケルトンローダーを使います。一般的な円形のスピナーは使いません
- 空の状態: データの入力方法が伝わるよう、構成された表示にします
- エラー状態: 明確なエラー表示をインラインで行います
6. レイアウトの原則を定義する
- 要素を重ねてはいけません。すべての要素に、それぞれ明確な空間を割り当てます。絶対配置したコンテンツを積み重ねてはいけません
- ばらつきが4を超える場合、中央揃えのヒーローセクションは禁止です。画面分割、左揃え、または非対称の余白を使います
- 横並びの「同じ幅のカード3枚」による一般的な機能紹介の行は禁止です。2列のジグザグ配置、非対称グリッド、または横スクロールを使います
- Flexboxの計算よりCSS Gridを優先します。
calc()を使った割合調整のハックは使いません - 最大幅の制約(例:中央揃えの1400px)を使ってレイアウトを収めます
- 高さが画面いっぱいのセクションには
min-h-[100dvh]を使います。h-screenは使いません(iOS Safariで致命的なジャンプが発生します)
7. レスポンシブルールを定義する
すべてのデザインは、あらゆるビューポートで適切に動作する必要があります。
- モバイルファーストでの折りたたみ(768px未満): 複数列のレイアウトはすべて1列に折りたたみます。例外はありません
- 横スクロール禁止: モバイルで横方向にはみ出すことは重大な不具合です
- タイポグラフィの拡大縮小: 見出しは
clamp()で拡大縮小します。本文テキストの最小サイズは1rem/14pxです - タッチターゲット: すべてのインタラクティブ要素のタップ領域を最低
44pxにします - 画像の動作: インライン画像タイポグラフィの画像(単語の間に配置された写真)は、モバイルでは見出しの下に配置します
- ナビゲーション: デスクトップの横型ナビゲーションは、シンプルなモバイルメニューに折りたたみます
- 間隔: セクション間の縦方向の間隔は、比率に応じて縮小します(
clamp(3rem, 8vw, 6rem))
8. モーションの方針を定める
- デフォルトはスプリング物理:
stiffness: 100, damping: 20に設定し、高級感と重量感を出します。リニアなイージングは使いません - 継続的なマイクロインタラクション: アクティブなコンポーネントには、無限ループの状態(パルス、タイプライター、浮遊、きらめき)を持たせます
- 段階的な演出: リストを一度に表示してはいけません。カスケード遅延を使って、滝のように順次表示します
- パフォーマンス: アニメーションには
transformとopacityのみを使います。top、left、width、heightはアニメーションさせません。グレイン/ノイズフィルターは固定の疑似要素にのみ適用します
9. アンチパターンの一覧(AI らしさが出る要素)
これらを DESIGN.md に明示的な「絶対にしない」ルールとして記載します。
- 絵文字は一切使用しない
Interフォントは使用しない- 汎用的なセリフフォント(
Times New Roman、Georgia、Garamond)は使用しない — 必要な場合に限り、個性のあるモダンなセリフフォントを使用する - 純粋な黒(
#000000)は使用しない - ネオン/外側のグローシャドウは使用しない
- 彩度が高すぎるアクセントカラーは使用しない
- 大きな見出しにグラデーションテキストを過剰に使用しない
- カスタムマウスカーソルは使用しない
- 要素を重ねない — 常に空間を明確に分ける
- 3 列均等のカードレイアウトは使用しない
- 汎用的な名前(「John Doe」、「Acme」、「Nexus」)は使用しない
- 偽の端数のない数値(
99.99%、50%)は使用しない - AI によるコピーライティングでありがちな決まり文句(「高める」、「シームレス」、「解き放つ」、「次世代」)は使用しない
- 埋め草の UI テキスト(「スクロールして探索」、「下にスワイプ」、スクロール矢印、跳ねるシェブロン)は使用しない
- 壊れた Unsplash リンクは使用しない —
picsum.photosまたは SVG アバターを使用する - 中央揃えのヒーローセクションは使用しない(多様性の高いプロジェクトの場合)
出力形式(DESIGN.md の構成)
# Design System: [Project Title]
## 1. Visual Theme & Atmosphere
(Evocative description of the mood, density, variance, and motion intensity.
Example: "A restrained, gallery-airy interface with confident asymmetric layouts
and fluid spring-physics motion. The atmosphere is clinical yet warm — like a
well-lit architecture studio.")
## 2. Color Palette & Roles
- **Canvas White** (#F9FAFB) — Primary background surface
- **Pure Surface** (#FFFFFF) — Card and container fill
- **Charcoal Ink** (#18181B) — Primary text, Zinc-950 depth
- **Muted Steel** (#71717A) — Secondary text, descriptions, metadata
- **Whisper Border** (rgba(226,232,240,0.5)) — Card borders, 1px structural lines
- **[Accent Name]** (#XXXXXX) — Single accent for CTAs, active states, focus rings
(Max 1 accent. Saturation < 80%. No purple/neon.)
## 3. Typography Rules
- **Display:** [Font Name] — Track-tight, controlled scale, weight-driven hierarchy
- **Body:** [Font Name] — Relaxed leading, 65ch max-width, neutral secondary color
- **Mono:** [Font Name] — For code, metadata, timestamps, high-density numbers
- **Banned:** Inter, generic system fonts for premium contexts. Serif fonts banned in dashboards.
## 4. Component Stylings
* **Buttons:** Flat, no outer glow. Tactile -1px translate on active. Accent fill for primary, ghost/outline for secondary.
* **Cards:** Generously rounded corners (2.5rem). Diffused whisper shadow. Used only when elevation serves hierarchy. High-density: replace with border-top dividers.
* **Inputs:** Label above, error below. Focus ring in accent color. No floating labels.
* **Loaders:** Skeletal shimmer matching exact layout dimensions. No circular spinners.
* **Empty States:** Composed, illustrated compositions — not just "No data" text.
## 5. Layout Principles
(Grid-first responsive architecture. Asymmetric splits for Hero sections.
Strict single-column collapse below 768px. Max-width containment.
No flexbox percentage math. Generous internal padding.)
## 6. Motion & Interaction
(Spring physics for all interactive elements. Staggered cascade reveals.
Perpetual micro-loops on active dashboard components. Hardware-accelerated
transforms only. Isolated Client Components for CPU-heavy animations.)
## 7. Anti-Patterns (Banned)
(Explicit list of forbidden patterns: no emojis, no Inter, no pure black,
no neon glows, no 3-column equal grids, no AI copywriting clichés,
no generic placeholder names, no broken image links.)
ベストプラクティス
- 具体的に記述する:「ディープチャコールインク(#18181B)」のように記載し、「暗いテキスト」だけで済ませない
- **機能を明確にする:**各要素の用途を説明する
- **一貫性を保つ:**ドキュメント全体で同じ用語を使用する
- **正確に記述する:**正確な HEX コード、rem 値、ピクセル値を括弧内に記載する
- **明確な方針を示す:**これは中立的なテンプレートではありません — 特定のプレミアムな美的スタイルを徹底します
成功のためのヒント
- 雰囲気から始める — トークンの詳細を記述する前に、全体の印象を把握する
- パターンを探す — 一貫した余白、サイズ、スタイルを特定する
- 意味を意識する — 色の名前は見た目だけでなく用途に基づいて付ける
- 階層を考慮する — 視覚的な重みが重要度をどう伝えるかを記録する
- 禁止事項を明記する — アンチパターンはルールそのものと同じくらい重要です
よくある落とし穴
- 技術用語を説明せずに使う(「generously rounded corners」ではなく「rounded-xl」と記載するなど)
- HEX コードを省略する、または説明的な名前だけを使う
- デザイン要素の機能的な役割を忘れる
- 雰囲気の説明が曖昧すぎる
- アンチパターンの一覧を無視する — これらが出力をプレミアムなものにします
- 厳選された美的スタイルを徹底せず、汎用的な「無難な」デザインに頼る
出力レポート
スキルの主なタスクがすべて完了した後、Wiki にドラフトを提案します。
手順
1. ファイル名を作成する:
- 形式:
DDMMYY-<ten>.md DDMMYY= 今日の日付(例:2026 年 6 月 2 日の場合は020626)<ten>= 実施内容を要約する 2〜4 個のケバブケースの単語(例:landing-page-coteccons、brand-kit-fintech、ingest-auth-spec)
2. llmwiki/wiki/draft/uiux/DDMMYY-<ten>.md に書き込む:
# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD
## What
<One sentence — what this skill invocation produced or decided>
## Output
<Key artefacts, files created/modified, or decisions made>
## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |
## Notes
- Invoked via: `/<skill-name>` skill
## Origin
- **Draft:** `wiki/draft/uiux/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_
3. Wiki のインデックスとログを更新する:
llmwiki/wiki/index.md— 1 行追加する:| [DDMMYY-<ten>](draft/uiux/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |llmwiki/wiki/log.md— 追記する:## YYYY-MM-DD — <skill-name> — <ten>
スキルが成果物も決定事項も一切生成しない場合に限り、スキップします(例:
/caveman-statsのような表示専用モード)。