Claude Code Tam Workflow — fikirden deploy'a

Bu workshop’ta Eric Tech’in 12 dakikalık “My Complete Claude Code Workflow” videosunda anlattığı end-to-end akışı kendi makinende uçtan uca uygulayacağız. Örnek olarak basit bir Astro + TypeScript bookmark/link kaydedici (link-vault) kuracağız; ama akış proje-agnostik — kendi mini-projende de aynı adımlar geçerli. Üç topluluk repo’sundan yararlanacağız: obra/superpowers (brainstorm, plan, debug skill’leri), mattpocock/skills (engineering skill’leri) ve garrytan/gstack (slash komut toolkit’i). Komut zinciri: claude (interactive) + gh CLI (issues + projects) + claude -p (headless subagent spawn). Sayfayı bitirdiğinde elinde çalışan bir uygulama, GitHub repo + Project board, otonom build döngüsünden çıkmış merge’lenmiş PR serisi, QA raporu ve verify-fix-*.md log’ları olacak.

Bu videoda ne anlatılıyor

Konuşmacı: Eric Tech — eski Amazon ve Microsoft yazılım mühendisi, şimdi BookZero.AI kurucusu (fiş ve işlem yönetimi için AI platformu). Videoda kendi günlük Claude Code akışını fikirden deploy’a kadar 12 dakikada anlatıyor.

Anlatım yapısı (7 ana parça):

1. Brainstorm: fikri Claude Code’un takip edebileceği netlikte spec’e çevirmek için 3 farklı framework — mattpocock/skills (Interview), obra/superpowers (Workshop), garrytan/gstack (Board of Directors).
2. UI tasarımı: Spec’ten claude.ai/design’a geçip etkileşimli prototip üretmek; Claude Code’un build sırasında UI sürprizleri yapmasını engellemek.
3. Context rot: Token sayısı arttıkça tüm LLM’lerin (Claude, OpenAI, Gemini, Qwen) doğruluğunun düşmesi. Tek konuşmada her şeyi yapmama gerekçesi.
4. Fazlara bölme: GStack /autoplan ile spec’i 5–8 bağımsız faza bölmek — her faz ayrı bir context bütçesi.
5. GitHub Projects kanban: Fazları issue’lara dönüştürüp Backlog → Ready → In progress → In review → Done akışına bağlamak. gh CLI Claude Code’la default geliyor — MCP gerekmez.
6. Autonomous build loop: Bir parent orchestrator session’ın Ready kolonu boşalana kadar fresh claude --headless session’lar açıp her ticket’ı çalıştırması.
7. QA + verify-fix loop: GStack /qa ile bug bash, ardından aynı orchestrator pattern’i bug raporunu girdi alarak 2 ardışık temiz iterasyon görene kadar tekrar çalıştırmak.

Sayfanın altındaki video player üstündeki repo kartlarından her parçanın detayına dalabilirsin. Aşağıdaki tablo videodaki timestamp’lerin doğrudan linklerini verir:

Örnek projemiz: link-vault

Workshop boyunca somut bir mini-uygulama üstünde çalışacağız: link-vault — kişisel link/bookmark kaydedici. Astro + TypeScript, veri localStorage’da (auth ve sunucu yok), ufak ama videodaki tüm akışı ezberlemeye yetecek kadar katmanlı.

Sayfalar (4):

• / — kayıtlı link listesi (en yeni üstte, etiket filtreleri)
• /new — yeni link ekleme formu (URL + başlık + etiketler)
• /tag/[slug] — belirli bir etikete sahip linkleri listele
• /search?q=… — başlık + URL üzerinden arama

Data model:

type Link = {
  id: string;          // crypto.randomUUID()
  url: string;
  title: string;
  tags: string[];      // tag.slug referansları
  addedAt: string;     // ISO date
};
type Tag = { slug: string; color?: string };

Out-of-scope (V1): auth, supabase / sunucu sync, sosyal paylaşım, OG-image preview. Bu sınırlamalar projeyi 5–7 fazlık net bir kapsamda tutar.

Hedefimiz nedir

Bu workshop’un hedefi: videoda anlatılan profesyonel akışı kendi mini-projende uçtan uca uygulamak ve süreç ezberini kazanmak. Sonraki projelerinde Adım 1-3’ü 30 dakikaya indirip doğrudan otonom build loop’una geçebilmelisin.

Bitirdiğinde elinde olacaklar:

• ✅ docs/spec.md — ürün açıklaması, senaryolar, data model
• ✅ design/ — 4 sayfa HTML/CSS prototip + design tokenları
• ✅ phases/phase-*.md — 5–8 fazlık ardışık plan
• ✅ GitHub repo + Project board (issue’lar Done’da, PR’lar merge’lenmiş)
• ✅ Otonom build loop’tan çıkmış commit serisi
• ✅ QA bug raporu + verify-fix log’ları
• ✅ Çalışan bir uygulama (pnpm dev ya da canlı URL)

Hedef kitle: Claude Code’u tanıyan, GitHub kanban + gh CLI ile az çok haşır neşir biri. Hiç başlangıç değilsen ekstra: obra/superpowers veya garrytan/gstack skill’lerinden en az birine aşinalık avantaj.

Benzer bir workshop yapacağız

Eric Tech videoda kendi FitBox Admin Console örneğini gösteriyor; biz senin seçtiğin bir mini-proje üstünde aynı akışı uygulayacağız. Komutlar link-vault placeholder’ı kullanır — sen kendi adınla değiştirirsin.

Generic akış (özet):

GitHub'da boş repo aç
   ↓
spec.md yaz (brainstorm framework'lerinden biriyle)
   ↓
design/ üret (Claude Design veya CLI fallback)
   ↓
spec'i fazlara böl (autoplan veya writing-plans)
   ↓
fazları issue olarak GitHub Projects'e koy, kanban kolonlarına diz
   ↓
build-loop slash komutu yaz, Claude'u Ready kolonundaki ilk issue'ya ata
   ↓
PR'lar otomatik açılır → CI yeşilse merge → issue Done'a düşer (loop)
   ↓
/qa ile bug bash (Chromium otomasyonu)
   ↓
verify-fix-loop ile 2 ardışık temiz iterasyon görene kadar tekrar QA

Gerekli repolar ve komutlar

Workshop boyunca üç farklı topluluk repo’sundan yararlanıyoruz. Her birinin ne için, nasıl kurulduğu ve hangi adımda devreye girdiği aşağıda:

Önkoşullar (kurulu olmalı):

• Claude Code (claude CLI, giriş yapılmış)
• gh CLI (Claude Code default’unda gelir)
• Node 20+ ve pnpm/npm
• GitHub hesabı

Kurulum komutları (üçü de farklı yöntem kullanır):

# 1) Superpowers — Claude Code marketplace plugin'i
claude
> /plugin install superpowers@claude-plugins-official

# 2) mattpocock/skills — npx ile (Claude Code dışı bir CLI)
npx skills@latest add mattpocock/skills

# 3) gstack — git clone + setup script
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
&& cd ~/.claude/skills/gstack && ./setup
# Kurulum bitince yeni bir terminalde `claude` session başlat — slash komutlar yüklü gelir.

Hazırlık (Adım 0)

Tüm adımlar boş bir GitHub repo + boş yerel klasörden başlar.

mkdir link-vault && cd link-vault
git init
gh repo create link-vault --private --source=. --remote=origin
echo "node_modules/\ndist/\n.astro/\n.env" > .gitignore
git add . && git commit -m "chore: initial workspace"
git push -u origin main

claude   # bu klasörde Claude Code session başlat

# Adım 01 Fikirden gereksinime: 3 brainstorm framework'ü 1:18

Devreye giren araç: obra/superpowers (brainstorming) veya mattpocock/skills (grill-me) veya garrytan/gstack (/office-hours + /plan-*-review zinciri) — kafandaki netliğe göre.

İlk iş: kafandaki fikri Claude Code’un takip edebileceği bir spec/blueprint’e dönüştürmek. Üç farklı yaklaşım var, hangisini seçeceğin ne kadar netliğin olduğuna bağlı.

• mattpocock/skills — Interview (1 yön). “grill-me” skill’i sıkı sorgulama yapar; ne istediğini biliyorsan açıkları kapatır.
• obra/superpowers — Workshop (2 yön). “brainstorming” skill’i context’e bakıp soru sorar, alternatif önerir, tasarımı bölümler hâlinde sunar.
• garrytan/gstack — Board of Directors (N yön). /office-hours, /plan-ceo-review, /plan-eng-review, /plan-design-review, /plan-devex-review ardışık skill’leri farklı role perspektiflerinden eleştirir.

claude   # workspace klasörünün içinde
> link-vault adında basit bir Astro + TypeScript bookmark/link kaydedici yapacağım.
> 4 sayfa olacak: liste (/), yeni-ekle (/new), etiket detayı (/tag/[slug]), arama (/search).
> Veri localStorage'da, auth yok, sunucu yok. Etiketler çoklu seçimli.
> superpowers/brainstorming skill'i ile beni yönlendirir misin? Eksiklerimi sor,
> data model'i netleştirelim, sonunda docs/spec.md olarak yaz.

# Adım 02 Gereksinimden UI tasarımı (Claude Design) 3:56

Devreye giren araç: claude.ai/design (Anthropic Labs Research Preview) — erişimin yoksa Claude Code’a doğrudan mockup yazdırma fallback’i.

Spec’in olduğunda Claude Code’a UI’ı doğrudan oluşturtmak yerine Claude Design’a teslim et. Sebep: Claude Code build aşamasında “buton şuraya, density compact, dil EN/中文” gibi tüm sürpriz kararları sürekli yeniden vermek zorunda kalır — bu hem context’i şişirir hem doğruluğu düşürür.

Akış:

1. claude.ai/design adresine git, Prototype → High fidelity seç.
2. Spec’in özeti + birkaç HTML wireframe yapıştır.
3. Üretilen prototipi Tweaks panelinden ayarla: rol (Admin/CS/Production…), dil, density (compact/comfortable), palette (default/bold/muted).
4. Tasarım hazır olunca sağ üstten Share → çıktıyı Claude Code’a aktar.

# Claude Design erişimin yoksa, Claude Code'a doğrudan ver
claude
> docs/spec.md'yi oku ve design/ klasörü altında her sayfa için Tailwind tabanlı
> static HTML mockup üret. Dosya isimleri: list.html, new.html, by-tag.html, search.html.
> Her sayfada minimum: header (logo + nav: "Liste / Ekle / Etiketler / Ara"),
> main content area (link cards / form / arama box), footer.
> Tek bir tokens.css'te primary/surface/text/accent renklerini tanımla.
> Card stiline dikkat: link başlığı, URL hostname'i (kısaltılmış), etiket rozetleri, eklenme tarihi.

# Adım 03 Context rot tuzağı ve fazlara bölme 5:27

Devreye giren araç: garrytan/gstack (/autoplan — CEO/design/eng review zinciri) veya obra/superpowers (writing-plans skill’i, slash gerekmez).

Spec + UI tek bir konuşmaya yapıştırmak en yaygın hata. Context rot denilen olgu yüzünden token sayısı arttıkça LLM’in doğruluğu düşer — Claude bile, OpenAI bile, hepsi.

Çözüm: spec’i fazlara böl, her faz kendi temiz Claude Code session’ında çalışsın. gstack’in /autoplan skill’i bunu üç ardışık review ile yapar (CEO → design → eng).

# spec.md ve design/ hazır olduktan sonra
claude
> /autoplan
# /autoplan üç skill'i sırayla tetikler:
#   /plan-ceo-review     — strateji & kapsam
#   /plan-design-review  — tasarım denetimi
#   /plan-eng-review     — mimari + faz ayrımı

Çıktı: faz markdown’ları + her fazın bağımlılıkları. Her faz bağımsız çalıştırılabilir, kendi context bütçesi var. Hedef: bir konuşmada %50 dolulukta kalmak.

# Adım 04 Fazları GitHub Projects'e bağla 6:55

Devreye giren araç: gh CLI (Claude Code default) — Issue + Project API’larını doğrudan kullanır, ekstra MCP veya CLI gerekmez.

Fazları takip etmek için Jira veya başka bir araç kurma — gh CLI Claude Code’a default geliyor, GitHub Projects bedava ve Claude direkt issues + projects API’ına erişebiliyor.

Akış:

1. GitHub’da repo altında bir Project oluştur (Kanban template).
2. Her faz markdown’unu bir issue’ya çevir.
3. Issue’ları project’e ekle, ilk 1-2 tanesini Ready kolonuna taşı.
4. PR açılırken Closes #N ile issue’yu bağla — merge edildiğinde otomatik Done’a düşer.

# 1) Project oluştur
gh project create --owner @me --title "link-vault"
# Çıkacak: <project-number> (örn: 5) — bunu not et

# 2) Her phase için issue
for f in phases/phase-*.md; do
TITLE=$(head -n 1 "$f" | sed 's/# //')
gh issue create --title "$TITLE" --body-file "$f"
done

# 3) Issue'ları project'e ekle
REPO=$(gh repo view --json owner,name -q '.owner.login + "/" + .name')
gh issue list --json number --jq '.[].number' | while read num; do
gh project item-add <project-number> --owner @me --url "https://github.com/$REPO/issues/$num"
done

# 4) İlk 1-2 issue'yu Ready kolonuna taşı (UI'da sürükle bırak veya gh project item-edit)

# Adım 05 Build loop ile otonom üretim 8:42

Devreye giren araç: Kendi yazdığın .claude/commands/build-loop.md slash komutu (gstack/superpowers’ta hazır YOK) + claude --headless (subagent spawn).

Manuel “şu issue’yu çalış, sonra şunu” döngüsü yorucu. Bunun yerine build-loop orchestrator pattern’i: bir parent session sürekli yeni headless Claude session’lar açar, her biri bir issue alır, biter, kapanır.

Mantık:

• state = GitHub Projects board (Ready kolonu)
• orchestrator = parent Claude session, döngüyü yönetir
• headless = claude -p "<prompt>" (non-interactive mode), her iterasyonda fresh context
• döngü = Ready kolonu boşalana kadar tek tek ticket al → çalıştır → PR aç → kapat

Sen build-loop orkestratörüsün. Aşağıdaki döngüyü Ready kolonu boşalana kadar tekrarla:

1. `gh issue list --state open --label ready --json number,title,body --limit 1`
2. Eğer dönen liste boşsa → "Done" yaz ve dur.
3. Issue'yu In Progress'e taşı: `gh project item-edit ... --field-id Status --single-select-option-id "In progress"`
4. `claude -p "Issue #{n}'i çöz: {body}. PR aç, 'Closes #{n}' ekle."` çalıştır.
5. PR merge edildiğinde GitHub Projects otomatik Done'a taşır. Adım 1'e dön.

Her iterasyon yeni bir process spawn eder; parent context şişmez.

# Slash komut .claude/commands/ altındaysa Claude Code otomatik tanır
claude
> /build-loop

# Adım 06 QA / bug bash otomasyonu 9:08

Devreye giren araç: garrytan/gstack (/qa veya /qa-only) — Chromium tabanlı BFS gezinti + otomatik fix. Alternatif: Playwright + Claude prompt + MCP Chrome DevTools.

TDD ile birim testler yeşil olsa da, manuel “her sayfayı bir tıkla” turu (bug bash) gerekir. gstack’in /qa komutu Chromium spin up edip uygulamanın her sayfasını breadth-first dolaşır, bulduğu bug’ları otomatik düzeltir. Sadece raporlama istiyorsan /qa-only kullanırsın.

Çalışma mantığı:

1. Login sayfasından başlar → Dashboard → kategoriler/altsayfalar/filtreler.
2. Her sayfada görünen elementlerin state’ini kaydeder; aynı sayfayı 2 kez gezmez.
3. Console error / network 4xx/5xx / unhandled exception → bug raporu.

# Astro default port 4321 — pnpm dev başlattıktan sonra
claude
> /qa http://localhost:4321
# /qa = bug bul + fix
# /qa-only = sadece bul, raporla (fix etme)

# Adım 07 Verify-fix loop 10:42

Devreye giren araç: Kendi yazdığın .claude/commands/verify-fix-loop.md slash + gstack /qa (her iterasyonda fresh session) + obra/superpowers debugging skill’i fix tarafında.

/qa tek seferde her bug’u yakalayamaz — özellikle ilk fix yeni bug üretebilir. Verify-fix-loop, build-loop ile aynı orkestratör pattern’in bu sefer girdi olarak QA çıktısını alan versiyonu.

Akış (kendi .claude/commands/verify-fix-loop.md):

1. state = boş veya önceki iterasyonun bug raporu
2. Her iterasyon fresh headless session’da claude -p "/qa http://localhost:4321" çalışır
3. Çıktı 0 bug → counter++, 2 ardışık 0 → loop’tan çık
4. Çıktı bug listesi → counter sıfırlanır, sonraki iterasyona geç

Sen verify-fix orkestratörüsün. Aşağıdaki döngüyü 2 ardışık 0-bug iterasyon görene kadar tekrarla (en fazla 5 iterasyon):

1. `claude -p "/qa http://localhost:4321"` çağır.
2. Çıktıyı verify-fix-{i}.md olarak kaydet.
3. Çıktıda "Bug found:" satırı varsa → counter=0, devam et.
4. Yoksa → counter++; counter=2 ise "Clean. Loop done." yaz ve çık.
5. i++ ve adım 1'e dön.

Hard cap: 5 iterasyon (sonsuz döngüye karşı kemer).

Sonuç — şu noktada elinde ne var?

7 adımı tamamladıysan link-vault için elinde:

• ✅ docs/spec.md — ürün açıklaması, senaryolar, data model
• ✅ design/ — sayfa başına HTML/CSS prototip + token dosyası
• ✅ phases/phase-*.md — 5–8 fazlık plan
• ✅ GitHub repo + Project board (issue’lar Done kolonunda)
• ✅ 5+ merge edilmiş PR (her biri bir faz)
• ✅ bug-report.md (Adım 6) ve verify-fix-*.md log’ları (Adım 7)
• ✅ Çalışan bir uygulama: pnpm dev veya deploy edilmişse canlı URL

Workflow’un bağı: her parça öncekine yaslanır.

1. Brainstorm netliği belirler → 2. Claude Design UI sürprizlerini ayıklar → 3. Faz bölme context rot’tan korur → 4. GitHub Projects durumun tek kaynağı olur → 5. Build loop insan müdahalesini düşürür → 6. QA skill kör noktaları yakalar → 7. Verify-fix loop bug’ları otonom kapatır.

Bir sonraki adım

• Birinci pipeline’ı bitirdiysen ölç: kaç saat sürdü? Hangi adım en uzun? Hangi fazlarda Claude takıldı?
• 2. projeyi yaparken Adım 1-3’ü 30 dakikaya indirebilirsin (kalıbı tanıyorsun).
• Eric Tech’in playlist’inde her loop için derin dalış videoları var (linkler kaynak videoda).
• gstack’in /ship, /canary, /cso gibi henüz dokunmadığımız 15+ skill’i var — ürünü prod’a almak için Adım 7’den sonra devreye girer.

İleri linkler için yan paneldeki repo kartlarına bak.