beast-agent 1.7.0 → 1.8.0

package/src/agent/seeds/dispatching-parallel-agents/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: dispatching-parallel-agents
+description: Birbirinden bağımsız 2+ iş aynı anda yapılabilecekken kullan — farklı alt sistemlerdeki hatalar, farklı araştırmalar, farklı dosyalar; işler sıra gerektirmeden ve ortak durum paylaşmadan yürüyebiliyorsa.
+---
+
+# Paralel Ajan Devri
+
+## Genel Bakış
+
+İşleri, bağlamı İZOLE alt-ajanlara devredersin. Talimatlarını ve
+bağlamını hassas kurarak odaklarını ve başarısını garanti edersin. Onlar
+senin oturum bağlamını asla görmez — ihtiyaç duydukları her şeyi SEN
+inşa edersin. Bu, kendi bağlamını koordinasyon işine saklar.
+
+**Çekirdek ilke:** Bağımsız her problem alanı için bir ajan. Paralel koştur.
+
+## Ne Zaman
+
+**Kullan:**
+- Farklı kök nedenli 3+ test hatası
+- Birbirinden bağımsız kırılmış alt sistemler
+- Her sorun diğerinin bağlamı olmadan anlaşılabilir
+- Araştırmalar arasında ortak durum yok
+
+**Kullanma:**
+- Hatalar ilişkiliyse (biri düzelince diğerleri de düzelebilir) — birlikte incele
+- Tam sistem durumunu görmek gerekiyorsa
+- Ajanlar birbirine karışacaksa (aynı dosyaları düzenliyorlarsa)
+
+## Desen
+
+### 1. Bağımsız Alanları Belirle
+
+Sorunları neyin kırıldığına göre grupla:
+- test-a.test.js: onay akışı
+- test-b.test.js: batch tamamlama
+- test-c.test.js: iptal davranışı
+
+Her alan bağımsız — onay fix'i iptal testlerini etkilemez.
+
+### 2. Odaklı Ajan Görevleri Yaz
+
+Her ajana:
+- **Spesifik kapsam:** tek dosya/alt sistem
+- **Net hedef:** bu testler geçsin
+- **Kısıt:** başka koda dokunma
+- **Beklenen çıktı:** ne buldun + ne düzelttin özeti
+
+### 3. Paralel Devret
+
+Tüm devirleri AYNI cevapta ver — paralel koşarlar:
+
+```
+run_background: "tests/a.test.js'deki 3 hatayı düzelt ..."
+run_background: "tests/b.test.js'deki 2 hatayı düzelt ..."
+run_background: "tests/c.test.js hatasını düzelt ..."
+```
+
+Birden çok çağrı aynı turda = paralel. Tur başına bir çağrı = sıralı.
+Bağımsız adımlar için `run_background_many` TEK ÇAĞRIDA fan-out yapar ve
+bitince TEK birleşik rapor düşürür.
+
+### 4. İncele ve Entegre Et
+
+Ajanlar dönünce:
+- Her özeti oku
+- Fix'ler çakışıyor mu kontrol et (aynı kod düzenlenmiş mi?)
+- Tam test suite'ini çalıştır — hepsi birlikte çalışıyor mu doğrula
+- Ara sıra elle kontrol — ajanlar sistematik hata yapabilir
+
+## Ajan Görev Metni Yapısı
+
+İyi görev metinleri:
+1. **Odaklı** — tek net problem alanı
+2. **Kendine yeterli** — problemi anlamak için gereken TÜM bağlam
+   (dosya yolları, hata mesajları, test isimleri — ajan senin sohbetini göremez)
+3. **Çıktıya spesifik** — ajan ne döndürmeli?
+
+```markdown
+src/agents/abort.test.js'deki 3 hatayı düzelt:
+
+1. "partial output ile abort" — 'interrupted at' bekleniyor
+2. "mixed completed/aborted" — hızlı araç abort edilmedi
+3. "pendingToolCount" — 3 beklenirken 0
+
+Bunlar zamanlama/race sorunları. Görevin:
+1. Test dosyasını oku, her testin ne doğruladığını anla
+2. Kök nedeni bul — zamanlama mı, gerçek bug mı?
+3. Düzelt:
+   - Keyfi timeout'ları event-beklemeliyle değiştir
+   - Bulunan gerçek bug'ları düzelt
+   - Davranış değiştiyse test beklentisini güncelle
+
+SADECE timeout artırma — gerçek sorunu bul.
+
+Dönüş: ne bulduğun ve ne düzelttiğin özeti.
+```
+
+## Yaygın Hatalar
+
+**❌ Çok geniş:** "tüm testleri düzelt" — ajan kaybolur
+**✅ Spesifik:** "abort.test.js'yi düzelt" — odaklı kapsam
+
+**❌ Bağlamsız:** "race condition'ı düzelt" — ajan nerede bilmiyor
+**✅ Bağlamlı:** hata mesajlarını ve test isimlerini yapıştır
+
+**❌ Kısıtsız:** ajan her şeyi refactor edebilir
+**✅ Kısıtlı:** "sadece testleri düzelt, production koduna dokunma"
+
+**❌ Belirsiz çıktı:** "düzelt" — ne değiştiğini bilemezsin
+**✅ Spesifik:** "kök neden ve değişiklik özeti dön"
+
+## Doğrulama
+
+Ajanlar döndükten sonra:
+1. **Her özeti incele** — ne değiştiğini anla
+2. **Çakışma kontrolü** — ajanlar aynı kodu düzenledi mi?
+3. **Tam suite çalıştır** — tüm fix'ler birlikte çalışıyor mu
+4. **Rastgele kontrol** — ajan raporları iddiadır, kanıt değil
+   (verification-before-completion)

package/src/agent/seeds/executing-plans/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: executing-plans
+description: Yazılı bir implementasyon planı bu oturumda uygulanacakken kullan — paralel ajan devri yapılmadan, plan adımları elle yürütülecekse.
+---
+
+# Plan Yürütme
+
+## Genel Bakış
+
+Planı yükle, eleştirel incele, tüm görevleri uygula, bitince raporla.
+
+**Not:** CEO modu / paralel ajan mümkünse subagent-driven-development daha
+iyi sonuç verir — bu skill ajan devrinin olmadığı düz yürütme içindir.
+
+## Süreç
+
+### Adım 1: Planı Yükle ve İncele
+1. Plan dosyasını oku (ve varsa gösterdiği spec dosyasını)
+2. Eleştirel incele — plan hakkında soru/tereddüt var mı?
+3. Tereddüt varsa: BAŞLAMADAN kullanıcıya bildir
+4. Yoksa: todo_write ile plan görevlerini aç ve başla
+
+### Adım 2: Görevleri Uygula
+
+Her görev için:
+1. todo_write'ta in_progress yap
+2. Her adımı plan yazdığı gibi uygula (plan ısırık adımlar taşır — atlamak yok)
+3. Belirtilen doğrulamaları çalıştır (run_command — komut çıktısıyla)
+4. done yap, sıradakine geç
+
+### Adım 3: Bitiş
+
+Tüm görevler tamam ve doğrulandığında:
+- 1-3 satırlık özet rapor: ne yapıldı + doğrulama kanıtları (ör. "npm test ✓ 154/154")
+- verification-before-completion: "bitti" demeden önce taze kanıt şart
+
+## Ne Zaman Durup Sorulur
+
+Hemen dur:
+- Engel ile karşılaşırsan (eksik bağımlılık, test fail, belirsiz talimat)
+- Plan başlamayı engelleyen kritik boşluk içeriyorsa
+- Bir talimatı anlamıyorsan
+- Doğrulama tekrar tekrar fail ediyorsa
+
+**Tahmin etmek yerine sor.**
+
+## Ne Zaman Önceki Adıma Dönülür
+
+- Kullanıcı planı güncellerse → Adım 1'e dön
+- Temel yaklaşımın yeniden düşünülmesi gerekiyorsa → Adım 1'e dön
+
+Engellere zorla geçme — dur, sor.
+
+## Hatırla
+
+- Planı önce eleştirel incele
+- Plan adımlarını birebir takip et
+- Doğrulamaları atlama
+- Kendi başına plan değiştirme — plan hatalıysa kullanıcıya bildirip karar al
+- Hiçbir doğrulama "elle yaptım" ile geçmez

package/src/agent/seeds/subagent-driven-development/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: subagent-driven-development
+description: Bağımsız görevlere bölünmüş bir implementasyon planı yürütülürken, görev başına taze paralel ajan devredilecekken kullan — CEO modunda planlı geliştirme işlerinde.
+---
+
+# Alt-Ajan Destekli Geliştirme
+
+Planı, görev başına TAZE implementer alt-ajanı devrederek yürüt; her
+görevden sonra görev incelemesi (spec uyumu + kalite), sonda tüm işin
+genel incelemesi.
+
+**Neden alt-ajan:** Bağlamı izole, uzman ajanlara devredersin. Onlar senin
+oturum bağlamını asla görmez — ihtiyaçları olan her şeyi sen kurarsın. Bu
+senin bağlamını koordinasyona saklar ve her görevde taze, kiralanmamış
+bağlam garanti eder.
+
+**Çekirdek ilke:** Görev başına taze ajan + görev incelemesi + sonda geniş
+inceleme = yüksek kalite, hızlı iterasyon.
+
+**Kesintisiz yürütme:** Görevler arasında kullanıcıya "devam edeyim mi?"
+diye DURMA. Planı sorana kadar yürüt. Durmanın sadece 4 sebebi var:
+(1) geri döndürülemez/yıkıcı işlem, (2) güvenlik hassasiyetli işlem,
+(3) worktree dışına dokunan yan etki (merge, push, publish), (4) plan o
+kadar bozuk ki her yol tahmine dayanıyor.
+
+**Karar ver, bekleme:** Çelişki, belirsizlik, plan kusuru — sen karar ver.
+Spec bağlayıcı otoritedir, plan onun savunmasıdır. Her kararı defterine
+`Karar: <neyi> — <neden> — <yanlışsa maliyeti>` olarak yaz ve devam et.
+
+## Ne Zaman
+
+- Implementasyon planı var mı? → yoksa önce writing-plans
+- Görevler çoğunlukla bağımsız mı? → sıkı bağlıysa satır içi (executing-plans)
+- CEO modu / paralel ajan mümkün mü? → evetse bu skill
+
+## Kurulum
+
+1. Planı BİR KEZ oku (ve varsa spec'i — çelişkiler spec'e göre çözülür)
+2. todo_write ile her göreve bir madde aç
+3. Defteri kur: `<workspace>/.sdd/<plan-adı>-progress.md` — ilk satır
+   `# SDD defteri — plan: <plan dosyası>` olsun. Bağlam sıkışırsa/kaybolursa
+   defter VE git log senin hafızandan güvenilirdir; tamamlanan görevleri
+   yeniden devretme.
+4. Görev 1'den önce hızlı çelişki taraması: birbiriyle çelişen görevler,
+   görevlerin tanımladığı arayüzler tutarlı mı? Bulgu varsa kararını deftere yaz.
+
+## Model Seçimi (agent: parametresi)
+
+Her devirde en az güçlü yeterli modeli kullan — run_background'da
+`agent:` ile tanımlı ajan ver (%APPDATA%\beast\agents\*.md) ya da görevde
+model beklentisini belirt:
+
+- **Mekanik iş** (izole fonksiyon, net spec, 1-2 dosya, plan kodu tam içeriyor):
+  hızlı/ucuz model
+- **Entegrasyon/tyargı işi** (çok dosya, pattern eşleme, debug): standart model
+- **Mimari/tasarım işi + FİNAL inceleme:** en güçlü model — final review
+  asla oturum varsayılanına düşük kalmamalı
+- **Fix turları 4-5:** takılan implementer'dan bir tier güçlü model
+
+## Görev Döngüsü
+
+**Küçük aynı-kalıp işleri TOPLA:** plan birkaç küçük bağımsız aynı-tip edit
+listeliyorsa görev başına ajan AÇMA — tek brief'te tüm dosyaları listele,
+tek ajana ver, diff'ini tek unit olarak incele.
+
+### 1. Implementeri devret
+
+- **Görev brief'i:** görev metnini brief dosyasına yaz
+  (`<workspace>/.sdd/gorev-N-brief.md`) — tam değerler, kod, testler brief'te.
+  Devir metni şunu içersin: (1) görevin projedeki yeri tek cümle; (2) brief
+  dosyasının yolu ("önce bunu oku — gereksinimlerin burada, değerleri birebir
+  kullan"); (3) brief'in bilemeyeceği önceki görevlerin arayüz kararları;
+  (4) belirsizliklerin çözümü; (5) rapor dosyası yolu
+  (`gorev-N-rapor.md`).
+- **Kritik kuralları GÖM:** alt-ajanlar skill OKUMAZ (skills taraması
+  arka-ajanlara girmez) — TDD/verification gibi şartları görev metnine tek
+  cümleyle göm: "Testten önce kod yok: RED→fail gör→GREEN→pass gör.
+  Bitti demeden önce test çıktısıyla kanıtla."
+- **Alt-ajan alt-ajan AÇAMAZ** — bu normaldir: implementer inceleme de
+  devredemez; inceleme senden gelir.
+- Aynı anda birden çok implementasyon ajanı devretme (çakışır) —
+  BAĞIMSIZ görevler run_background_many ile fan-out edilebilir.
+- Report contract: ajan kısa döner — status + commit + tek satır test özeti +
+  endişeler; detay rapor dosyasına yazar (senin bağlamını şişirmez).
+
+### 2. Raporu ele
+
+- **DONE:** inceleme paketini hazırla, task reviewer devret (adım 3)
+- **DONE_WITH_CONCERNS:** endişeleri oku; doğruluk/kapsam ise review'dan
+  ÖNCE ele al; gözlemse not al ve geç
+- **NEEDS_CONTEXT:** eksik bağlamı ver, yeniden devret
+- **BLOCKED:** bağlam sorunuysa bağlamla; akıl sorunuysa güçlü modelle;
+  iş büyükse böl; plan hatalıysa karar ver + deftere yaz + düzeltilmiş devir
+
+Ajan takıldı dediysen aynı modelle aynı şartlarda TEKRAR deneme — bir şey
+değişmeli.
+
+### 3. Görevi incele
+
+- **Task reviewer devret** (taze ajan): girdiler = brief dosyası + rapor
+  dosyası + diff dosyası. Diff'i kendin ÖZETLEME — `git diff BASE..HEAD` çıktısını
+  bir dosyaya yaz (BASE = devirden önceki commit) ve yolunu ver; reviewer tek
+  okumada commit listesi + stat + tam diff görür, senin bağlamına diff girmez.
+- Reviewer'a planın Global Kısıtlarını BİREBİR kopyala — bu onun dikkat
+  merceğidir. Açık uçlu talimat ("tüm kullanımları kontrol et") EKLEME.
+- Reviewer'a bulguyu ÖNCEDELEN yargılama — "şunu bayraklama" deme; bulgunu
+  çıkarsın, inceleme döngüsünde sen kararlaştırırsın.
+- İki karar gereklidir: spec uyumu ✓ VE kalite onayı. Ajanın öz-incelemesi
+  task incelemesinin YERİNİ TUTMAZ.
+- Reviewer "diff'ten doğrulanamıyor" işareti koyabilir — bunları kendin çöz:
+  plan + görevler-arası bağlam sende.
+
+### 4. Fix döngüsü
+
+Review spec ❌ veya Critical/Important bulgu bildirirse döngü başlar.
+Minor bulgular döngüye girmez — deftere `Task N: minor (ertelendi): <tek satır>` yaz.
+
+Tur başına: bir fix devri + bir scoped re-review. Görev başına MAK 5 tur:
+
+- **Tur 1-3 — aynı implementer'a devam:** açık bulguları birebir gönder;
+  bağlamı duruyor. Aynı ajana mesaj atılamıyorsa taze implementer'a brief +
+  rapor + bulguları ver — rapor dosyası kalıcı hafızadır.
+- **Tur 4-5 — taze implementer + güçlü model:** "Önceki implementer N kez
+  denedi; artık sen sahibin. Deneneni rapordan oku."
+- Her turda: implementer kapsayan testleri yeniden çalıştırır, fix raporunu
+  AYNI rapor dosyasına ekler. Re-review scoped: SADECE fix diff'inde bulgular
+  ADDRESSED/NOT ADDRESSED + yeni kırılma var mı.
+- Defteri her turda güncelle: `Task N: fix turu R/5 (X giderildi, Y açık)`.
+
+**Kendin fix YAPMA** — bağlamın koordinasyon için temiz kalmalı ve senin
+fix'in review'sız kalır.
+
+**Sigorta (5. turda da açık bulgu):** devretmeyi durdur, her bulguyu kendin
+kararla:
+- Reviewer yanılıyorsa → park et: `Task N: park — <bulgu> — Karar: <kod neden duruyor>`
+- Gerçek ama kimseye binmiyorsa → ertelendi olarak park et
+- Gerçek ve yük taşıyorsa → en küçük açıcı değişikliğe karar ver, deftere yaz,
+  sonraki görevin devrine taşı
+
+### 5. Görevi tamamla
+
+Review temiz gelince (veya bulgular park edildiğinde): deftere
+`Task N: complete (commits <base>..<head>, review clean)` yaz, todo done yap,
+sıradaki görev.
+
+## Final Review
+
+Tüm görevler bitince TÜM işin incelemesini devret — en güçlü modelle:
+`git diff <plan-başlangıç>..HEAD` diff dosyası + defterdeki ertelenen minor/
+park satırlarıyla (hangi merge'i bloklar triage etsin). Bulgu dönerse TEK fix
+ajanı devret (bulgu başına ayrı ajan değil) + TEK scoped re-review.
+
+Bitirince defterdeki tüm `Karar:` satırlarını final mesajında kullanıcıya
+listele — senin onun adına aldığın kararlar buraya kadar görünür olur.
+
+## Yaygın Bahaneler
+
+| Bahane | Gerçek |
+|---|---|
+| "Spec uyumu kabaca tamam" | Reviewer spec boşluğu buldu = bitmedi. Fix veya cap+karar — başka çıkış yok. |
+| "Kendim fixleyeyim, devir maliyetli" | Senin fix'in review'sız kalır ve bağlamını kirletir. Implementer'a devam ettir. |
+| "Bir tur daha yakınsar" | Cap sonrası turlar yakınsamaz — sorun yapısal. Kararlaştır. |
+| "Reviewer zaten yeni bulgu çıkaracak" | Scoped re-review sadece fix'i doğrular; yeni bulgu deftere gider, döngüye değil. |
+| "Bu bulgu bariz yanlış, düşüreyim" | Karar SADECE cap'te ve her karar deftere. Sessiz düşürme yasak. |
+| "Fix küçük, re-review'sız geç" | Review'sız fix = regresyon kapısı. Her tur re-review ile biter. |
+| "İnceleme döngüyü yavaşlatıyor" | Reviewsuz döngü doğrulanmamış efor. İnceleme fren ve direksiyondur. |
+| "Defter yazımı maliyetli" | Defter bağlam sıkışmasından kurtulan tek şeydir. |

package/src/agent/seeds/systematic-debugging/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: systematic-debugging
+description: Herhangi bir bug, test hatası, beklenmedik davranış, build/entegrasyon sorunuyla karşılaştığında — ÇÖZÜM ÖNERMEDEN ÖNCE kullan; kök neden araştırması yapılmadan düzeltme denemesi yasak.
+---
+
+# Sistematik Hata Ayıklama
+
+## Çekirdek ilke
+
+**Her zaman kök nedeni bul, sonra düzelt. Belirtiye yama = başarısızlık.**
+
+**Bu sürecin harfini ihlal etmek, ruhunu ihlal etmektir.**
+
+## Demir Kanun
+
+```
+KÖK NEDEN ARAŞTIRMASI OLMADAN DÜZELTME YOK
+```
+
+Faz 1 tamamlanmadıysa çözüm öneremezsin.
+
+## Ne Zaman
+
+Her teknik sorun: test hataları, prod bug'ları, beklenmedik davranış,
+performans sorunları, build/entegrasyon hataları.
+
+ÖZELLİKLE şunlarda kullan:
+- Zaman baskısı varken (acele tahmini cezbeder)
+- "Hızlı bir tek düzeltme" çok bariz görünüyorken
+- Birden fazla düzeltme denedin ve olmadıysa
+
+Basit görünen sorunlarda da atlama — basit bug'ların da kök nedeni var.
+
+## Dört Faz
+
+Her fazı bitirmeden sonrakine geçemezsin.
+
+### Faz 1: Kök Neden Araştırması
+
+HİÇBİR düzeltmeden ÖNCE:
+
+1. **Hata mesajlarını DİKKATLE oku** — stack trace'i tamamen oku; satır
+   numarası, dosya yolu, hata kodu not al. Çözüm genelde mesajın içindedir.
+2. **Tutarlı şekilde yeniden üret** — güvenilir tetikleyebiliyor musun?
+   Adımlar neler, her seferinde oluyor mu? Üretilemiyorsa veri topla, TAHMİN ETME.
+3. **Son değişiklikleri kontrol et** — ne değişti? git diff, son commit'ler,
+   yeni bağımlılık/config değişikliği.
+4. **Çok bileşenli sistemlerde kanıt topla** — her bileşen sınırında ne
+   girdiğini/ne çıktığını logla; HANGİ katmanın kırdığını gösteren tek bir
+   kanıt çalıştırması yap, sonra o bileşeni incele.
+5. **Veri akışını izle** — bozuk değer nereden kaynaklanıyor? Kim bu değeri
+   gönderdi? Kaynağa kadar yukarı çıkar; kaynağında düzelt, belirtide değil.
+
+### Faz 2: Desen Analizi
+
+1. **Çalışan örnek bul** — aynı kod tabanında benzer ama ÇALIŞAN kod nerede?
+2. **Referansla karşılaştır** — bir desen uyguluyorsan referans implementasyonu
+   TAMAMEN oku (göz gezdirme yok).
+3. **Farkları listele** — çalışanla bozuk arasındaki her farkı, ne kadar küçük
+   olursa olsun yaz. "Bu fark önemli olamaz" deme.
+4. **Bağımlılıkları anla** — hangi bileşen/ayar/ortam varsayımlarına dayanıyor?
+
+### Faz 3: Hipotez ve Test
+
+Bilimsel yöntem:
+
+1. **Tek hipotez kur** — "X kök neden, çünkü Y" diye net yaz. Spesifik ol.
+2. **Minimal test et** — hipotezi test eden EN KÜÇÜK değişikliği yap. Tek
+   değişken. Birden fazla şeyi birden düzeltme.
+3. **Devam etmeden doğrula** — oldu mu → Faz 4. Olmadı mı → YENİ hipotez;
+   üstüne yama EKLEME.
+4. **Bilmiyorsan söyle** — "X'i anlamıyorum" de; araştır, yardım iste.
+
+### Faz 4: Uygulama
+
+1. **Başarısız test üret** — en basit yeniden üretim; test framework varsa
+   otomatik test, yoksa tek seferlik script (test-driven-development skill'i
+   ilerler). Düzeltmeden ÖNCE şart.
+2. **Tek düzeltme uygula** — belirlenen kök nedeni hedefle; "buradayken şu da"
+   iyileştirmesi YOK, paket refactoring YOK.
+3. **Düzeltmeyi doğrula** — test geçti mi? Başka testler kırıldı mı? Sorun
+   gerçekten çözüldü mü? Başarı iddiasından önce verification-before-completion.
+4. **Düzeltme işe yaramadıysa:** DUR. Kaç düzeltme denedin say. 3'ten azsa →
+   Faz 1'e dön, yeni bilgiyle yeniden analiz et. 3 ve üzeriyse → mimariyi
+   sorgula (aşağıda).
+
+### 3+ Düzeltme Başarısızsa: Mimaride Hata Var
+
+Desen: her düzeltme başka yerde yeni sorun çıkarıyor; düzeltmeler "büyük
+refactoring" istiyor; her fix yeni belirti üretiyor.
+
+DUR ve temel soruları sor: Bu desen sağlam mı? Devam etmek atalet mi?
+Mimariyi refactor etmek mi, belirti düzeltmeye devam etmek mi? Kullanıcıya
+danışmadan 4. düzeltmeyi deneme. Bu başarısız hipotez değil — yanlış mimaridir.
+
+## Kırmızı Bayraklar — DUR ve Sürece Dön
+
+Kendini şöyle düşünürken yakalarsan:
+
+- "Şimdilik hızlı bir fix, sonra bakarız"
+- "X'i değiştirip bakalım" (araştırma olmadan)
+- "Birden fazla değişiklik yapayım, testleri çalıştırırım"
+- "Testi atlayayım, elle doğrularım"
+- "Muhtemelen X'tir, onu düzelteyim"
+- "Tam anlamıyorum ama bu işe yarayabilir"
+- Veri akışını izlemeden çözüm listesi sunmak
+- 2+ başarısız denemeden sonra "bir fix daha"
+- Her fix başka yerde yeni sorun açıyor
+
+**Hepsi aynı anlama gelir: DUR. Faz 1'e dön.**
+
+## Yaygın Bahaneler
+
+| Bahane | Gerçek |
+|---|---|
+| "Sorun basit, sürece gerek yok" | Basit sorunların da kök nedeni var; süreç basitte hızlıdır. |
+| "Acil, süreç için vakit yok" | Sistematik hata ayıklama, tahmin-check döngüsünden HIZLIDIR. |
+| "Önce şunu deneyeyim, sonra araştırırım" | İlk fix deseni belirler; baştan doğru yap. |
+| "Testi fix işe yaradıktan sonra yazarım" | Testsiz fix kalıcı değildir; test önce kanıtlar. |
+| "Birden çok fixi birden yapsam zaman kazanırım" | Neyin işe yaradığını izole edemezsin; yeni bug üretir. |
+| "Referans çok uzun, uyarlarım" | Kısmi anlayış bug garantidir. Tamamını oku. |
+| "Sorunu görüyorum, düzelteyim" | Belirti görmek ≠ kök nedeni anlamak. |
+
+## Hızlı Referans
+
+| Faz | Anahtar işler | Başarı kriteri |
+|---|---|---|
+| 1. Kök neden | Hata oku, üret, değişiklikleri kontrol et, kanıt topla | NE ve NEDEN'i anladın |
+| 2. Desen | Çalışan örnek bul, karşılaştır | Farkları belirledin |
+| 3. Hipotez | Teori kur, minimal test et | Doğrulandı veya yeni hipotez |
+| 4. Uygulama | Test üret, tek fix, doğrula | Bug çözüldü, testler geçti |

package/src/agent/seeds/test-driven-development/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: test-driven-development
+description: Herhangi bir özellik veya bug fix uygulanırken, implementasyon kodu yazılmadan ÖNCE kullan — yeni özellik, davranış değişikliği, refactoring işlerinde test-önce disiplini zorunludur.
+---
+
+# Test-Driven Development (TDD)
+
+## Genel Bakış
+
+Önce testi yaz. Başarısız olduğunu İZLE. Geçecek minimal kodu yaz.
+
+**Çekirdek ilke:** Testin başarısız olduğunu izlemediysen, doğru şeyi
+test ettiğini bilmezsin.
+
+**Kuralın harfini ihlal etmek, ruhunu ihlal etmektir.**
+
+## Demir Kanun
+
+```
+BAŞARISIZ TEST OLMADAN PRODUCTION KODU YOK
+```
+
+Testten önce kod yazdıysan: SİL. Baştan başla.
+
+**İstisna yok:**
+- "Referans olarak tutma"
+- Testleri yazarken "uyarlama"
+- Bakma bile
+- Silmek silmektir. Testten taze implemente et.
+
+## Ne Zaman
+
+**Her zaman:** yeni özellik, bug fix, refactoring, davranış değişikliği.
+
+**İstisnalar (kullanıcıya sorarak):** atılacak prototipler, üretilmiş kod,
+config dosyaları.
+
+"Bu seferlik TDD'yi atlayayım" düşüncesi = bahane. DUR.
+
+## RED-GREEN-REFACTOR
+
+### RED — Başarısız Test Yaz
+
+Bir minimal test yaz: ne OLMASI gerektiğini gösterir.
+
+**Gereksinimler:**
+- Tek davranış
+- Açık isim (`retry 3 kereden sonra vazgeçer`, "retry works" değil)
+- Gerçek kod (kaçınılmaz değilse mock yok)
+
+### RED'i Doğrula — Başarısızlığını İZLE
+
+**ZORUNLU. Asla atlama.**
+
+```
+run_command: node --test tests/ornek.test.js
+```
+
+Doğrula:
+- Test FAIL ediyor (error değil)
+- Hata mesajı beklenen
+- Eksik özellik yüzünden fail ediyor (typo değil)
+
+**Test hemen geçti?** Mevcut davranışı test ediyorsun. Testi düzelt.
+
+**Test error verdi?** Hatayı düzelt, doğru şekilde fail edene kadar tekrar.
+
+### GREEN — Minimal Kod
+
+Testi geçecek EN BASİT kodu yaz. Fazla özellik, gereksiz opsiyon,
+"şimdiyken ekleyiver" YOK (YAGNI).
+
+### GREEN'i Doğrula — Geçişini İZLE
+
+**ZORUNLU.** Aynı komutu çalıştır:
+- Test geçiyor
+- Diğer testler hâlâ geçiyor
+- Çıktı temiz (hata/uyarı yok)
+
+**Test fail?** Testi değil KODU düzelt.
+**Başka testler fail?** Şimdi düzelt.
+
+### REFACTOR — Temizle
+
+Sadece yeşilken: tekrar eden kodu kaldır, isimleri iyileştir, helper çıkar.
+Testleri yeşil tut. Davranış EKLEME. Sonra sonraki failing test ile tekrarla.
+
+## İyi Test
+
+| Nitelik | İyi | Kötü |
+|---|---|---|
+| Minimal | Tek şey. İsmi "ve" içeriyorsa böl. | `email ve domain ve boşluğu doğrular` |
+| Açık | İsim davranışı tarif eder | `test1` |
+| Niyet gösterir | İstenen API'yi sergiler | Kodun ne yapacağını gizler |
+
+- Gerçek davranışa assert et, mock davranışına asla
+- Test yazmadan önce: bu testi FAIL eden production değişikliğini adlandırabilmeliyim
+
+## Yaygın Bahaneler
+
+| Bahane | Gerçek |
+|---|---|
+| "Test etmek için çok basit" | Basit kod da kırılır. Test 30 saniye. |
+| "Sonra yazarım" | Sonradan yazılan test hemen geçer — bu bir şey KANITLAMAZ. Yanlış şeyi test edebilir, hatırladığın kenar durumları kapsar, unuttuğunları kaçırır. |
+| "Testler sonra da aynı hedefe ulaşır" | Test-sonra "bu ne yapıyor?"u cevaplar; test-önce "bu ne YAPMALI?"ı cevaplar. Kod zaten yazılmışken test ondan biaslanır. |
+| "Elle test ettim zaten" | Elle test kayıpsız tekrarlanamaz, kenar durumları kanıtlamaz. |
+| "X saat kaybolacak, silmesem iyi olur" | Batık maliyet yanılgısı. Güvenemediğin kodu tutmak asıl kayıp. |
+| "Keşif gerek önce" | Tamam — keşfi at, TDD ile baştan başla. |
+| "Test yazması zor = tasarım kötü" | Teste dinle. Test etmek zor = kullanmak zor. |
+| "TDD yavaşlatır" | TDD pragmatik yoldur: commit öncesi yakalar, regresyonu önler, korkusuz refactor sağlar. "Pragmatik" kısayol = prod'da debug. |
+
+## Kırmızı Bayraklar — DUR, Baştan Başla
+
+- Testten önce kod
+- Implementasyondan sonra test
+- Test anında geçti
+- Testin neden fail ettiğini açıklayamıyorsun
+- "Sonraya" eklenen testler
+- "Sadece bu sefer" bahanesi
+- "Elle test ettim zaten"
+- "Ruha uygun, ritüele değil"
+- "Referans olarak tutarım"
+- "X saat boşa gideydi"
+
+**Hepsi aynı anlama gelir: Kodu sil. TDD ile baştan başla.**
+
+## Doğrulama Listesi
+
+İşi tamamlanmış saymadan önce:
+
+- [ ] Her yeni fonksiyonun testi var
+- [ ] Her testi implementasyondan ÖNCE fail izledim
+- [ ] Her test beklenen sebeple fail etti
+- [ ] Her test için minimal kod yazdım
+- [ ] Tüm testler geçiyor, çıktı temiz
+- [ ] Kenar durumları ve hatalar kapsamlı
+
+Tüm kutular dolmuyorsa TDD'yi atladın. Baştan başla.
+
+## Takıldığında
+
+| Sorun | Çözüm |
+|---|---|
+| Nasıl test edeceğimi bilmiyorum | İstediğin API'yi yaz, assertion'la başla, kullanıcıya sor |
+| Test çok karmaşık | Tasarım karmaşık demektir. Arayüzü sadeleştir. |
+| Her şeyi mock'lamam gerek | Kod fazla coupled. Bağımlılık enjeksiyonu kullan. |
+| Test kurulumu devasa | Helper çıkar. Hâlâ karmaşıksa tasarımı sadeleştir. |
+
+## Bug Bulunduğunda
+
+Bug'ı yeniden üreten FAILING test yaz → TDD döngüsü → test hem fix'i
+kanıtlar hem regresyonu önler. Testsiz bug fixi ASLA yapma.