Generate Figma Screen — Kod/Açıklamadan Figma Ekranı

Kullanım (v3.1+): fmcp-screen-orchestrator altında, Fast Path match FALSE olduğunda ana üretim motoru. Doğrudan entry point DEĞİL. Kullanıcı "ekran üret" dediğinde önce orchestrator yüklenir; orchestrator Fast Path match yapamadıysa buraya düşer.

Design Token Kuralı: Bu skill'deki kod örneklerinde geçen font adları, renk kodları, piksel boyutları yalnızca FORMAT gösterimidir. Çalışma anında tüm design token değerleri (font, renk, boyut, spacing, radius, gölge) kayıtlı kütüphaneden (figma_get_variables, figma_get_styles) veya kullanıcıdan okunmalıdır. Hardcoded token değeri kullanma. Detay: project-context.md → "Design Token Kuralı".

Overview

Bu skill, bir kod tabanından veya metin açıklamasından Figma'da tam sayfa/ekran oluşturur. Temel ilke: hardcode hex renk ve piksel değerleri yerine yayınlanmış design system bileşenlerini (component instance), değişkenlerini (variable) ve stillerini (text/effect style) kullanmak.

Topluluk figma-generate-design skill'inden uyarlanmış, F-MCP Bridge araçlarına göre yeniden yazılmıştır.

Zorunlu: Her figma_execute çağrısından önce figma-canvas-ops kılavuzundaki kuralları uygula.

Skill Boundaries

• Bu skill: Figma'da ekran oluşturma/güncelleme (DS bileşen instance'ları ile)
• Figma'dan kod üretmek istiyorsan → implement-design
• Yeniden kullanılabilir bileşen/variant oluşturmak istiyorsan → generate-figma-library
• Code Connect eşlemesi istiyorsan → code-design-mapper

Prerequisites

• F-MCP Bridge plugin bağlı olmalı
• Hedef Figma dosyasında yayınlanmış DS bileşenleri (veya team library erişimi) olmalı
• Kaynak: kod dosyaları veya ekran açıklaması

F-MCP skill koordinasyonu

• Önce (isteğe bağlı): audit-figma-design-system ile mevcut ekranın DS uyumunu kontrol et
• Birlikte: figma-canvas-ops (her figma_execute öncesi zorunlu)
• Sonra: figma-a11y-audit ile erişilebilirlik kontrolü; design-drift-detector ile kod parity'si

Required Workflow

Bu adımları sırayla uygula. Adım atlama.

Step 0: Aktif Tasarım Sistemi Kontrolü (ZORUNLU - v1.8.0+)

Ekran yapmaya başlamadan önce DS context'inin belirli olduğundan emin ol.

1. Read .claude/design-systems/active-ds.md
2. Status alanı:
   ✅ Aktif        → Library Name'i not al, Step 1'e geç
   ❌ Henüz seçilmedi → Kullanıcıya sor:
     "Hangi tasarım sistemi ile ilerleyelim?
      - ❖ Ana-DS (varsa)
      - Material Design
      - Apple HIG
      - Kendi DS'iniz (Figma library URL verin)
      - Hiçbiri (ham Figma)"
3. Kullanıcı yanıtladıktan sonra active-ds.md'yi update et:
   - Status: ✅ Aktif
   - Library Name: <seçim>
   - Selected At: <bugün>
4. Sonraki turlarda bu soruyu TEKRAR SORMA — active-ds.md zaten dolu.
   Kullanıcı açıkça "DS değiştir" demediği sürece aynı DS'i kullan.

Bypass: Kullanıcı "DS'siz devam et" derse Status: DS bypass mode olarak işaretle. Token binding kuralı esnetilir ama yine de kullanıcıya hardcoded değer kullandığını bildir.

Detay: figma-canvas-ops SKILL Section 0 — Design System Context.

Step 1: Plugin Bağlantısını Doğrula

figma_get_status()

Step 2: Ekranı Anla

Figma'ya dokunmadan önce ne inşa edileceğini anla:

1. Koddan oluşturuluyorsa ilgili kaynak dosyaları oku — sayfa yapısı, bölümler, kullanılan bileşenler
2. Ekranın ana bölümlerini listele (Header, Hero, Content, Footer vb.)
3. Her bölüm için gereken UI bileşenlerini belirle (Button, Input, Card, Nav vb.)

Step 2.5: Tasarım Yönü Belirleme

DS bileşenlerini keşfetmeden ÖNCE, ne inşa edileceğinin estetik yönünü belirle.

Marka Profili Kontrolü

Proje kökünde .fmcp-brand-profile.json varsa:

• aestheticDirection → estetik yön zaten tanımlı, kullan
• typography.displayFont / typography.bodyFont → font seçimi zaten tanımlı, kullan
• typography.rationale → seçim gerekçesi mevcut

Profil Yoksa Kullanıcıya Sor

Amaç: Bu ekran hangi sorunu çözüyor? Kim kullanıyor?

Estetik Yön: Aşağıdakilerden birini seç veya tanımla:

Kısıtlamalar: Teknik gereksinimler (framework, performans, a11y)

Farklılaşma: Bu ekranı unutulmaz yapan tek şey ne?

DS bileşen kütüphanesi olan projelerde: Estetik yön DS'nin belirlediği sınırlar içinde olmalı. DS font, renk ve spacing kararlarını zaten vermiştir. Bu adım DS'yi aşmak için değil, DS bileşenlerini nasıl compose edeceğini yönlendirmek içindir.

Tipografi Stratejisi

• Display font: başlıklar, hero text, sayfa title
• Body font: paragraflar, açıklamalar, form etiketleri
• Font çifti kararını raporda belirt (neden bu çift?)

Step 2.4: DS-Contextual Defaults (ZORUNLU — v1.9.8+)

⚠️ MUTLAK — AskUserQuestion YASAK (v1.9.9+ K2+): Bu tabloyu uyguladıktan sonra device, primary_binding, font_pattern cevaplanmış sayılır. Adım 5 smart skip'i bu üç input için bypass et; kullanıcıya device / preset / mode sorusu SORMA. auto_resolved_reason alanını log'a yaz (örn. "iOS mobile + payment → iPhone 17 defaulted from Step 2.4 table") ama soru olarak sunma. Sadece tabloda eşleşme YOKSA (fallback case) klasik Adım 5 sorusuna düş.

Amaç: Kullanıcı aktif DS + screen_type belirttiğinde device / primary binding / font'u otomatik çözerek gereksiz soru sormayı önle.

Uygulama: Prompt parse + active-ds.md'den Library Name oku, sonra aşağıdaki tabloyu çap:

<DS> = active-ds.md'deki Library Name slug'ı (örn. ❖ Ana-DS → ana-ds, Material → material). Token isimleri DS convention'una göre değişebilir — eşleşme yoksa DS cache'inden (.claude/design-systems/<DS>/tokens.md) benzer token ara.

Algoritma:

1. User prompt'undan platform keyword parse et (iOS/iPhone/mobil/Android/Pixel/tablet/iPad/desktop/web).
2. Prompt'tan screen_type keyword parse et (payment/login/home/list/detail/form/dashboard/onboarding).
3. Tablodan (platform, screen_type) kombinasyonunu çap → device, primary_binding, font_pattern al.
4. active-ds.md cache'inden <DS>/primary/default gerçek variableKey'ini çöz (Step 3 cache-first ile).
5. Kullanıcıya sorma — Adım 6 summary'ye doğrudan bu değerleri yaz.

Fallback: Tabloda eşleşme yoksa (örn. custom platform + custom screen_type): v1.9.5 "Sen seç" kuralı devreye girer → iPhone 17 + <DS>/primary/default default.

Neden ZORUNLU: Önceki testlerde "Ana-DS iOS ödeme sayfası" prompt'una device sorusu gereksiz yere soruldu. Bu tablo ile otonomi kırılma noktası #3 kapatılır.

Step 3: Design System Keşfi (Cache-First Stratejisi)

Üç şey gerekiyor: bileşenler, variable'lar, stiller.

⚠️ MCP TOOL SEÇİMİ (v1.8.0+):

• F-MCP plugin bağlıysa figma_search_assets veya figma_get_library_variables kullan
• Resmi Figma MCP'nin search_design_system tool'unu ÇAĞIRMA — "Resource links not supported" / "file could not be accessed" hatası verir
• Detay: FMCP_INSTRUCTIONS → "TOOL SELECTION" bölümü

Step 3.1 — Cache Populate (v1.9.9+ OTONOM — G19)

v3.3+ SKIP-ON-LIVE: Adım -1'deki canlı enumerate (figma_enumerate_published_components / figma_enumerate_library_components) componentKey'leri zaten döndürdüyse bu adımı tamamen ATLA — populate gereksiz. Yalnızca registry boş / REST token yoksa aşağıdaki klasik populate akışı çalışır.

Eğer user-local ~/.claude/data/fcm-ds/<file-key>/components.md yok veya stale (>7 gün) VE active-ds.md Status: ✅ Aktif ise, Claude kullanıcıya sormadan aşağıdaki adımları otomatik çalıştırır:

1. Token populate: figma_get_library_variables() çağır (tüm enabled library collection'ları için). Sonuçları ~/.claude/data/fcm-ds/<file-key>/tokens.md'e yaz:

   # Tokens (auto-populated YYYY-MM-DD)
   | Name | Key | Type | Collection |
   |---|---|---|---|
   | spacing/100 | <variableKey> | FLOAT | Semantic Sizes |
   | Global/primary/default | <variableKey> | COLOR | Semantic Colors |

2. Component populate: figma_search_components(currentPageOnly=false, limit=500) çağır. Library (remote=true) component'leri filtrele. components.md'e yaz:

   # Components (auto-populated YYYY-MM-DD)
   | Name | Key | Role | Source |
   |---|---|---|---|
   | Button | <componentKey> | primary_button | ❖ Ana-DS |
   | NavigationTopBar | <componentKey> | nav_top | ❖ Ana-DS |

3. Meta update: _meta.md güncelle — Son sync: YYYY-MM-DD, Durum: ✅ TAMAMLANDI (auto), Sync yöntemi: Step 3.1 auto-populate.
4. Exit: Cache dolu → aşağıdaki ana Cache-First kuralı (var → kullan) devreye girer.

Neden otonom: User-local dizin gitignored; Claude'un buraya yazması repo'ya etki etmez, sadece cache oluşur. Sonraki /execute sorguları cache-hit yapar → importComponentByKeyAsync direkt kullanılabilir (Rule 24.2 aktif).

Fail case: figma_get_library_variables boş döner veya plugin erişemezse → _restFallbackHint'i logla, Rule 24 fallback chain'e (24.1 → 24.3) geç.

CACHE-FIRST KURALI (MUTLAK ZORUNLU - PRE-FLIGHT BLOCKER):

Figma API'ye gitmeden önce .claude/design-systems/<library-id>/ cache'ini kontrol et:

1. Read .claude/design-systems/<library-id>/_meta.md
   ↓
   ✅ Var, sync güncel (24h içinde) → cache'leri kullan, devam et
   ❌ Yok / sync eski / yarım kalmış → Step 3a-3d'yi ÇALIŞTIR ve cache'i doldur,
                                       ANCAK O ZAMAN ekran üretimine başla

Cache eksik veya stale ise ekran üretimi BAŞLAYAMAZ — önce keşif/cache, sonra üretim. Bu, hardcoded fallback'leri ve tekrar tekrar API çağrılarını engeller.

• Text style key'leri → .claude/design-systems/<library-id>/tokens.md (text style key cache)
• Variable key'leri → .claude/design-systems/<library-id>/tokens.md
• Component key'leri + override notları → .claude/design-systems/<library-id>/components.md
• Font ailesi + available weights → .claude/design-systems/<library-id>/tokens.md (Font Weights bölümü)

Cache doldurulduktan sonra her oturumda 24 saat boyunca tekrar API'ye gitmeden okunabilir. Bu, sonraki oturumlarda token tüketimini %60-70 düşürür.

Cache Invalidation: Cache dosyasının başına lastUpdated: YYYY-MM-DD HH:mm ekle. 24 saatten eski cache'ler otomatik yenilenmelidir. Kütüphane güncellendiğinde key'ler değişebilir.

Kütüphane Cache Şablonu

Her DS kütüphanesi .claude/libraries/<ds>.md dosyasında şu bölümleri içermeli:

### Text Style Key Cache (importStyleByKeyAsync ile kullan)
| Style Adı | Font | Size | Key |
|-----------|------|------|-----|
| heading/h1 | Bold | 32 | `abc123...` |
| body/regular | Regular | 14 | `def456...` |

### Effect Style Key Cache
| Style Adı | Key |
|-----------|-----|
| shadow/card | `ghi789...` |

### Sık Kullanılan Variable Key Cache
**Renkler:**
| Variable | Key |
|----------|-----|
| bg/primary | `jkl012...` |

**Boyutlar:**
| Variable | Key |
|----------|-----|
| spacing/md | `mno345...` |

### Sık Kullanılan Component Key Cache
| Bileşen | Key | Override Notları |
|---------|-----|------------------|
| Button | `pqr678...` | `Label#id` → TEXT property |
| Input | `stu901...` | Label → nested text (findOne) |

Cache oluşturma: İlk ekran oluşturmada figma_get_styles, figma_get_variables(summary) ve componentProperties ile key'leri topla, .claude/libraries/<ds>.md'ye yaz. Sonraki oturumlarda direkt cache'den oku.

3a: Bileşen keşfi (v3.1+ — server cache-first)

ZORUNLU SIRA — Rule 24.0:

1. figma_enumerate_published_components(libraryFileKey=<registry>, filter?)  ← TEK ÇAĞRI
   → componentKey listesi (REST; library dosyası açıksa figma_enumerate_library_components tercih et)
2. importComponentByKeyAsync(key) / importComponentSetByKeyAsync(key) → instance üret

YASAK (enumerate başarılıyken): figma.currentPage.findAll(INSTANCE) ile başka sayfaları/ekranları tarama. Sebep: timeout riski + yanlış instance + liste zaten elde.

Fallback (sıra zorunlu — Rule 24):

• 24.0 → figma_enumerate_published_components / figma_enumerate_library_components (ana yol)
• 24.1 → figma_rest_api GET /v1/files/<LIB_KEY>/components (ham REST)
• 24.2 → figma_search_assets(currentPageOnly=false) (Plugin instance scan, son çare)
• 24.4 → kullanıcıya library URL sor

Geniş arama gerekirse — birden fazla filter ile çağır (büyük library'lerde filter ZORUNLU):

figma_enumerate_published_components(libraryFileKey=<registry>, filter="button")
figma_enumerate_published_components(libraryFileKey=<registry>, filter="input")

3b: Variable keşfi

figma_get_variables(verbosity="summary")

Renk, spacing, radius token'larını not al. Gerekirse verbosity="full" ile detay al.

3c: Stil keşfi

figma_get_styles()

Text style ve effect style'ları not al.

3d: DS Variable Key'lerini Hazırla (ZORUNLU)

v3.3+ LIVE-FIRST: figma_get_library_variables(query?, collectionName?) TEK CALL ile variableKey listesi al (teamLibrary — hedef dosyada çalışır, library dosyasının açık olması gerekmez). figma_execute içinde elle teamLibrary discovery YASAK (gereksiz round-trip). Tool başarısızsa aşağıdaki klasik akış.

Ekran oluşturmadan önce kullanılacak tüm DS token'larının variable key'lerini topla. Bu adım atlanamaz.

1. Kütüphane dosyasını oku: .claude/libraries/ dizinindeki kütüphane dosyasından font ailesi, variable collection ve text style bilgilerini al.
2. HEDEF dosyada variable key'lerini çek (DS dosyasına bağlanmak GEREKMEZ):

   figma_get_library_variables({ libraryName: "❖ Ana-DS" })

   Veya figma_execute ile:

   // HEDEF dosyada çalıştır — DS dosyası değil!
   var cols = await figma.teamLibrary.getAvailableLibraryVariableCollectionsAsync();
   var target = cols.filter(function(c) { return c.libraryName === "❖ Ana-DS"; });
   var results = [];
   for (var ci = 0; ci < target.length; ci++) {
     var vars = await figma.teamLibrary.getVariablesInLibraryCollectionAsync(target[ci].key);
     for (var vi = 0; vi < vars.length; vi++) {
       results.push({ name: vars[vi].name, key: vars[vi].key, type: vars[vi].resolvedType, collection: target[ci].name });
     }
   }
   return results;

3. Text style key'lerini çek: Kütüphane cache'inde key varsa oku. Yoksa REST API ile DS dosyasından: figma_rest_api GET /v1/files/{DS_FILE_KEY}/styles Alternatif: Hedef dosyada zaten import edilmiş style'lar:

   var styles = await figma.getLocalTextStylesAsync();
   return styles.map(function(s) { return { id: s.id, name: s.name, key: s.key }; });

4. Font ailesi: Kütüphane dosyasındaki Font Ailesi alanından oku. Bulunamazsa DS text style'larından font bilgisini çıkar. Kullanıcıya sor. Kullanıcı "sen seç" derse VE DS fontu bulunamadıysa Inter kullan.

Bu adımda toplanan key'ler, sonraki adımlarda importVariableByKeyAsync ile hedef dosyaya import edilecek.

Step 3.5: Clone Tool'u Tuzağı — Ne Zaman Clone, Ne Zaman Sıfırdan İnşa (v1.8.2+ ZORUNLU)

figma_clone_screen_to_device tool'u v1.8.1'de eklendi ama sadece dar bir use-case için kullanılmalıdır. Yanlış kullanım, benchmark'ın mevcut yanlışlıklarını (hardcoded rectangle, eksik token binding, non-responsive layout) kopyalayarak disiplin ihlaline yol açar.

Karar Matrisi

Kullanıcının Gerçek İstediği Nedir?

Kullanıcı "3 alternatif tasarım" dediğinde neredeyse her zaman istediği:

• Farklı layout/renk/tipografi yaklaşımları
• Her biri gerçekten AYRI (sadece isim değil, içerik de)
• Hepsinde DS uyumu (instance + token binding)
• Hepsi responsive (auto-layout + FILL sizing)

Bu clone'un kapsamında DEĞİL. Clone sadece "kopyala, isim değiştir" yapar. Sonuçta 3 identik kopya + farklı isimler olur. Bu kullanıcının istediği GERÇEK varyasyon değildir.

Doğru Akış: Build-from-Scratch (Step 4-5)

Benchmark varsa:

1. Step 3.x'te benchmark'ı figma_get_design_context ile OKU — yapısal anlayış için
2. Benchmark'ta kullanılan Ana-DS instance'ları not al (NavigationTopBar, PillTabs, vb.)
3. Benchmark'ta yanlış olan şeyleri kopyalama:
   • Hardcoded rectangle separator'lar → DS Divider component kullan
   • Non-responsive iç frame'ler → auto-layout FILL'e çevir
   • Missing token bindings → her yerde setBoundVariable* kullan
4. Step 4 + Step 5 akışını takip et — sıfırdan, Ana-DS kurallarıyla
5. Her alternatif için benzersiz layout çözümü:
   • Hero Card: bakiye kartı büyütülmüş, quick actions altta sade
   • Liste Odaklı: hesap listesi dominant, özet sağ-altta
   • Dark Header: root fill Global/primary/default, text'ler on-primary token
6. Step 6.5 validate → skor ≥ 80

Kısıtlama Kuralı

Kullanıcı şu kelimelerden birini kullandıysa → figma_clone_screen_to_device KULLANMA:

• "alternatif", "varyasyon", "farklı", "yeni", "tasarla", "iyileştir", "redesign"

Intent Router bu kelimeleri algıladığında approach = build-from-scratch otomatik set eder ve Claude'u Step 4-5 rotasına yönlendirir.

Step 4: Boş Alan Bul ve Wrapper Frame Oluştur

const children = figma.currentPage.children;
let maxX = 0;
children.forEach(c => {
  const right = c.x + c.width;
  if (right > maxX) maxX = right;
});

// DS'den arka plan ve spacing variable'larını import et
const bgVar = await figma.variables.importVariableByKeyAsync("SURFACE_BG_KEY");
const paddingVar = await figma.variables.importVariableByKeyAsync("SPACING_KEY");

const frame = figma.createFrame();
frame.name = "Ekran Adı";
frame.x = maxX + 100;
frame.y = 0;
frame.resize(1440, 900); // Masaüstü varsayılan; mobil için 390x844
frame.layoutMode = "VERTICAL";
frame.primaryAxisSizingMode = "AUTO";
frame.counterAxisSizingMode = "FIXED";

// Arka plan rengini DS variable'ına BAĞLA (hardcoded renk YAZMA)
const fills = [{type: "SOLID", color: {r:1,g:1,b:1}}]; // geçici
const boundFill = figma.variables.setBoundVariableForPaint(fills[0], "color", bgVar);
frame.fills = [boundFill];

// Padding'i DS variable'ına BAĞLA
frame.setBoundVariable("paddingLeft", paddingVar);
frame.setBoundVariable("paddingRight", paddingVar);
frame.setBoundVariable("paddingTop", paddingVar);
frame.setBoundVariable("paddingBottom", paddingVar);

return { frameId: frame.id, position: { x: frame.x, y: frame.y } };

Step 5: Bölüm Bölüm İnşa Et

Her bölümü ayrı bir figma_execute çağrısında oluştur. Tek çağrıda tüm ekranı oluşturmaya ÇALIŞMA.

Sıra: Üstten alta — Header → Hero → Content → Footer

Her bölüm için:

1. figma_execute ile bölüm frame'ini oluştur, DS bileşen instance'larını yerleştir
2. Tüm renkleri setBoundVariableForPaint ile DS variable'ına bağla — hardcoded renk kullanma
3. Tüm spacing/padding/radius değerlerini setBoundVariable ile bağla — hardcoded sayı kullanma
4. Metin node'larına text style ata: setTextStyleIdAsync ile DS text style'ını uygula — hardcoded fontSize/fontName kullanma
5. Oluşturulan node ID'lerini return et
6. figma_capture_screenshot ile görsel doğrulama — boundVariables bağlı mı kontrol et

Metin oluşturma kalıbı (DS'e bağlı):

await figma.loadFontAsync({ family: "DS_FONT", style: "Regular" });
const textColorVar = await figma.variables.importVariableByKeyAsync("TEXT_COLOR_KEY");

const text = figma.createText();
text.characters = "Metin içeriği";

// Text style uygula (fontSize, fontName, lineHeight hep style'dan gelir)
await text.setTextStyleIdAsync("TEXT_STYLE_ID");

// Metin rengini DS variable'ına bağla
const textFills = [...text.fills];
const boundTextFill = figma.variables.setBoundVariableForPaint(textFills[0], "color", textColorVar);
text.fills = [boundTextFill];

Loading State Karar Ağacı:

Dinamik içerik barındıran her öğe için uygun loading pattern'ını belirle:

Skeleton türleri:

• Metin bloğu → skeleton-text (tam genişlik × 16px, 2-3 satır)
• Başlık → skeleton-title (200px × 24px)
• Avatar/ikon → skeleton-circle (pulse animasyonlu daire)
• Kart → skeleton-card (başlık + 2 satır metin + görsel alanı)
• Tablo/liste → skeleton-row (satır bazlı tekrarlayan skeleton)

Instance oluşturma kalıbı:

// figma_instantiate_component aracını kullan veya figma_execute içinde:
const component = figma.root.findOne(
  n => n.type === "COMPONENT" && n.name === "Button"
);
const instance = component.createInstance();
parentFrame.appendChild(instance);
// FILL boyutlandırmayı appendChild'DAN SONRA ayarla
instance.layoutSizingHorizontal = "FILL";

Tercihen figma_instantiate_component aracını kullan — daha güvenli ve basit.

Step 5.1: Gestalt İlkeleri ile Spacing Kararları (ZORUNLU)

Tek bir itemSpacing ile tüm bölümü dizme — YANLIŞ. Spacing kararlarında tüm tasarım ilkelerini sentezle:

Gestalt Proximity: İlişkili öğeler yakın, ilişkisiz öğeler uzak.

Card içi mantıksal gruplar (nested frame ile):
├── Header Group (title + subtitle) → iç gap: küçük (sp-050 ~ sp-100)
├── Form Group (inputs + checkbox) → iç gap: küçük-orta (sp-100 ~ sp-150)
├── Action Group (button + register link) → iç gap: küçük (sp-100 ~ sp-150)
├── Social Group (divider + social buttons + legal) → iç gap: küçük-orta (sp-150)
└── Gruplar arası gap: BÜYÜK (sp-300 ~ sp-400)

Similarity: Aynı işlevi gören öğeler aynı text style, renk ve boyutta olmalı. Hierarchy: Büyük/bold = önemli (başlık, CTA), küçük/light = ikincil (legal text, açıklama). Contrast: CTA butonu ve önemli öğeler arka plandan ayrışmalı. Alignment: Tutarlı hizalama ile düzen hissi — tüm child'lar layoutSizingHorizontal="FILL" (appendChild SONRA). White Space: Nefes aldıran boşluklar — ne çok sıkışık ne çok dağınık.

Step 5.15: DS Bileşen Kullanım Kuralı (ZORUNLU)

Önce DS'te o işlevi karşılayan bileşen variant'ını ara. DS'te varsa bileşeni kullan, yoksa raw node oluştur.

Kural: Ekrana koyacağın her UI öğesi için şu soruyu sor: "DS'te bu işlevi karşılayan bileşen var mı?"

• Evet → DS bileşenini kullan, variant/property'lerini ayarla (öncelikli)
• Hayır → Raw node oluştur (DS'te yoksa geçerli yol)

Uygulama: Ekran oluşturmadan önce (Step 3) DS bileşen kataloğunu tara. .claude/libraries/<ds>.md dosyasındaki bileşen listesini kontrol et. Link, divider, hint, badge gibi yardımcı öğeler için de mutlaka bileşen ara.

Step 5.16: Auto-Layout Sizing Kuralları (ZORUNLU)

Tüm child node'lar layoutSizingHorizontal = "FILL" olmalı (appendChild SONRASI). layoutAlign = "STRETCH" kullanma — tutarsız davranır.

// DOĞRU: appendChild sonra FILL
parentFrame.appendChild(child);
child.layoutSizingHorizontal = "FILL";

// YANLIŞ: layoutAlign = "STRETCH"
child.layoutAlign = "STRETCH"; // tutarsız, kullanma

İstisnalar:

• Horizontal row içindeki text node'lar: layoutSizingHorizontal = "HUG" — FILL yaparsan text kesilir
• Logo instance: HUG veya FIXED — doğal boyutunda kalsın
• layoutGrow = 1: Horizontal row'da eşit genişlik paylaşımı için (divider'lar gibi)

Card yapısı:

Screen: VERTICAL, counterAxis=CENTER, layoutSizingVertical=HUG
├── Logo: HUG (doğal boyut)
├── Card: FILL (appendChild SONRA) ← ekran padding ile genişlik kontrol edilir
│   ├── Title text: FILL
│   ├── Form Group: FILL
│   │   ├── Input instance: FILL
│   │   ├── Input instance: FILL
│   │   └── Horizontal Row: FILL
│   │       ├── Checkbox: HUG
│   │       └── Button(Link): HUG
│   ├── Action Group: FILL
│   │   ├── Button(Primary): FILL
│   │   └── Horizontal Row: FILL
│   │       ├── Text: HUG
│   │       └── Button(Link): HUG
│   └── Social Group: FILL
│       ├── Divider Row: FILL
│       ├── Social Button: FILL
│       └── Legal text: FILL
└── Bottom text: FILL

Responsive: Ekran genişliği FIXED (1280/768/375) veya Breakpoints/Screen token'a bound. Mode (Web/Tablet/Mobil) padding ve gap değerlerini kontrol eder → card otomatik uyar.

Mode adı eşleşmesi DİKKAT: indexOf("Web") "Mobil & Web Mobil"i de yakalar. indexOf("Desktop") kullan.

Step 5.17: Quality Gate — Her Bölüm Yazıldıktan Sonra (ZORUNLU — v1.8.2+)

Her bölüm (figma.createFrame() sonrası) için aşağıdaki checklist ZORUNLU. Herhangi biri ❌ ise → bölümü yeniden yaz. Claude bu checklist'i kendi kendine uygulamakla yükümlüdür.

[ ] Frame'in layoutMode'u atandı mı? (ASLA "NONE" olmamalı — HORIZONTAL veya VERTICAL)
[ ] primaryAxisSizingMode doğru mu? (Hug: AUTO, Fixed width: FIXED)
[ ] counterAxisSizingMode doğru mu?
[ ] Tüm fills setBoundVariableForPaint ile DS token'a bağlı mı? (hardcoded SOLID YASAK)
[ ] Tüm padding (top/bottom/left/right) setBoundVariable ile DS spacing token'a bağlı mı?
[ ] itemSpacing setBoundVariable ile DS spacing token'a bağlı mı?
[ ] cornerRadius (varsa) setBoundVariable ile DS radius token'a bağlı mı?
[ ] Her text node setTextStyleIdAsync ile DS text style'a bağlı mı? (ASLA sadece fontSize hardcoded)
[ ] Text fills setBoundVariableForPaint ile DS text color token'a bağlı mı?
[ ] Bölüm içinde en az 1 DS INSTANCE var mı? (importComponentByKeyAsync ile). 
    İstisna: Sadece text + frame olan bölümler (ör. başlık row) — bu durumda yine spacing/padding/renk token'ları zorunlu.
[ ] Tüm child'lar appendChild sonrası layoutSizingHorizontal = "FILL" mi? (text istisna: HUG)
[ ] Hiçbir node'un fills'i raw hex literal ile atandı mı? (grep: `{r:`, `color:` literal)

Otomatik kontrol örneği:

// Her createFrame sonrası Claude bu kontrolü yapar:
if (frame.layoutMode === "NONE") throw new Error("Quality Gate FAIL: NO_AUTO_LAYOUT");
if (!frame.boundVariables || !frame.boundVariables.paddingLeft) {
  console.warn("Quality Gate WARN: padding token binding eksik");
}

Quality Gate FAIL olursa ne yap?

1. Bölümü sil: frame.remove()
2. Eksik token/instance'ı figma_search_assets + figma_get_library_variables ile ara
3. Bölümü yeniden yaz — bu sefer tüm kuralları uyarak
4. Tekrar kontrol et

Skor hedef: figma_validate_screen sonrası ≥ 80 (Step 6.5). Quality Gate çalışırsa validate zaten geçer.

Step 5.2: Instance Override Rehberi (ZORUNLU)

Component PROPERTY (TEXT/BOOLEAN/VARIANT tipi) → setProperties:

btn.setProperties({"Value#44:2": "Buton Metni"});

NESTED TEXT (property olarak expose edilmemiş) → findOne:

var label = instance.findOne(function(n){
  return n.type==="TEXT" && n.name==="Label";
});
if(label){
  await figma.loadFontAsync(label.fontName);
  label.characters = "Yeni Metin";
}

Kural: Property mi nested mi bilmiyorsan → önce componentProperties oku. Orada yoksa findOne kullan. Hiçbir instance'ta "Label", "Value", "Button" gibi default text bırakma.

Step 5.3: API Gotcha Tablosu (EZBERLE)

Step 5.4: Referans Sadakati

Kullanıcı referans ekran (screenshot, canlı site) paylaştıysa:

• Card genişliği, renk tonu, border stili, spacing oranlarını kopyala
• Kendi yorumunu ekleme — referansa sadık kal
• Emin olmadığın kararlardan önce kullanıcıya sor

Step 5.5: Görsel Derinlik ve Detay (İsteğe Bağlı)

Estetik yön belirlendiyse (Step 2.5), bölüm inşa sırasında şu detaylar eklenebilir:

Spatial Composition:

• Asimetrik layout: her bölüm aynı grid'e sıkışmasın
• Overlap: öğeler arasında kasıtlı örtüşme (hero image + text overlay)
• Negatif alan: dramatik boşluk CTA'yı öne çıkarır

Arka Plan ve Atmosfer:

• Düz renk yerine: subtle gradient, noise doku, geometrik pattern
• Katmanlı transparan: overlay + backdrop-blur efektleri
• Gölge derinliği: elevation token'larını kullan (sm → xl)

Dekoratif Detaylar:

• Border: dekoratif border (dashed, gradient border)
• İkon: mono-weight ikon seti tutarlılığı
• Mikro detaylar: buton iç gölge, kart hover efekti ipucu

NOT: Bu öneriler DS bileşen kütüphanesi varsa DS'nin izin verdiği ölçüde uygulanır. DS token'ları dışında hardcoded değer eklenmez.

Step 5.6: Dark Mode / Theme Variants Workflow (ZORUNLU — v1.9.0+)

Intent router variants input'unda "Light + Dark mode" seçildiyse (veya kullanıcı açıkça dark+light istiyorsa), Step 6'ya geçmeden önce bu alt adımı uygula.

Ön koşul: DS'de theme modlar tanımlı bir variable collection var. Ana-DS için tipik: Colors collection + Light mode + Dark mode.

Akış (4 adım):

1. Light ekranı doğrula (Step 5 sonu): Wrapper frame ID'sini al. Tüm fill/stroke/background'lar setBoundVariableForPaint ile bağlı olmalı (Step 5.17 Quality Gate zaten sağladı). Eğer hardcoded değer varsa Step 5'e dön, düzelt.
2. Klon oluştur:

// figma_execute
const lightFrame = await figma.getNodeByIdAsync("<wrapper_id>");
const darkFrame = lightFrame.clone();
figma.currentPage.appendChild(darkFrame);
darkFrame.x = lightFrame.x + lightFrame.width + 80;  // sağda, 80px boşluk
darkFrame.name = lightFrame.name + " — Dark";
return { darkFrameId: darkFrame.id };

3. Dark mode'u klon frame'e uygula:

// figma_execute (ayrı çağrı)
const collections = await figma.variables.getLocalVariableCollectionsAsync();
const colorCol = collections.find(c => c.name === "Colors" || c.name.toLowerCase().includes("color"));
if (!colorCol) throw new Error("Theme collection bulunamadı — DS'de mode tanımlı değil");
const darkMode = colorCol.modes.find(m => m.name.toLowerCase().includes("dark"));
if (!darkMode) throw new Error("Dark mode bulunamadı — DS tek modlu");

const darkFrame = await figma.getNodeByIdAsync("<darkFrameId>");
darkFrame.setExplicitVariableModeForCollection(colorCol, darkMode.modeId);
return { status: "dark mode applied", mode: darkMode.name };

Sihir burada: setExplicitVariableModeForCollection ile tüm bound variable'lar otomatik olarak dark mode değerleri kullanır. Manuel swap gerekmez — tek bir API çağrısı tüm renkleri günceller. Bu yüzden Step 5.17'de her fill/stroke mutlaka variable'a bağlı olmalı — hardcoded kalanlar dark mode'da güncellenmez, light rengini taşır.

4. Her iki frame'i ayrı validate et:

figma_validate_screen(nodeId: <lightFrameId>, minScore: 80)
figma_validate_screen(nodeId: <darkFrameId>, minScore: 80)

İkisi de ≥80 olmalı. Biri fail ederse hardcoded değerler kaldı demektir — Step 5.17 Quality Gate'e dön.

Edge case: DS'de dark mode yoksa (sadece light), variants: "Light + Dark" seçimi kullanıcıya hata raporla: "Aktif DS'de dark mode tanımlı değil, sadece light üretildi. Dark mode için DS'nin Colors collection'ında Dark modu eklenmelidir."

Responsive + theme kombinasyonu: variants: ["Light + Dark", "Mobile + Web"] seçilirse matris oluşur (Light+Mobile / Light+Web / Dark+Mobile / Dark+Web = 4 frame). Her biri için ayrı wrapper, ayrı mode/device binding, ayrı validate. Turn budget'e dikkat — 4 frame için 4 turn harca (inter-screen checkpoint gate Step 6.6).

Known limitation: figma_validate_screen skorlama algoritması dark mode variable binding coverage'ını ayrıca ölçmez (plugin-side: f-mcp-plugin/code.js). Dark frame'de hardcoded renk kalmış olsa bile skor ≥80 alabilir. Bu yüzden Step 5.17 Quality Gate ve Step 5.6 adım 4'teki manuel binding kontrolü zorunludur — scora tek başına güvenme.

Step 6: Görsel Doğrulama

figma_capture_screenshot(nodeId="wrapper-frame-id")

Screenshot'ı incele:

• Bölümler doğru sırada mı?
• Spacing ve hizalama tutarlı mı?
• Renk ve tipografi DS'ye uygun mu?

Anti-Pattern Kontrolü (screenshot'a bakarak):

• ❌ Generic font mu kullanılmış? (DS font'u yokken Inter/Roboto/Arial)
• ❌ Mor gradient + beyaz arka plan? (klişe AI estetiği)
• ❌ Tahmin edilebilir grid? (12-col, hep aynı padding, her bölüm aynı)
• ❌ Her ekran birbirinin kopyası mı? (aynı layout, renk, font)
• ❌ "Bu bir AI'ın ürettiği gibi mi görünüyor?" → Evet ise revizyona dön

Sorun varsa hedefli figma_execute ile düzelt.

Step 6.5: Self-Audit Mandate (ZORUNLU — v1.8.1+)

Ekranı kullanıcıya sunmadan ÖNCE kendi kendini denetle. Bu adım atlanamaz — screenshot yeterli değil çünkü Claude görsel olarak "güzel" görünen ama token/bileşen disiplininden uzak ekranları fark edemez.

Adım 1 — figma_validate_screen çağır

figma_validate_screen(nodeId="wrapper-frame-id", expectedDs="❖ Ana-DS", minScore=80)

Tool şunu döner:

{
  "score": 92,
  "passed": true,
  "minScore": 80,
  "breakdown": {
    "instanceCoverage": 85,
    "libraryInstanceCount": 7,
    "autoLayoutCoverage": 100,
    "tokenBindingCoverage": 90
  },
  "violations": [],
  "recommendation": "Score 92/100 passed minimum 80. Screen is DS-compliant."
}

Adım 2 — Skor değerlendirmesi

Adım 3 — Retry Loop (max 3 deneme)

Eğer ilk denemede score < 80 ise:

1. Violations listesini oku (en kritik 5'i)
2. Her bir violation için figma_execute ile targeted fix uygula:
   • HARDCODED_FILL → figma_bind_variable ile binding ekle
   • NO_AUTO_LAYOUT → layoutMode = "VERTICAL" ekle
3. Tekrar figma_validate_screen çağır
4. Max 3 deneme. 3. denemede de fail ise:
   • Ekranı sil
   • Kullanıcıya rapor et: "3 denemede de minimum skoru yakalayamadım. Muhtemel sebepler: [list]. Elle düzeltmek mi, farklı yaklaşım mı denemek istersiniz?"

Adım 4 — Pass sonrası raporlama

Validation passed ise kullanıcıya özet çıkar:

✅ Ekran hazır: "Vadesiz TL - iPhone 17"
   📊 DS Compliance Score: 92/100
   🧩 Library Instances: 7
   🎨 Token Bindings: 24
   📐 Auto-Layout Coverage: 100%
   ⏱️ Süre: 18 saniye

Anti-patterns (Self-Audit atlamak)

❌ YANLIŞ: "Screenshot güzel görünüyor, validate'e gerek yok" → Bu bir disiplin kaçırmasıdır ✅ DOĞRU: Screenshot güzel olsa bile validate çalıştır. Token binding eksikliği gözle görülmez.

❌ YANLIŞ: Score 75 → "yeterince iyi, kullanıcıya sun" ✅ DOĞRU: Score < 80 → retry loop, ekranı düzelt

❌ YANLIŞ: Self-audit'i opsiyonel sayma ✅ DOĞRU: generate-figma-screen akışının tamamlanma koşulu bu adımdır. Validate çalıştırılmadan akış TAMAMLANMIŞ sayılmaz.

Step 6.6: Inter-Screen Checkpoint Gate + Turn Budget (ZORUNLU — v1.8.2+)

Kullanıcı birden fazla alternatif istediğinde (N > 1), her alternatif ayrı bir turn olmalıdır. Tek turn'de 2+ alternatif yapmak YASAK — tool-use limit'e takılır, chat donar.

Turn Budget Kuralı

Her turn'ün bütçesi:

• Maksimum 90 saniye toplam süre
• Maksimum 2 başarısız tool call (timeout/error)

Eğer turn içinde:

• 2 başarısız tool call (timeout/error) olursa, VEYA
• 60+ saniye geçti ve sonuç gelmediyse

→ Turn'ü "FAILED" olarak işaretle. Orphan cleanup uygula (fmcp-intent-router Tool Failure Recovery Protocol). Kullanıcıya checkpoint sorusunu sor.

Checkpoint Gate (Her Turn Sonrası)

Alternatif N tamamlandığında (başarılı veya fail), kullanıcıya AskUserQuestion ile sor:

✅/⚠️ Alternatif N/M ({name}) tamamlandı
   Node ID: 173:xxxxx
   Skor: XX/100
   Library instances: X
   Token bindings: Y
   Süre: Xs

Ne yapayım?
[✅ Beğendim, Alternatif N+1'e geç]
[✏️ Revize et (ne değişsin söyle)]
[🛑 Dur, bu yeter]

Kullanıcı yanıtı gelmeden bir sonraki alternatife GEÇME. Turn boundary kuralı budur.

Yasaklar

❌ YANLIŞ: Tek turn'de 3 alternatifi de yap, en sonda tek özet ✅ DOĞRU: Her alternatif ayrı turn, her biri sonunda checkpoint

❌ YANLIŞ: Turn içinde 3+ retry (sonsuz döngü) ✅ DOĞRU: 2 retry max, sonra Turn FAILED + kullanıcıya sor

❌ YANLIŞ: Alternatif N başarısız, sessizce N+1'e geç ✅ DOĞRU: N başarısız olunca orphan cleanup + rapor + checkpoint

Step 6.7: Prototip Bağlantı Teklifi (Opsiyonel, v1.9.9+)

Oturumda 2 veya daha fazla frame üretildiyse kullanıcıya öner:

"Bu oturumda X ekran ürettim (Login, Home, Register). Bunları birbirine bağlamak için
`figma-prototype-flow` skill'ini kullanabiliriz — otomatik navigasyon haritası çıkarır,
animasyon + flow starting point oluşturur.

Şimdi başlatayım mı? (Üretilen frame ID'leri hazır: 1:2, 1:3, 1:4)"

• Skill-to-skill invoke YOK — FMCP'de programatik skill tetikleme mekanizması yok. Kullanıcı onaylarsa Claude yeni bir intent olarak skill'i tetikler (fmcp-intent-router üzerinden).
• Kullanıcı evet derse: screen_scope=Node ID listesi parametresiyle, üretilen frame ID'lerini listele.
• Kullanıcı hayır veya sessiz kalırsa: önerme kaydedilir, Step 7'ye geç.

Önkoşul: Üretilen frame'lerin içinde en az 1 Button/Link instance'ı olmalı (aksi halde heuristic işe yaramaz).

Step 7: Güncelleme Senaryosu

Mevcut bir ekranı güncellerken:

1. figma_get_file_data ile mevcut yapıyı oku
2. figma_get_design_context ile değişecek bölümü analiz et
3. Yalnızca değişen bölümü yeniden oluştur veya güncelle
4. Tüm ekranı baştan oluşturmaktan kaçın

Türkçe Karakter Kuralı (ZORUNLU)

Tüm Türkçe metin içeriklerinde (Figma text node, kod string, dokümantasyon) doğru Unicode karakterler kullanılmalıdır. ASCII karşılıkları YASAKTIR:

Son adım: Üretilen tüm Türkçe metinleri karakter kontrolünden geçir.

Performans Kuralları

• Aynı oturumda figma_get_variables(verbosity="full") birden fazla çağırma — ilk sonucu kullan. verbosity="full" 500K+ karakter üretir, asla full kullanma — summary yeterli.
• figma_search_components: varsayılan currentPageOnly=true; false yalnızca gerektiğinde (timeout riski)
• Her figma_execute çağrısı küçük ve odaklı olmalı — 50+ satır kod riski yüksek
• Asla 3 paralel agent çalıştırma — gereksiz token tüketir. Key'ler .claude/libraries/ dosyasında cache'liyse agent bile gereksiz.
• Performans bütçesi: Ekran başına ≤5 figma_execute (3 core + 1 hata buffer + 1 doğrulama), <130K token hedefi. Cache'li çalışmada <100K.
• Timeout: 1-5 node → 5000ms | 6-12 node → 10000ms | 13+ node → 15-30000ms veya işlemi böl

Responsive Boyut Presetleri (ZORUNLU)

Her ekran minimum 3 boyutta oluşturulmalı:

Uygulama (3 adım):

Adım 1: Breakpoint token'ları oluştur (bir kerelik)

Primitives collection'a ekran boyut token'ları ekle:

screen/mobile-width: 390    screen/tablet-width: 768    screen/web-width: 1440
screen/tablet-padding: 120  screen/web-padding: 480
screen/top-padding-mobile: 80  screen/top-padding-tablet: 160
screen/bottom-padding: 40

Semantic collection'a alias'lar ekle:

layout/screen-mobile-width → screen/mobile-width
layout/screen-tablet-width → screen/tablet-width
layout/screen-web-width → screen/web-width
layout/screen-tablet-padding → screen/tablet-padding
layout/screen-web-padding → screen/web-padding

Adım 2: Ekranları oluştur ve klonla

// figma_execute — Mobile (master)
const mobile = figma.createFrame();
mobile.name = "Screen / Mobile";
mobile.layoutMode = "VERTICAL";
// ... içerik ekle ...

Tablet ve Web klonla → resize et.

Adım 3: Ekran boyutlarını token'lara bağla (ZORUNLU)

Her ekranın width ve padding'i variable'a bağlanmalı. Hard-coded değer KABUL EDİLMEZ:

// figma_execute — Token binding (her ekran için)
const semVars = {}; // semantic variable'ları yükle

// Mobile
const mobile = await figma.getNodeByIdAsync("<MOBILE_ID>");
mobile.setBoundVariable("width", semVars["layout/screen-mobile-width"]);
mobile.setBoundVariable("paddingLeft", semVars["layout/page-padding"]);
mobile.setBoundVariable("paddingRight", semVars["layout/page-padding"]);
mobile.setBoundVariable("paddingTop", semVars["layout/screen-top-padding-mobile"]);
mobile.setBoundVariable("paddingBottom", semVars["layout/screen-bottom-padding"]);

// Tablet
const tablet = await figma.getNodeByIdAsync("<TABLET_ID>");
tablet.setBoundVariable("width", semVars["layout/screen-tablet-width"]);
tablet.setBoundVariable("paddingLeft", semVars["layout/screen-tablet-padding"]);
tablet.setBoundVariable("paddingRight", semVars["layout/screen-tablet-padding"]);
tablet.setBoundVariable("paddingTop", semVars["layout/screen-top-padding-tablet"]);

// Web
const web = await figma.getNodeByIdAsync("<WEB_ID>");
web.setBoundVariable("width", semVars["layout/screen-web-width"]);
web.setBoundVariable("paddingLeft", semVars["layout/screen-web-padding"]);
web.setBoundVariable("paddingRight", semVars["layout/screen-web-padding"]);

Min Height bağlama (ZORUNLU):

Ekranın minimum yüksekliği de token'a bağlanmalı. Figma'da "Fixed height (900)" yerine "Add min height..." → "Apply variable..." kullanılmalı:

// Her ekran için minHeight bağla
mobile.setBoundVariable("minHeight", primVars["screen/mobile-height"]); // 844
tablet.setBoundVariable("minHeight", primVars["screen/tablet-height"]); // 1024
web.setBoundVariable("minHeight", primVars["screen/web-height"]);       // 900

Kural: Figma'da tüm boyut değerleri (width, minHeight, padding) "Apply variable..." ile token bağlı görünmeli. Hard-coded değer KABUL EDİLMEZ. Bu, breakpoint değiştiğinde tüm ekranların otomatik güncellenmesini sağlar.

Dark Mode (ZORUNLU)

Her ekran Light ve Dark tema olarak oluşturulmalı.

Free Plan (1 mode sınırı):

Ayrı "Primitives Dark" collection oluştur, aynı token isimleriyle dark değerler ver. Ekranı klonla ve dark renkleri uygula:

// figma_execute — Dark mode uygulama
const lightScreen = await figma.getNodeByIdAsync("<LIGHT_NODE_ID>");
const darkScreen = lightScreen.clone();
darkScreen.name = lightScreen.name + " / Dark";
// Arka planı dark yapSet background and traverse children to apply dark palette

Professional+ Plan (çoklu mode):

Light ekranı klonla, collection OBJECT ile mode set et. String ID çalışmaz — library API chain zorunlu:

// 1. Collection object al
var colls = await figma.teamLibrary.getAvailableLibraryVariableCollectionsAsync();
var semCol = colls.find(function(c){ return c.name.indexOf("Semantic Colors") !== -1; });
var vars = await figma.teamLibrary.getVariablesInLibraryCollectionAsync(semCol.key);
var firstVar = await figma.variables.importVariableByKeyAsync(vars[0].key);
var localColl = await figma.variables.getVariableCollectionByIdAsync(firstVar.variableCollectionId);
var darkMode = localColl.modes.find(function(m){ return m.name === "Dark"; });

// 2. Dark ekrana set et
dark.setExplicitVariableModeForCollection(localColl, darkMode.modeId);

Semantic Sizes Mode Binding (ZORUNLU)

Her ekran frame'inde Semantic Sizes collection'a da mode set edilmeli. Figma Appearance panelinde hem renk hem boyut mode'u görünmeli:

// Semantic Sizes collection object al (aynı chain)
var sizeColls = await figma.teamLibrary.getAvailableLibraryVariableCollectionsAsync();
var semSize = sizeColls.find(function(c){ return c.name.indexOf("Semantic Sizes") !== -1; });
var sizeVars = await figma.teamLibrary.getVariablesInLibraryCollectionAsync(semSize.key);
var sizeFirst = await figma.variables.importVariableByKeyAsync(sizeVars[0].key);
var localSizeColl = await figma.variables.getVariableCollectionByIdAsync(sizeFirst.variableCollectionId);

var webMode = localSizeColl.modes.find(function(m){ return m.name.indexOf("Web Desktop") !== -1; });
var tabletMode = localSizeColl.modes.find(function(m){ return m.name.indexOf("Tablet") !== -1; });
var mobilMode = localSizeColl.modes.find(function(m){ return m.name.indexOf("Mobil") !== -1; });

// Her ekrana size mode set et
webScreen.setExplicitVariableModeForCollection(localSizeColl, webMode.modeId);
tabletScreen.setExplicitVariableModeForCollection(localSizeColl, tabletMode.modeId);
mobileScreen.setExplicitVariableModeForCollection(localSizeColl, mobilMode.modeId);

Sonuç: Her ekranın Figma Appearance panelinde:

• Semantic Colors → Light / Dark
• Semantic Sizes → Web Desktop / Tablet / Mobil & Web Mobil
• W alanı → breakpoint token'ına bound

Toplam Ekran Matrisi:

Mobile Light | Mobile Dark
Tablet Light | Tablet Dark
Web Light    | Web Dark
= 6 ekran minimum

Çıktı Formatı

• Oluşturulan tüm ekranların Figma node ID'leri (6 ekran)
• DS uyum özeti (kaç instance, kaç variable bağlı)
• Responsive doğrulama: her boyutta screenshot
• Dark/Light tema screenshot karşılaştırma

Evolution Triggers

• Bridge'e asset arama veya otomatik ekran üretme aracı eklenirse paralel iş akışı eklenmeli
• Yeni bileşen instance araçları eklenirse Step 5 kalıbı güncellenmeli
• Mobil platform desteği genişletilirse boyut presetleri eklenmeli