HTML Taslak Çizici

Taslak

Bu beceriyi, kullanıcı bir tasarıma karar vermeden önce tasarım yönünü görmek istediğinde kullanın — bir UI/UX fikrini, atılıp yeniden yapılabilecek HTML maketler olarak keşfetmek için. Amaç, kullanıcının görsel yönleri yan yana karşılaştırabilmesi için 2-3 etkileşimli varyant üretmektir; teslim edilebilir kod üretmek değil.

Kullanıcı şunları söylediğinde bu beceriyi yükleyin: "bu ekranı taslakla", "X nasıl görünebilir göster", "A ve B düzenini karşılaştır", "bu arayüz için 2-3 farklı yorum ver", "birkaç varyant göreyim", "inşa etmeden önce bunun maketini yap".

Ne zaman KULLANILMAMALI

• Kullanıcı bir üretim bileşeni istiyor — claude-design kullanın ya da düzgün bir şekilde inşa edin
• Kullanıcı gösterişli, tek seferlik bir HTML çalışması (açılış sayfası, sunum) istiyor — claude-design
• Kullanıcı bir diyagram istiyor — excalidraw, architecture-diagram
• Tasarım zaten kilitlenmiş — sadece inşa edin

Kullanıcı tam GSD sistemine sahipse

Eğer gsd-sketch bir kardeş beceri olarak görünüyorsa (npx get-shit-done-cc --hermes ile yüklenmiş), tam iş akışı için gsd-sketch tercih edin: MANIFEST ile kalıcı .planning/sketches/, frontier modu analizi, geçmiş taslaklar arasında tutarlılık denetimleri ve GSD'nin geri kalanıyla entegrasyon. Bu beceri, durum makinesi olmadan hafif bir bağımsız sürümdür — tek seferlik taslaklama.

Temel yöntem

girdi  →  varyantlar  →  başa baş karşılaştırma  →  kazananı seç (veya yinele)

1. Girdi (kullanıcı zaten yeterli bilgi verdiyse atlayın)

Varyantları oluşturmadan önce üç şeyi öğrenin — hepsini bir anda değil, her seferinde bir soru:

1. His. "Bu nasıl hissettirmeli? Sıfatlar, duygular, bir atmosfer." — "sakin, editoryal, Linear gibi" demek "minimal" demekten daha fazlasını anlatır.
2. Referanslar. "Hangi uygulamalar, siteler veya ürünler hayal ettiğiniz hissi yakalıyor?" — gerçek referanslar soyut tariflerden üstündür.
3. Temel eylem. "Bir kullanıcının bu ekranda yaptığı en önemli tek şey nedir?" — varyantların hepsi buna iyi hizmet etmeli; etmezlerse yalnızca dekorasyondurlar.

Bir sonraki soruya geçmeden her yanıtı kısaca yansıtın. Kullanıcı üçünü de önceden verdiyse doğrudan varyantlara geçin.

2. Varyantlar (2-3 tane, asla 1, nadiren 4+)

Bir seferde 2-3 varyant üretin. Her varyant tam, kendi başına çalışan bir HTML dosyasıdır. Varyantları tarif etmeyin — inşa edin. Amaç karşılaştırmadır.

Her varyant farklı bir tasarım duruşu almalıdır, farklı piksel değerleri değil. Üç iyi varyant ekseni:

• Yoğunluk: kompakt / havadar / ultra-yoğun (iki karşıt uç seçin)
• Vurgu: içerik-öncelikli / eylem-öncelikli / araç-öncelikli
• Estetik: editoryal / faydacı / oyuncu
• Düzen: tek sütun / kenar çubuğu / bölünmüş panel
• Temellendirme: kart-tabanlı / yalın-içerik / belge-stili

Bir eksen seçin ve ondan ayrıştırın. Yalnızca vurgu renginde farklılık gösteren iki varyant boşa harcanmış çabadır — kullanıcı onları ayırt edemez.

Varyant adlandırma: duruşu tarif edin, numarayı değil.

taslaklar/
├── 001-sakin-editoryal/
│   ├── index.html
│   └── README.md
├── 001-faydacı-yoğun/
│   ├── index.html
│   └── README.md
└── 001-oyuncu-bölünmüş/
    ├── index.html
    └── README.md

3. Onları gerçek HTML yapın

Her varyant tek başına çalışan bir HTML dosyasıdır:

• Satır içi <style> — derleme adımı yok, harici CSS yok
• Sistem fontları veya <link> ile bir Google Font
• CDN üzerinden Tailwind (<script src="https://cdn.tailwindcss.com"></script>) uygundur
• Gerçekçi sahte içerik — gerçek cümleler, gerçek isimler, "Lorem ipsum" değil
• Etkileşimli: bağlantılar tıklanabilir, üzerine gelmeler gerçek, en az bir durum geçişi (aç/kapat, filtrele, aç/kapa). Donmuş statik bir görüntü, özensiz animasyonlu olandan daha kötü bir prototiptir.

Tarayıcıda açın. Bozuk görünüyorsa, kullanıcıya göstermeden önce düzeltin.

Varyantları görsel olarak doğrulayın — Hermes'in tarayıcı araçlarını kullanın. Sadece HTML yazıp düzgün görüntülendiğini ummayın; her varyantı yükleyin ve bakın:

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Bu düzen temiz ve okunabilir görünüyor mu? Görünür hatalar var mı (üst üste binen metin, stillendirilmemiş öğeler, bozuk resimler)?")

browser_vision sayfada gerçekten ne olduğuna dair bir AI açıklaması artı bir ekran görüntüsü yolu döndürür — salt kaynak incelemenin kaçırdığı düzen hatalarını yakalar (örn. sessizce başarısız olmuş bir font içe aktarımı, çökmüş bir flex konteyner). Her varyant doğru görünene kadar düzeltip yeniden gezin.

Hızlı başlangıçlar için varsayılan CSS sıfırlaması + sistem font yığını:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. Varyant README

Her varyantın README.md'si şunları yanıtlar:

## Varyant: {duruş adı}

### Tasarım duruşu
Bu varyantı yönlendiren ilkeyi tek cümleyle.

### Temel seçimler
- Düzen: ...
- Tipografi: ...
- Renk: ...
- Etkileşim: ...

### Ödünleşmeler
- Güçlü olduğu: ...
- Zayıf olduğu: ...

### En iyi olduğu
- Bu varyantın gerçekten hizmet ettiği kullanıcı tipi veya kullanım durumu

5. Başa baş

Tüm varyantlar inşa edildikten sonra, onları bir karşılaştırma olarak sunun. Sadece listelemeyin — yorumlayın:

## Ana ekran için üç yorum

| Boyut | Sakin editoryal | Faydacı yoğun | Oyuncu bölünmüş |
|-----------|----------------|-------------------|---------------|
| Yoğunluk   | Düşük            | Yüksek              | Orta        |
| Birincil eylem görünürlüğü | Düşük | Yüksek | Orta |
| Taranabilirlik | Yüksek | Orta | Düşük |
| His | Sakin, güvenilir | Keskin, alet gibi | Davetkar, enerjik |

**Benim yorumum:** Güç kullanıcıları için faydacı yoğun, içerik odaklı kitleler için sakin editoryal. Oyuncu bölünmüş en zayıfı — ikisini birden yapmaya çalışıp hiçbirine bağlanmıyor.

Kullanıcının bir kazanan seçmesine, ikisini birleştirip melez bir tane oluşturmasına ya da başka bir tur istemesine izin verin.

Tema oluşturma (projenin görsel bir kimliği olduğunda)

Kullanıcının mevcut bir teması (renkler, fontlar, jetonlar) varsa, paylaşılan jetonları sketches/themes/tokens.css dosyasına koyun ve her varyantta @import edin. Jetonları minimal tutun:

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

Atılıp yeniden kullanılacak bir taslağı aşırı jetonlaştırmayın — genellikle üç renk ve bir font yeterlidir.

Etkileşim çıtası

Bir taslak, kullanıcı şunları yapabildiğinde yeterince etkileşimlidir:

1. Birincil eyleme tıklayabilir ve görünür bir şey olur (durum değişikliği, modal, bildirim, gezinme yanılsaması)
2. Anlamlı bir durum geçişi görebilir (bir listeyi filtreleyebilir, bir modu değiştirebilir, bir paneli açıp kapatabilir)
3. Tanınabilir eylem belirteçlerinin üzerine gelebilir (düğmeler, satırlar, sekmeler)

Bundan fazlası, atılıp yeniden kullanılacak bir şey için aşırı mühendisliktir. Daha azı ise bir ekran görüntüsüdür.

Frontier modu (sırada neyi taslaklayacağını seçme)

Taslaklar zaten mevcutsa ve kullanıcı "sırada neyi taslaklamalıyım?" derse:

• Tutarlılık boşlukları — farklı taslaklardan kazanan iki varyant, henüz birleştirilmemiş bağımsız seçimler yapmıştır
• Taslaklanmamış ekranlar — referans verilmiş ama hiç keşfedilmemiş
• Durum kapsamı — mutlu yol taslaklanmış, ama boş / yükleniyor / hata / 1000-öğe durumları yok
• Duyarlılık boşlukları — tek bir görüntü alanında doğrulanmış; mobil / ultra geniş ekranda tutarlı mı?
• Etkileşim desenleri — statik düzenler var; geçişler, sürükleme, kaydırma davranışı yok

2-4 adet adlandırılmış aday önerin. Kullanıcının seçmesine izin verin.

Çıktı

• Depo kökünde sketches/ (veya kullanıcı GSD kurallarını kullanıyorsa .planning/sketches/) oluşturun
• Varyant başına bir alt dizin: NNN-duruş-adı/index.html + README.md
• Kullanıcıya nasıl açacaklarını söyleyin: macOS'ta open sketches/001-sakin-editoryal/index.html, Linux'ta xdg-open, Windows'ta start
• Varyantları atılabilir tutun — koruma ihtiyacı hissettiğiniz bir taslak gerçek proje koduna yükseltilmeli, bir varlık olarak düzenlenmemelidir

Bir varyant için tipik araç sırası:

terminal("mkdir -p sketches/001-sakin-editoryal")
write_file("sketches/001-sakin-editoryal/index.html", "<!doctype html>...")
write_file("sketches/001-sakin-editoryal/README.md", "## Varyant: Sakin editoryal\n...")
browser_navigate(url="file://$(pwd)/sketches/001-sakin-editoryal/index.html")
browser_vision(question="Bu nasıl görünüyor? Bariz düzen sorunları var mı?")

Her varyant için tekrarlayın, ardından karşılaştırma tablosunu sunun.

Atıf

GSD (Get Shit Done) projesinin /gsd-sketch iş akışından uyarlanmıştır — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). Tam GSD sistemi, kalıcı taslak durumu, tema/varyant deseni referansları ve tutarlılık denetimi iş akışları sağlar; npx get-shit-done-cc --hermes --global ile yükleyin.