beast-agent 1.9.0 → 2.0.0

package/src/agent/seeds/brainstorming/SKILL.md

@@ -1,90 +1,90 @@
----
-name: brainstorming
-description: Yaratıcı işe KOD YAZMADAN ÖNCE kullan — yeni özellik, yeni proje, bileşen, davranış değişikliği istendiğinde; niyeti, gereksinimleri ve tasarımı kullanıcıyla netleştirmeden implementasyona geçmek yasaktır.
----
-
-# Brainstorming: Fikirden Tasarıma
-
-Fikirleri doğal diyalogla tam oluşmuş tasarımlara dönüştür.
-
-Akış: bağlamı anla → fikri netleştir → tasarımı sun → kullanıcı onayı.
-
-<ZOR KAPI>
-Kullanıcıya ne yapacağını söyleyip onayı almadan HİÇBİR implementasyon
-eylemi yok: kod yazma, proje scaffold'ı, dosya üretme. Bu kapı HER görev
-için geçerlidir; törenin boyutu göreve göre ölçeklenir ama ONAY KAPISI
-ölçeklenmez.
-</ZOR KAPI>
-
-## Üç Yol
-
-İlk sorudan önce isteği SINIFLANDIR ve sınıfı sesli söyle — "bu sınırlı
-kapsamlı görünüyor, spec dosyası yazmak yerine kısa tasarımı burada sunacağım"
-— kullanıcı override edebilsin:
-
-- **Spike** — fizibilite sorusu ("yapılabilir mi", "hızlı-çirkin olsun").
-  Çıktısı tuttuğun kod değil, bir CEVAPTIR. Soru ve deneme planını 2-3
-  cümleyle sun, onay al, en ucuz yolla araştır. Tasarım dosyası yok.
-  Bulgu → öneri olarak raporla; bir şey inşa ettiysen "atılabilir" etiketiyle.
-- **Sınırlı (Bounded)** — mevcut koda iyi tanımlı değişiklik: yeni flag,
-  küçük endpoint, tek dosyalık fix. "Sınırlı" için DEĞİŞTİRECEĞİN AKIŞIN
-  Bu projede zaten var olması şart. Önemli netleştirme sorularını sor,
-  KISA tasarımı SOHBETTE sun (birkaç cümle - paragraf) ve DUR. Kullanıcı
-  "evet" demeden implementasyon yok. Spec dosyası yok, plan dosyası yok.
-- **Mimari** — yeni projeler, yeni alt sistemler, bileşen ilişkilerini
-  değiştiren işler. Tam süreç: sorular → 2-3 yaklaşım → bölümlü tasarım →
-  yazılı spec → writing-plans skill'i.
-
-İki yol arasında tereddüt varsa AĞIRINI seç. Ortasında gizli karmaşıklık
-çıkarsa yol YÜKSELTİLİR (dur, söyle, büyüt); asla aşağı inmez.
-
-## Anti-Desen: "Onaya Gerek Yok Kadar Basit"
-
-Her yol onayla biter. Todo listesi, tek fonksiyon, config değişikliği —
-tasarım sohbette iki cümle olabilir ama SUN ve ONAY AL. "Basit" işler,
-incelenmemiş varsayımların en çok iş boşa çıkardığı yerdir. Basitlikle
-ölçeklenen şey artefaktır; onay asla değil.
-
-## Kırmızı Bayraklar
-
-| Düşünce | Gerçek |
-|---|---|
-| "Bu, tasarım gerektirmeyecek kadar basit" | Basitlik kısa tasarım demektir, tasarım yok demek değil. |
-| "Sınırlı der spec'i atlarım" | Etiket arayışı şüphenin ta kendisi — ağır yolu seç. |
-| "Tasarım bariz, onu okurken başlarım" | Kapı onaydır, tasarımın uzunluğu değil. Sun ve evet bekle. |
-| "Bu tür app'leri biliyorum, sınırlıdır" | Sınırlı olma projeyi ölçer, bilgini değil. Akış yoksa mimaridir. |
-| "Spike çalıştı, kodu tutayım" | Spike'ın çıktısı cevaptır. Kodu tutmak YENİ istektir — sınıflandır. |
-| "Büyüdü ama az kaldı, yeniden sınıflandırmaya gerek yok" | Gizli karmaşıklık yolu ortada yükseltir. Dur ve söyle. |
-
-## Kontrol Listesi
-
-**Spike:** bağlamı gör → soru+plan sun (2-3 cümle) → onay → en ucuz yolla araştır → öneri raporla.
-
-**Sınırlı:** bağlamı gör (dosyalar, dokümanlar, son commit'ler) → netleştirme
-soruları TEK TEK → kısa tasarımı sohbette sun (yaklaşım, dokunulan dosyalar,
-test stratejisi) → açık "evet" bekle (sunup hemen başlamak = kapıyı atlamak) →
-normal iş akışıyla uygula (TDD geçerli).
-
-**Mimari:**
-1. Bağlamı gör: mevcut yapıyı list_dir/grep/read_file ile incele, deseni takip et
-2. Netleştirme soruları — TEK SORU PER MESAJ; amaç/kısıt/başarı kriterini anla;
-   çoklu seçmeli soru tercih et
-3. Kapsam çok buysa parçala: bağımsız alt-projelere böl, sırayı belirle,
-   ilk alt-projeyle normal akışa gir
-4. 2-3 yaklaşım öner — artı/eksileriyle; önerini BAŞA koy ve nedenini söyle;
-   her yaklaşımda YAGNI: gereksiz özelliği çıkar
-5. Tasarımı bölümler halinde sun — mimari, bileşenler, veri akışı, hata
-   yönetimi, test stratejisi; her bölümün ardından "şimdiye kadar doğru mu?" de
-6. Onaylı tasarımı yaz: `<workspace>/docs/plans/specs/YYYY-MM-DD-<konu>-design.md`
-7. Spec öz-denetim: "TBD/TODO" var mı, iç tutarlılık, kapsam tek plana sığıyor mu,
-   iki şekilde yorumlanabilir gereksinim var mı → düzelt
-8. Kullanıcıya spec dosyasını göster, incelemesini iste
-9. Onay gelince writing-plans skill'iyle implementasyon planına geç — başka hiçbir
-   implementasyon adımı bu kapıdan önce gelmez
-
-## Mevcut Kodda Çalışırken
-
-- Değişiklik önermeden önce mevcut yapıyı incele; var olan deseni takip et
-- İşini etkileyen sorunlu noktalar varsa (şişmiş dosya, bulanık sınır) hedefli
-  iyileştirmeyi tasarıma dahil et
-- Alakasız refactoring önerme — mevcut hedefe hizmet eden kal
+---
+name: brainstorming
+description: Yaratıcı işe KOD YAZMADAN ÖNCE kullan — yeni özellik, yeni proje, bileşen, davranış değişikliği istendiğinde; niyeti, gereksinimleri ve tasarımı kullanıcıyla netleştirmeden implementasyona geçmek yasaktır.
+---
+
+# Brainstorming: Fikirden Tasarıma
+
+Fikirleri doğal diyalogla tam oluşmuş tasarımlara dönüştür.
+
+Akış: bağlamı anla → fikri netleştir → tasarımı sun → kullanıcı onayı.
+
+<ZOR KAPI>
+Kullanıcıya ne yapacağını söyleyip onayı almadan HİÇBİR implementasyon
+eylemi yok: kod yazma, proje scaffold'ı, dosya üretme. Bu kapı HER görev
+için geçerlidir; törenin boyutu göreve göre ölçeklenir ama ONAY KAPISI
+ölçeklenmez.
+</ZOR KAPI>
+
+## Üç Yol
+
+İlk sorudan önce isteği SINIFLANDIR ve sınıfı sesli söyle — "bu sınırlı
+kapsamlı görünüyor, spec dosyası yazmak yerine kısa tasarımı burada sunacağım"
+— kullanıcı override edebilsin:
+
+- **Spike** — fizibilite sorusu ("yapılabilir mi", "hızlı-çirkin olsun").
+  Çıktısı tuttuğun kod değil, bir CEVAPTIR. Soru ve deneme planını 2-3
+  cümleyle sun, onay al, en ucuz yolla araştır. Tasarım dosyası yok.
+  Bulgu → öneri olarak raporla; bir şey inşa ettiysen "atılabilir" etiketiyle.
+- **Sınırlı (Bounded)** — mevcut koda iyi tanımlı değişiklik: yeni flag,
+  küçük endpoint, tek dosyalık fix. "Sınırlı" için DEĞİŞTİRECEĞİN AKIŞIN
+  Bu projede zaten var olması şart. Önemli netleştirme sorularını sor,
+  KISA tasarımı SOHBETTE sun (birkaç cümle - paragraf) ve DUR. Kullanıcı
+  "evet" demeden implementasyon yok. Spec dosyası yok, plan dosyası yok.
+- **Mimari** — yeni projeler, yeni alt sistemler, bileşen ilişkilerini
+  değiştiren işler. Tam süreç: sorular → 2-3 yaklaşım → bölümlü tasarım →
+  yazılı spec → writing-plans skill'i.
+
+İki yol arasında tereddüt varsa AĞIRINI seç. Ortasında gizli karmaşıklık
+çıkarsa yol YÜKSELTİLİR (dur, söyle, büyüt); asla aşağı inmez.
+
+## Anti-Desen: "Onaya Gerek Yok Kadar Basit"
+
+Her yol onayla biter. Todo listesi, tek fonksiyon, config değişikliği —
+tasarım sohbette iki cümle olabilir ama SUN ve ONAY AL. "Basit" işler,
+incelenmemiş varsayımların en çok iş boşa çıkardığı yerdir. Basitlikle
+ölçeklenen şey artefaktır; onay asla değil.
+
+## Kırmızı Bayraklar
+
+| Düşünce | Gerçek |
+|---|---|
+| "Bu, tasarım gerektirmeyecek kadar basit" | Basitlik kısa tasarım demektir, tasarım yok demek değil. |
+| "Sınırlı der spec'i atlarım" | Etiket arayışı şüphenin ta kendisi — ağır yolu seç. |
+| "Tasarım bariz, onu okurken başlarım" | Kapı onaydır, tasarımın uzunluğu değil. Sun ve evet bekle. |
+| "Bu tür app'leri biliyorum, sınırlıdır" | Sınırlı olma projeyi ölçer, bilgini değil. Akış yoksa mimaridir. |
+| "Spike çalıştı, kodu tutayım" | Spike'ın çıktısı cevaptır. Kodu tutmak YENİ istektir — sınıflandır. |
+| "Büyüdü ama az kaldı, yeniden sınıflandırmaya gerek yok" | Gizli karmaşıklık yolu ortada yükseltir. Dur ve söyle. |
+
+## Kontrol Listesi
+
+**Spike:** bağlamı gör → soru+plan sun (2-3 cümle) → onay → en ucuz yolla araştır → öneri raporla.
+
+**Sınırlı:** bağlamı gör (dosyalar, dokümanlar, son commit'ler) → netleştirme
+soruları TEK TEK → kısa tasarımı sohbette sun (yaklaşım, dokunulan dosyalar,
+test stratejisi) → açık "evet" bekle (sunup hemen başlamak = kapıyı atlamak) →
+normal iş akışıyla uygula (TDD geçerli).
+
+**Mimari:**
+1. Bağlamı gör: mevcut yapıyı list_dir/grep/read_file ile incele, deseni takip et
+2. Netleştirme soruları — TEK SORU PER MESAJ; amaç/kısıt/başarı kriterini anla;
+   çoklu seçmeli soru tercih et
+3. Kapsam çok buysa parçala: bağımsız alt-projelere böl, sırayı belirle,
+   ilk alt-projeyle normal akışa gir
+4. 2-3 yaklaşım öner — artı/eksileriyle; önerini BAŞA koy ve nedenini söyle;
+   her yaklaşımda YAGNI: gereksiz özelliği çıkar
+5. Tasarımı bölümler halinde sun — mimari, bileşenler, veri akışı, hata
+   yönetimi, test stratejisi; her bölümün ardından "şimdiye kadar doğru mu?" de
+6. Onaylı tasarımı yaz: `<workspace>/docs/plans/specs/YYYY-MM-DD-<konu>-design.md`
+7. Spec öz-denetim: "TBD/TODO" var mı, iç tutarlılık, kapsam tek plana sığıyor mu,
+   iki şekilde yorumlanabilir gereksinim var mı → düzelt
+8. Kullanıcıya spec dosyasını göster, incelemesini iste
+9. Onay gelince writing-plans skill'iyle implementasyon planına geç — başka hiçbir
+   implementasyon adımı bu kapıdan önce gelmez
+
+## Mevcut Kodda Çalışırken
+
+- Değişiklik önermeden önce mevcut yapıyı incele; var olan deseni takip et
+- İşini etkileyen sorunlu noktalar varsa (şişmiş dosya, bulanık sınır) hedefli
+  iyileştirmeyi tasarıma dahil et
+- Alakasız refactoring önerme — mevcut hedefe hizmet eden kal

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

@@ -1,120 +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)
+---
+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

@@ -1,60 +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
+---
+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