gemini-design-mcp 3.12.7 → 3.12.9

package/build/index.js

@@ -41,27 +41,28 @@ This tool is for creating NEW files that need HIGH-QUALITY DESIGN.
   • Creating config files → You can do this yourself
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚠️ CRITICAL: MANDATORY FLOW BEFORE CALLING
+⚠️ MANDATORY: CHECK FOR design-system.md FIRST
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-STEP 1: CHECK PROJECT STATE
-─────────────────────────────
-A) EMPTY REPO (no package.json):
-   → Ask user: "What tech stack do you want?"
-   → Help them initialize first
+BEFORE calling this tool, check if design-system.md exists at project root.
 
-B) PROJECT EXISTS but NO frontend files yet:
-   → Proceed to Step 2 (Vibe Selection) - MANDATORY
+IF IT DOES NOT EXIST:
+  1. Call generate_vibes first
+  2. Write the returned code to vibes-selection.tsx
+  3. Ask user to open the page and pick their favorite vibe
+  4. Extract THE ENTIRE CODE between <!-- VIBE_X_START --> and <!-- VIBE_X_END -->
+  5. Save it to design-system.md
+  6. THEN call this tool
 
-C) PROJECT EXISTS with existing frontend code:
-   → Analyze existing files, pass as context
-   → Skip vibe selection
-   → ⚠️ MUST pass CSS/globals file with design tokens in 'context' parameter
+IF IT EXISTS:
+  Read it and pass its ENTIRE content in the designSystem parameter.
 
-STEP 2: VIBE SELECTION (Required for new designs)
-──────────────────────────────────────────────────
-Call generate_vibes tool FIRST to get 5 creative vibes from Gemini.
-Present options to user, they select one, then pass it here via designSystem.vibe.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📋 PARAMETERS
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+• designSystem: Copy-paste the ENTIRE content of design-system.md (all the code)
+• context: Functional/business context only (what it does, features, requirements)
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 📤 OUTPUT
@@ -98,13 +99,11 @@ Use this to REDESIGN existing UI elements that need better design.
   • "Center this div" → Just add flex classes yourself
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚠️ CRITICAL: PASS DESIGN TOKENS IN CONTEXT
+📋 PARAMETERS
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-Pass your styling files (CSS, SCSS, theme config) with design tokens in the 'context' parameter.
-Otherwise Gemini may introduce standalone styles that don't match your design system.
-
-Example: "Project uses: var(--font-heading), var(--bg-primary), .section-padding class"
+• designSystem: Copy-paste the ENTIRE content of design-system.md (all the code)
+• context: Functional/business context only (what the modification achieves)
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 📤 OUTPUT FORMAT
@@ -192,31 +191,12 @@ Use this for ANY new UI component that needs visual design:
 | Loading spinner              | ❌ NO                | Too simple                 |
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚠️ CRITICAL: DESIGN SYSTEM INTEGRATION
+📋 PARAMETERS
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-For EXISTING PROJECTS, you MUST pass the design tokens to avoid mismatched styles:
-
-1. Pass the CSS/globals file in the 'context' parameter
-2. Include CSS variables, classes, and color tokens in 'insertionContext'
-3. Gemini will then use YOUR design system instead of creating standalone styles
-
-Without this, the snippet will have:
-  ❌ Hardcoded px values instead of your spacing variables
-  ❌ Hardcoded colors instead of your color tokens
-  ❌ New fonts instead of your font definitions
-  ❌ Standalone styles that don't match your project
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚠️ REQUIRED: INSERTION CONTEXT
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Tell Gemini WHERE and WHICH design tokens to use:
-
-Good: "After the header in Dashboard. Use project tokens:
-      var(--font-heading) for titles, var(--bg-primary), .section-padding class."
-
-Bad: "In the dashboard"
+• designSystem: Copy-paste the ENTIRE content of design-system.md (all the code)
+• context: Functional/business context only (what it does, features, requirements)
+• insertionContext: WHERE in the file this snippet will go (after header, inside main, etc.)
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 📤 OUTPUT FORMAT
@@ -240,41 +220,36 @@ YOU (the agent) are responsible for:
 - Inserting the returned snippet into the correct location in the file`, snippetFrontendSchema, snippetFrontend);
 
     // TOOL 4: GENERATE_VIBES
-    server.tool("generate_vibes", `Generate 5 unique design vibes for a new project using Gemini AI.
+    server.tool("generate_vibes", `Generate a visual page with 5 unique design vibes for user selection.
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 🎯 WHEN TO USE THIS TOOL
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-Use this tool BEFORE calling create_frontend on a NEW project that has no existing design.
-
-This tool generates creative, unique design vibes tailored to the project context.
-The user then selects one, and you pass it to create_frontend.
+Use this tool when design-system.md DOES NOT EXIST at project root.
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📋 FLOW
+📋 COMPLETE FLOW
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-1. User asks to create frontend for a NEW project
-2. Call generate_vibes with project description
-3. Present the 5 vibes to the user
-4. User selects their preferred vibe
-5. Call create_frontend with the selected vibe in designSystem.vibe
+1. Call generate_vibes with projectDescription
+2. Write the returned code to vibes-selection.tsx (or .jsx)
+3. Ask user: "Can you open vibes-selection and pick your favorite vibe?"
+4. User opens the page, sees 5 distinct visual sections, picks one: "vibe 3"
+5. Extract THE ENTIRE CODE between <!-- VIBE_X_START --> and <!-- VIBE_X_END -->
+6. Save it to design-system.md
+7. Ask: "Delete vibes-selection.tsx?"
+8. Now you can call create_frontend, modify_frontend, snippet_frontend
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 📤 OUTPUT
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-Returns 5 vibes, each with:
-- emoji: Visual identifier
-- name: Memorable vibe name
-- description: 2-3 evocative sentences
-- keywords: Style keywords for the designer
+Returns FULL CODE for a page with 5 visual sections (vibes).
+Each vibe is wrapped in <!-- VIBE_X_START --> and <!-- VIBE_X_END --> markers.
 
-Example vibe:
-🏛️ "Pristine Museum"
-An ultra-clean, 'white-cube' aesthetic focused on vast negative space.
-Keywords: minimal, whitespace, gallery, clean, sophisticated`, generateVibesSchema, generateVibes);
+The user opens this page in browser to visually compare all 5 vibes.
+They pick one, you extract that vibe's code and save it to design-system.md.`, generateVibesSchema, generateVibes);
 
     return server;
 }

package/build/prompts/system.js

@@ -260,18 +260,30 @@ Gut-check questions to ensure you're not shipping mediocrity:
 
 ---
 
-## DESIGN SYSTEM INTEGRATION (CRITICAL WHEN CONTEXT IS PROVIDED)
-
-When existing project context is provided, you MUST:
-- NEVER add inline <style> tags - use ONLY the styling approach from the context
+## DESIGN SYSTEM INTEGRATION (CRITICAL WHEN DESIGN SYSTEM IS PROVIDED)
+
+The design system is a STYLE REFERENCE, not content to copy literally.
+
+**EXTRACT THE STYLE (use these):**
+- Colors (backgrounds, text colors, accents, gradients)
+- Typography (fonts, sizes, weights)
+- Spacing scale (padding, margin, gaps)
+- Visual effects (shadows, borders, border-radius, glassmorphism, animations)
+- CSS classes and patterns
+- Component structure (layout, flex/grid patterns)
+
+**DO NOT COPY THE CONTENT (adapt to context):**
+- Specific icons (Cpu, ShieldCheck, etc.) → use icons APPROPRIATE to the functional context
+- Placeholder text ("Sarah System", "Task completed") → use RELEVANT content
+- Example data (numbers, stats, names) → adapt to the real context
+- Specific images or illustrations
+
+**TECHNICAL RULES:**
+- NEVER add inline <style> tags - use ONLY the styling approach from the design system
 - NEVER hardcode pixel values - use the project's existing variables, tokens, or classes
-- NEVER introduce new fonts - use the project's existing font definitions
-- NEVER hardcode colors - use the project's existing color tokens/variables/classes
-- Match the EXACT spacing scale, typography scale, and color palette
-- The new file must look like it belongs to the same project, not a "foreign" design
-- Reuse existing component patterns, class naming conventions, and styling architecture
-- Adapt to whatever styling system the project uses (analyze the context)
-- DONT use fake "SYSTEM STATUS : OPERATIONAL" or something like that
+- NEVER introduce new fonts - use the design system's font definitions
+- NEVER hardcode colors - use the design system's color tokens/variables/classes
+- The new file must LOOK like the design system but CONTAIN relevant content for the context
 
 ---
 
@@ -604,13 +616,26 @@ UTILISER EXACTEMENT :
 // Added to modify/snippet prompts when design system is loaded
 // =============================================================================
 export const DESIGN_SYSTEM_USAGE_INSTRUCTIONS = `
-RÈGLE CRITIQUE - DESIGN SYSTEM OBLIGATOIRE:
-Si un design system est fourni, tu DOIS :
-- Copier EXACTEMENT les styles, classes, et patterns spécifiés
-- NE JAMAIS inventer de nouvelles couleurs, paddings, ou border-radius
-- Utiliser les composants définis (Button Primary, Input, Card, etc.)
-- Respecter les tailles définies (sm/md/lg) sans les modifier
-- Si un élément n'existe pas dans le design system, le créer en utilisant UNIQUEMENT les tokens définis
+RÈGLE CRITIQUE - DESIGN SYSTEM = RÉFÉRENCE DE STYLE (PAS DE CONTENU À COPIER)
+
+Le design system fourni est un EXEMPLE DE STYLE. Tu dois extraire et utiliser :
+
+✅ À UTILISER (le style) :
+- Les couleurs (backgrounds, text colors, accents, gradients)
+- La typographie (fonts, sizes, weights, line-heights)
+- Les espacements (padding, margin, gaps)
+- Les effets visuels (shadows, borders, border-radius, glassmorphism, animations)
+- Les classes CSS et patterns de styling
+- La structure des composants (layout, flex/grid patterns)
+
+❌ À NE PAS COPIER (le contenu d'exemple) :
+- Les icônes spécifiques (Cpu, ShieldCheck, etc.) → utilise des icônes APPROPRIÉES au contexte fonctionnel
+- Les textes placeholder ("Sarah System", "Task completed", etc.) → utilise du contenu PERTINENT
+- Les données d'exemple (nombres, stats, noms) → adapte au contexte réel
+- Les images ou illustrations spécifiques
+
+IMPORTANT : Le design system montre COMMENT styler, pas QUOI afficher.
+Adapte le CONTENU au contexte fonctionnel fourni, en gardant le STYLE du design system.
 `;
 
 // =============================================================================
@@ -685,15 +710,24 @@ CRITICAL RULE - FUNCTIONAL CODE ONLY:
 
 SNIPPET PRINCIPLES:
 
-1. **DESIGN SYSTEM INTEGRATION (CRITICAL - READ THIS FIRST)**
-   - NEVER add inline <style> tags or CSS-in-JS style objects - use ONLY the styling approach from the context
-   - NEVER hardcode pixel values (padding: 120px, font-size: 42px) - use the project's existing variables, tokens, or utility classes
-   - NEVER introduce new fonts - use the project's existing font definitions
-   - NEVER hardcode colors - use the project's existing color tokens/variables/classes
-   - If context includes design tokens, variables, or classes, you MUST use them exclusively
-   - The snippet must integrate SEAMLESSLY - it should look like it was always part of the codebase, not a "foreign block"
-   - Match the exact spacing scale, typography scale, and color palette of the existing project
-   - Adapt to whatever styling system the project uses (CSS modules, utility classes, SCSS, styled-components, etc.)
+1. **DESIGN SYSTEM = STYLE REFERENCE (NOT CONTENT TO COPY)**
+
+   The design system shows HOW to style, not WHAT to display.
+
+   **USE the style:**
+   - Colors, typography, spacing, effects, CSS classes, component structure
+
+   **DO NOT copy the content:**
+   - Specific icons (Cpu, ShieldCheck) → use icons APPROPRIATE to the functional context
+   - Placeholder text ("Sarah System") → use RELEVANT content from the context
+   - Example data → adapt to the real context
+
+   **TECHNICAL RULES:**
+   - NEVER add inline <style> tags - use ONLY the styling approach from the design system
+   - NEVER hardcode pixel values - use the project's existing variables, tokens, or utility classes
+   - NEVER introduce new fonts - use the design system's font definitions
+   - NEVER hardcode colors - use the design system's color tokens/variables/classes
+   - The snippet must integrate SEAMLESSLY with the design system's STYLE while having RELEVANT content
 
 2. **CONTEXTUAL AWARENESS**
    - The snippet will be inserted into an existing codebase

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gemini-design-mcp",
-  "version": "3.12.7",
+  "version": "3.12.9",
   "description": "MCP server that uses Gemini 3 Pro for frontend/design code generation",
   "main": "build/index.js",
   "bin": {