beast-agent 1.7.0 → 1.9.0

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.

package/src/agent/seeds/verification-before-completion/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: verification-before-completion
+description: İşin bitti/düştü/geçti diye bildirmeden ÖNCE kullan — herhangi bir tamamlama iddiasından hemen önce; komutu çalıştırıp çıktısıyla kanıtlamadan başarı beyanı yasak.
+---
+
+# Tamamlamadan Önce Doğrulama
+
+## Çekirdek ilke
+
+**Kanıt önce gelir, iddia sonra. Her zaman.**
+
+**Kuralın harfini ihlal etmek, kuralın ruhunu ihlal etmektir.**
+
+## Demir Kanun
+
+```
+TAZE DOĞRULAMA KANITI OLMADAN TAMAMLAMA İDDİASI YOK
+```
+
+Bu tur içinde doğrulama komutunu çalıştırmadıysan, geçtiğini söyleyemezsin.
+
+## Kapı Fonksiyonu
+
+Herhangi bir durum beyan etmeden / memnuniyet göstermeden ÖNCE:
+
+1. **BELİRLE:** Bu iddiayı kanıtlayan komut nedir?
+2. **ÇALIŞTIR:** Komutu TAM ve TAZE çalıştır (run_command) — önceki turun çıktısı geçersiz
+3. **OKU:** Çıktının tamamını oku, exit code'a bak, hata sayısını say
+4. **DOĞRULA:** Çıktı iddiayı destekliyor mu?
+   - Hayır → gerçek durumu kanıtıyla bildir
+   - Evet → iddiayı KANITLA birlikte bildir
+5. **ANCAK O ZAMAN:** iddiada bulun
+
+Bir adımı atlarsan doğrulamış değilsin, yalan söylüyorsundur.
+
+## Yaygın İddia → Gerekli Kanıt
+
+| İddia | Gerekli kanıt | Yetmez |
+|---|---|---|
+| Testler geçti | Test çıktısı: 0 failure | Önceki tur, "geçer herhalde" |
+| Linter temiz | Linter çıktısı: 0 hata | Kısmi kontrol, çıkarım |
+| Build başarılı | run_command: exit 0 | Linter geçti, loglar iyi görünüyor |
+| Bug düzeltildi | Orijinal belirtinin testi: geçti | Kod değişti, düzeldi varsayımı |
+| Ajan işi bitirdi | diff / tasks_list raporu eşleşiyor | Ajan "başarılı" dedi |
+| Gereksinimler karşılandı | Madde madde kontrol listesi | Testler geçti |
+
+## Kırmızı Bayraklar — DUR
+
+- "Zaten çalıştırdım" (bu turda DEĞİLSE sayılmaz)
+- "Geçmesi lazım", "kesin çalışır"
+- Kodu değiştirip testi TEKRAR çalıştırmadan "düzeldi" demek
+- Kısmi çıktıyla ("testlerin çoğu geçti") tamamlama iddiası
+- Ajanın kendi "başarılı" raporunu doğrulamadan kullanıcıya aktarmak
+- Çıktıyı okumadan exit code'a güvenmek
+
+**Hepsi aynı anlama gelir: komutu çalıştır, çıktıyı oku, öyle bildir.**
+
+## Paralel Ajan Notu
+
+run_background ile devrettiğin işin raporu geldiğinde bu skill ÇİFT GEÇERLİ:
+ajanın raporu bir iddiadır, kanıt değil. İddia görevle eşleşiyor mu?
+Dosyalar gerçekten oluşmuş mu (list_dir/glob), komut gerçekten geçmiş mi
+(task_status çıktısı)? Doğrulamadan kullanıcıya "bitti" deme.

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

@@ -0,0 +1,162 @@
+---
+name: writing-plans
+description: Çok adımlı bir iş için spec/gereksinim hazır olduğunda, KODA DOKUNMADAN ÖNCE kullan — implementasyon planı yazılacak her durumda.
+---
+
+# Plan Yazma
+
+## Genel Bakış
+
+Sıfır bağlama sahip, zevki şüpheli bir mühendisin takip edebileceği kapsamlı
+implementasyon planı yaz. Her görevin hangi dosyalara dokunacağını, kodu,
+testi, nasıl test edileceğini belgele. Planı ısırık büyüklüğünde adımlara böl.
+DRY. YAGNI. TDD. Sık commit.
+
+Yetenekli ama arac setini ve problem alanını neredeyse hiç bilmeyen biri
+olduğunu varsay. Plan o kişinin eline tek başına geçmeli.
+
+**Planları buraya kaydet:** `<workspace>/docs/plans/YYYY-MM-DD-<özellik-adı>.md`
+(write_file ile; klasör yoksa oluşur)
+
+## Kapsam Kontrolü
+
+Spec birden fazla bağımsız alt sistemi kapsıyorsa ayrı planlara böl — her biri
+tek başına çalışan, test edilebilir yazılım üretmeli.
+
+## Dosya Yapısı
+
+Görevleri tanımlamadan önce hangi dosyaların oluşacağı/değişeceğinin ve
+her birinin sorumluluğunun haritasını çıkar. Kararlar burada kilitlenir:
+
+- Net sınırlı, tek sorumlu dosyalar; birlikte değişenler yan yana
+- Küçük odaklı dosyalar tercih et — bağlamında tutabildiğin ve edit'inin
+  güvenilir olduğu yapı budur
+- Mevcut kod tabanında yerleşik deseni takip et; tek taraflı yeniden yapılandırma
+
+## Görev Ölçüsü
+
+Görev = kendi test döngüsünü taşıyan, bağımsız doğrulanabilir en küçük birim.
+Kurulum/scaffolding adımlarını, çıktısı onlara ihtiyaç duyan görevin içine kat.
+İki görevi ayır: birinci reddedilirken ikincisi onaylanabilir mi?
+
+## Isırık Büyüklüğünde Adımlar
+
+Her adım TEK eylem (2-5 dakika):
+
+- "Başarısız testi yaz" — adım
+- "Çalıştır, fail olduğunu gör" — adım
+- "Testi geçecek minimal kodu yaz" — adım
+- "Testleri çalıştır, geçtiğini gör" — adım
+- "Commit" — adım
+
+## Plan Dosyası Başlığı
+
+**Her plan bu başlıkla başlamalı:**
+
+```markdown
+# [Özellik Adı] Implementasyon Planı
+
+> **Ajan işçiler için:** GÖREV BAŞINA taze alt-ajan: subagent-driven-development
+> (önerilen, CEO modunda) veya executing-plans kullan. Adımlar checkbox (- [ ])
+> sözdizimiyle takip edilir.
+
+**Hedef:** [Bu planın ürettiği şey — tek cümle]
+
+**Mimari:** [Yaklaşım — 2-3 cümle]
+
+**Teknoloji:** [Önemli teknoloji/kütüphaneler]
+
+**Spec:** [Varsa spec/design dosyasının yolu — plan spec'ten hareket eder]
+
+## Global Kısıtlar
+
+[Proje geneli şartlar — sürüm sınırları, bağımlılık sınırları, isim kuralları,
+platform şartları — spec'ten BİREBİR kopyalanmış değerlerle, her biri tek satır.
+Her görev bu bölümü örtük olarak içerir.]
+
+---
+```
+
+## Görev Yapısı
+
+````markdown
+### Görev N: [Bileşen Adı]
+
+**Dosyalar:**
+- Oluştur: `tam/yol/dosya.js`
+- Değiştir: `tam/yol/mevcut.js:123-145`
+- Test: `tests/tam/yol/dosya.test.js`
+
+**Arayüzler:**
+- Tüketir: [önceki görevlerden kullandığı — tam imzalar]
+- Üretir: [sonraki görevlerin dayandığı — tam fonksiyon adları, parametre ve
+  dönüş tipleri. Bir görevin implementeri SADECE kendi görevini görür;
+  komşu görevlerin adlarını/tiplerini buradan öğrenir.]
+
+- [ ] **Adım 1: Başarısız testi yaz**
+
+```js
+test('boş e-postayı reddeder', () => {
+  expect(submitForm({ email: '' }).error).toBe('Email gerekli');
+});
+```
+
+- [ ] **Adım 2: Fail olduğunu doğrula**
+
+Çalıştır: `node --test tests/dosya.test.js`
+Beklenen: FAIL — "submitForm is not defined"
+
+- [ ] **Adım 3: Minimal implementasyon**
+
+```js
+function submitForm(data) {
+  if (!data.email?.trim()) return { error: 'Email gerekli' };
+}
+```
+
+- [ ] **Adım 4: Geçtiğini doğrula**
+
+Çalıştır: `node --test tests/dosya.test.js`
+Beklenen: PASS
+
+- [ ] **Adım 5: Commit**
+
+```bash
+git add tests/dosya.test.js src/dosya.js
+git commit -m "feat: boş e-postayı reddet"
+```
+````
+
+## Placeholder YASAK
+
+Her adım mühendisin ihtiyacı olan GERÇEK içeriği taşır. Bunlar **plan
+hatasıdır** — asla yazma:
+
+- "TBD", "TODO", "sonra doldur", "detayları tamamla"
+- "Uygun hata yönetimi ekle" / "kenar durumları handle et"
+- "Yukarıdakine test yaz" (test kodu olmadan)
+- "Görev N'ye benzer" (kodun kendisini yaz — mühendis görevleri sırasız okuyabilir)
+- Ne yapılacağını söyleyip nasılını göstermeyen adımlar (kod adımı = kod bloğu)
+- Hiçbir görevde tanımlanmamış tip/fonksiyon referansı
+
+## Öz-Denetim
+
+Planı bitirince spec'i taze gözle kontrol et (kendi checklist'in):
+
+1. **Spec kapsamı:** Spec'in her bölümü için hangi görev implemente ediyor?
+   Boşlukları listele, görev ekle.
+2. **Placeholder taraması:** Yukarıdaki kırmızı desenleri kendi planında ara, düzelt.
+3. **Tip tutarlılığı:** Görev 3'te `clearLayers()` diye çağırdığın şey Görev 7'de
+   `clearFullLayers()` olmasın. İmzalar birebir eşleşmeli.
+
+Sorun bulursan yerinde düzelt, tekrar tekrar dolaşma.
+
+## Teslim
+
+Plan kaydedildikten sonra yürütme seçeneği sun:
+
+**"Plan `<yol>`'e kaydedildi. İki seçenek:**
+**1. Alt-Ajan Destekli (önerilen)** — her görev için taze paralel ajan
+(run_background), görevler arası inceleme; CEO modunda birebir
+**2. Satır İçi** — bu oturumda executing-plans ile, checkpoint'li seri yürütme
+**Hangisi?"**