SSS
Sıkça sorulan sorular
Deep Work Plan hakkında en çok sorulanlara kısa yanıtlar; her biri, konuyu derinleştiren sayfaya bir bağlantıyla.
01
Deep Work Plan nedir
Deep Work Plan gerçekte ne yapar?
Deep Work Plan, bir depoyu, bir kodlama ajanının uzun işi güvenilir biçimde yürütebileceği yapılandırılmış bir ortama dönüştürür. Bir ajan skill’i olarak kurulur, depoyu bir kez kuruluma alır (bir `AGENTS.md` dizini, bir `docs/` ağacı, skill ve komutlardan oluşan bir `.agents/` kiti, gitignore’lanmış bir `.dwp/` çıktı alanı) ve o andan itibaren her hedef bir plana dönüşür: her biri kabul kriterleri ve bir doğrulama kapısı taşıyan atomik görevler; tek tek yürütülür, geçtikçe işlenir ve herhangi bir ajan tarafından diskten sürdürülebilir. Plan, güvenliği denetleyen ve son durumu doğrulayan bir Final Review ile kapanır. Metodoloji MIT lisanslıdır ve depo okuyan her kodlama ajanıyla çalışır.
Kimler içindir?
Kodlama ajanlarına gerçek, çok adımlı işler veren ve bu işin bitmesini isteyen geliştiriciler ve ekipler. Bir görev birden fazla oturuma, birden fazla dosya ailesine veya birden fazla ajana yayıldığında; bir ekip arkadaşının ajanın kaldığı yerden devam edebilmesi gerektiğinde; ya da "bitti"nin "ajanan öyle dedi" değil "doğrulandı" anlamına gelmesi gerektiğinde uyar. Tek satırlık bir düzeltmeye plan gerekmez ve metodoloji bunu açıkça söyler: orantılı titizlik kuralı, bunun yerine satır içi bir hedef, kriter ve kapı önerir.
Lite plan ile Full plan arasındaki fark nedir?
Bir gösterim tercihidir, titizlik ödünleşmesi değil. Planlar varsayılan olarak Lite’tır: sabitlenmiş görev kayıtları içeren, zaten yürütülebilir kompakt bir README — kısmi bir taslak değil. Baştan bir Full plan isterseniz `create` Full görev dosyalarını doğrudan yazar; bir görevin talimat ayrıntısı, bağımlılıkları veya sözleşmeleri incelenebilir kompakt bir kayda sığmadığında da planı Full’e genişletir. Sonraki yükseltme tamamlanmış her görevi korur. Her iki biçim de aynı kabul kriterlerini, doğrulama kapılarını, kanıtı ve zorunlu Final Review’yi taşır.
Bir araç mı, çerçeve mi yoksa metodoloji mi?
Kurulabilir bir skill olarak paketlenmiş bir metodoloji. Sunucu yok, hesap yok, tescilli biçim yok ve zaten kullandığınız kodlama ajanının ötesinde bir çalışma zamanı yok. Kurulan şey, ajanın okuduğu talimatlar; bağlam tespiti ve uyumluluk denetimi için küçük bir shell betiği kümesi; ve deponuzun benimsediği kurallardır. Planın ürettiği her şey deponuzdaki Markdown ve JSON’dur; hiçbir araç olmadan okunabilir.
Hangi kodlama ajanlarıyla çalışır?
Depo dosyalarını okuyan herhangi bir ajan. Skill, açık Agent Skills standardını ve `AGENTS.md` kuralını izler; bu yüzden Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot ve diğerleri onu normal skill ve talimat yükleme süreçleri üzerinden edinir. Metodolojinin kendi değerlendirmesi, bir satıcının ajanının başlattığı bir planın diğer satıcının ajanı tarafından her iki yönde sürdürüldüğünü gösterir. Kurulum kapsamı ve davranışsal kanıt uyumluluk matrisinde ajan başına listelenir ve ikisi asla birbirine karıştırılmaz.
Nasıl kullanılır?
Üç adım. Önce Deep Work Plan skill'ini kodlama ajanınıza kurun — en hızlı yol `npx skills add DailybotHQ/deepworkplan-skill` (veya skill repo'sunu klonlayıp `./setup.sh` çalıştırmak). İkinci olarak, depoyu bir kez onboard edin; ajan `AGENTS.md`, `docs/`, `.agents/` kitini ve gitignore edilmiş `.dwp/` alanını yığınınıza uyarlasın: https://deepworkplan.com/init.md adresine yönlendirin veya `/deepworkplan-onboard` çalıştırın. Üçüncü olarak, ince komutlarla planlayın ve çalıştırın: `/dwp-create <goal>` bir plan oluşturur; `/dwp-execute` her kapıya karşı görev görev çalıştırır; `/dwp-refine` devam eden bir planı düzenler (kapsam, görevler veya bir Lite planın Full'e yükseltilmesi); `/dwp-resume` bir kesintiden sonra devam eder; `/dwp-status` çalıştırmadan ilerlemeyi raporlar; `/dwp-verify` nesnel bir uygunluk raporu üretir; `/dwp-upgrade` yüklü bir skill’i var olan planlara dokunmadan daha yeni bir sürüme taşır. `/` komutunu yakalayan ajanlar genellikle `#` kullanır (örneğin `#dwp-execute`). Adoption endpoint ve hızlı başlangıç aynı yolu daha ayrıntılı anlatır.
Tam olarak ne kurulur ve nereye?
Ajan skill’i, ajanınızın proje veya kullanıcı skill’lerini yüklediği her yere kurulur. Kuruluma alma daha sonra deponun kendisini uyarlar: `AGENTS.md`, `docs/`, `.agents/` ve gitignore’lanmış `.dwp/` çalışma alanını oluşturur veya uzlaştırır. Skill ajana metodu öğretir; depo ise diğer ajanların devam edebilmesi için gereken bağlamı, kiti ve plan kanıtını tutar.
Deep Work Plan Git gerektirir mi?
Depolar için Git önerilir, çünkü geçmişi kurtarma ve inceleme yüzeyinin bir parçasıdır; ancak metodoloji bir Git deposu olmadan da bir ajan çalışma alanında çalışabilir. Bu durumda, kurtarmanın bir sohbet dökümüne bağlı olmaması için `state.json` kontrol noktaları ve kapı kayıtları dahil makine tarafından okunabilir durum katmanı zorunludur.
Bir skill, bir plan ve bir ürün spesifikasyonu arasındaki fark nedir?
Bir skill, ajanın tekrarlanabilir bir prosedürü nasıl gerçekleştirdiğini tanımlar. Bir DWP planı, kapsam, kabul kriterleri, doğrulama kapıları ve kanıt yoluyla somut bir değişikliği tanımlar. Bir ürün spesifikasyonu ürünün mevcut davranışını tanımlar ve uygulamadan sonra delta’lar yoluyla evrilir; skill’ler ve planlar da birer spesifikasyondur, ancak bu kanonik ürün sözleşmesini sürdürmek yerine prosedürleri ve değişiklikleri tanımlarlar.
02
Bir plan nasıl çalışır
Doğrulama kapıları nasıl uygulanır? İnsan onayı gerekir mi?
Yürütülebilir onaylamalardır ve ajan bunları kendisi çalıştırır. İnsan onayı çalışmayı iki uçtan çerçeveler: bir kişi yürütmeden önce planı onaylar ve pull request sırasında son diff’i inceler; aradaki yürütme otonomdur. Her görev, genellikle deponun kendi kalite kapısı olan somut komutları adlandırır; bunlar görevin dokunduğu yüzeyden seçilir: değişen davranışın testleri ve tüketicileri, değişiklik paylaşıldığında veya sınırlandırılamadığında tam suite’e genişletilir. Bir görev, yalnızca bu komutlar başarıyla çıktığında tamamlanmış sayılır ve davranışı değiştiren görevler testleri genişletmelidir. Bir başarısızlıkta ajan önce görevin kendi kapsamına düşen şeyi onarır ve kapıyı yeniden çalıştırır; bu kapsamda onarılamayan bir başarısızlık görevi engellenmiş olarak işaretler ve çalışmayı durdurur.
İnsanlar çalışmalar arasında kodu değiştirdiğinde plan nasıl bayatlamaktan kaçınır?
Üç cephede. Görevler düzenleme olarak değil davranış olarak yazılır: bir kabul kriteri sistemin ne yapması gerektiğini söyler, bu yüzden yeniden adlandırılmış bir dosya veya değiştirilmiş bir uygulama onu geçersiz kılmaz. Her kapı, reponun şu anki haliyle yeniden çalıştırılır; böylece kırık bir varsayım bir sonraki çalıştırmada sessizce kaymak yerine gürültülü biçimde başarısız olur ve bu başarısızlık iyileştirme için işarettir. Dokümantasyonu senkron tutmak da işin parçasıdır: davranışı değiştiren bir görev, onu tanımlayan docs ve ajan kitini de kendi kapısının içinde günceller. Her çalıştırma, reponu bulduğundan daha ajan-hazır bırakmalıdır.
Tamamlanan işi kaybetmeden planı yürütme ortasında değiştirebilir miyim?
Evet; kısmen yürütülmüş bir planı iyileştirmek birinci sınıf bir harekettir. Görev tanımları ve yürütme durumu ayrı tutulur: plan diskte bir kontrol listesi artı küçük bir durum dosyasıdır, bu yüzden tamamlananlar görev metninden bağımsız kayıtlı kalır. Bir görev yanlış çıktığında ajan onu engellenmiş işaretler ve zorlamak yerine durur. Sonra henüz çalışmamış görevleri düzenler, yeniden sıralar, böler veya düşürürken tamamlanan görevler tamamlanmış kalır. Sürdürme, durumu diskten ve gerçek repodan yeniden oluşturur ve önemli kapıları yeniden çalıştırır; altta kaymış hiçbir şey gözden kaçmaz.
İşi plana karşı sürekli kontrol eder mi, yoksa plan yalnızca başta belirlenen bir şey mi?
Plan sürekli bir kontroldür. Ajan bir seferde bir küçük görevle çalışır ve devam etmeden önce doğrulamalıdır; böylece üç adım değil bir adım sapabilir. Her görev kabul kriterleri ve bunları kanıtlayan tam komutları taşır; ilerleme giderken repoya yazılır, görev başına bir durumla; sapma size, sonraki oturuma ve sonraki ajana görünür olur. Bir plan, Final Review dahil her şey doğrulanana kadar bitmiş değildir. Dürüst uyarı: metodoloji bir ajanın baştan zayıf bir kabul kriteri yazmasını engelleyemez; sapmayı sessiz yerine gürültülü yapar.
Plan bir kez üretilip elle sürdürülür mü, yoksa kodla birlikte evrilir mi?
Hiçbiri. Bir hedeften bir kez üretilir ve sonra işin parçası olarak sürdürülür. Plan kasıtlı olarak kod diff’lerinden yeniden yazılmaz; çünkü kodu kovalayan bir spec gecikmeli bir ayna olur — metodolojinin ortadan kaldırmak için var olduğu sapma budur. Kasıtlı olarak evrilir: kapılar güncel repoya karşı yeniden çalışır, başarısız bir kapı iyileştirmeyi tetikler ve ajan bu iyileştirmeyi çalışma sırasında yapar; siz önden onaylar, sonda incelersiniz. Dokümantasyon ve testler, güncellemek her görevin kapısının içinde olduğu için yapı gereği kodla birlikte evrilir.
Oturum yarıda kesilirse ne olur?
İlerleme sohbette değil diskte yaşar. README onay kutuları, her görevin günlüğü, sınırlı bir çalışma indeksi ve makine tarafından okunabilir bir durum dosyası her görev sınırında güncellenir; durum dosyası planlı her duraklamadan önce bir kontrol noktası kaydeder. Yeni bir oturum veya farklı bir ajan bu kompakt indeksi okur, repoyla ve git geçmişiyle uzlaştırır ve bitmiş işi yeniden yapmadan ilk tamamlanmamış görevde devam eder. Yarıda kesilen plan oluşturma bile kurtarılabilir: planın kimliği ve amaçlanan görev listesi herhangi bir görev dosyasından önce yazılır; böylece yarım oluşturulmuş bir plan tahmin edilmek yerine tamamlanabilir veya atılabilir.
Final Review nedir?
Her planın zorunlu tek kapanış görevi. Sırayla: planın birikmiş tam değişiklik kümesi üzerinde bir güvenlik geçişi, AI Diff Reviewer skill’iyle diff’in zorunlu yerel incelemesi dahil; kritik bulgular düzeltilene veya açıkça kabul edilene kadar tamamlamayı engeller; son durum doğrulaması, yani nihai kodda deponun geçerli test, lint, type-check ve format suite’lerinin tamamı; ve her görevin kaydettiği skills kararlarının uzlaştırması. Ajan sonra teslim edilenleri, kanıtları ve sınırlamaları raporlar ve yalnızca siz istediğinizde oluşturarak bir kez Executive Report sunar.
Bir doğrulama kapısı başarısız olduğunda ne olur?
Başarısız bir kapı öncelikle bir onarım sinyalidir: ajan, görevin kendi kapsamına düşen şeyi düzeltir ve kapıyı yeniden çalıştırır. Bu kapsamı aşan bir başarısızlık görevi engellenmiş olarak kaydeder ve ajan tamamlandığını iddia etmeden önce durur. Kanıtı inceleyebilir, kodu onarabilir veya görevi iyileştirebilir, ardından sürdürebilirsiniz; başarısız bir komut, kapıyı zayıflatma izni değil, uyuşmazlığı çözme sinyalidir.
Uyumluluk denetleyicisi kontrollerini çalıştıramadığında ne olur?
Bunu açıkça söyler. Denetleyici, 2 çıkış kodu ve açık bir `UNVERIFIED` kararıyla sonlanır — gerçekte doğrulamadığı bir geçiş raporu asla yazdırmaz. Ortamda yetenekli bir yorumlayıcı yoksa veya bir kontrol çalışamıyorsa, dürüst sonuç “uyumlu” değil “doğrulanmamış”tır; yeşil bir sonuç her zaman her kontrolün çalıştığı ve geçtiği anlamına gelir. Aynı disiplin metodolojinin tamamına yayılır: hiçbir akış, işi tamamlanmış ilan etmek için bir kapıyı zayıflatmaz veya sahteleştirmez.
Bir plan gece boyunca veya CI içinde gözetimsiz çalışabilir mi?
Evet, plan önceden onaylanmışsa, gerekli durum katmanını taşıyorsa ve ajana sınırlı bir yetki veriyorsa. Gözetimsiz bir çalıştırma; gerçeklik saptığında, bir kapı planlanan onarım kapsamının dışında başarısız olduğunda veya yeni bir onay ya da kimlik bilgisi gerektiğinde durmalı ve bir engel kaydetmelidir.
03
Diğerleriyle karşılaştırma
Tek bir plan birden fazla repoya yayılabilir mi?
Evet — orkestratör hub arketipi tam olarak bunun için vardır. Bir hub repo koordine eden planı tutar ve her alt repo kendi planını kendi izole `.dwp/` çalışma alanında yürütür; böylece bir alt repo asla hub’ın plan durumuna yazmaz. Alt repoların tamamlanmışlığı her planın kendi en üst düzey durumundan okunur, içeride dizgi araması yapılmaz ve hub herhangi bir yere geçmeden önce nerede olduğunu kaydeder. Her alt repo, tek başına da pilotlanabilen sıradan bir DWP repo olarak kalır.
Spec Kit, OpenSpec veya Kiro gibi spec odaklı araçlardan nasıl farklıdır?
Bitişik sorunları çözerler. Spec odaklı araçlar neyin değişmesi gerektiğini yakalamada mükemmeldir: tekrarlanabilir biçimde spesifikasyonlar, gereksinimler ve değişiklik önerileri. Deep Work Plan, bir ajanın saatlerce sapmadan nasıl yürüteceğiyle ilgilidir: kuruluma alınmış harness, dokunulan yüzeyden seçilen görev başına doğrulama kapıları, diskte sürdürülebilir durum, güvenlik geçişiyle zorunlu Final Review ve reponun kendisi için bir uyumluluk denetleyicisi. İkisi birleştirilebilir; bir spec veya değişiklik önerisi bir plana beslenir. Karşılaştırma sayfası yetenekleri yan yana, her aracın kendi terimleriyle düzenler.
BMAD, Superpowers, Get Shit Done veya Gentle-AI gibi ajan iş akışı araçlarından nasıl farklıdır?
BMAD, Superpowers ve Get Shit Done gibi ajan iş akışı çerçeveleri güçlü çalışma stilleri getirir: roller, ilkeler, test-first adımlar, doğrulama alışkanlıkları. Gentle-AI, bir ajan ekosistemi yapılandırıcısı olarak komşu bir kategoride yer alır: zaten kullandığınız kodlama ajanlarını oturumlar arasında kalıcı bellek (Engram), seçilmiş skill'ler, personalar, MCP sunucuları, isteğe bağlı Spec-Driven Development ve isteğe bağlı kanıta dayalı inceleme (Receipt-Driven Development) ile donatır ve her ajanın yapılandırma dizinlerine yazar. Deep Work Plan ikisinden de farklıdır: repoda ne kalır ve ne kontrol edilebilir olduğuna odaklanır — herhangi bir ajanın soğuk okuyabildiği bir harness, kabul kriterleri ve gate'lerle görev dosyaları, bir oturumu atlatan durum, CI dostu çıkış koduna sahip bir uyumluluk denetleyici ve her akışın kaç talimat baytı yüklediğinin yayımlanmış ölçümü. Yapı gereği araçtan bağımsızdır ve ana döngüye hizmet, sağlayıcı veya sır eklemez. Katmanlar bir arada durabilir: çerçeveler ve Gentle-AI ajanın nasıl çalıştığını şekillendirir; Deep Work Plan uzun işi repo içinde kalıcı ve doğrulanabilir kılar. Karşılaştırma sayfası her yaklaşımın nerede yerleşik, isteğe bağlı veya kapsam dışı olduğunu gösterir.
Neden yalnızca ajanımın yerleşik plan modunu kullanmıyorum?
Yerleşik plan modları kullanışlıdır ve Deep Work Plan aynı alt yapı üzerine kurulur: `AGENTS.md` kuralı ve açık Agent Skills standardı. Fark, planın nerede yaşadığı ve neyin onu zorladığıdır. Yerel planlar genellikle reponun dışında yaşar ve oturumla sona erer; Deep Work Plan planı, durumunu ve kanıtını repoya yazar; böylece başka bir ajan veya ekip arkadaşı devam edebilir ve her görev yürütülebilir bir kapı ve kayıtlı bir günlük taşır. Düşünmek için ajanınızın plan modunu kullanmaya devam edersiniz; metodoloji dayanıklı, doğrulanabilir yürütme döngüsünü ekler.
04
Benimseme
Kuruluma alma repoma ne yazar ve mevcut dosyalara dokunur mu?
Kuruluma alma yıkıcı değildir: mevcut `AGENTS.md`, `docs/`, `.agents/` veya `CLAUDE.md` dosyasını algılar, üzerine yazmak yerine uzlaştırır ve bir şeyi değiştirmeden önce sorar. Gerçek komutlarla `AGENTS.md` dizini, akıl yürütülmüş bir `docs/` ağacı, modül başına docs, ince `dwp-*` komutlarıyla `.agents/` kiti, gitignore’lanmış bir `.dwp/` çıktı alanı, doğrulanmış bir test haritası ve zorunlu yerel kod incelemesi (AI Diff Reviewer skill’i artı repoya uyarlanmış inceleme eklentisi) yazar. Sonra ne üretildiğini görebilmeniz için self-check ve uyumluluk denetleyicisini çalıştırır. Daha önceki bir standartla kuruluma alınmış bir repo, yalnızca eksik veya güncel olmayan şeyleri uzlaştıran hedefli bir harness yükseltmesi alır.
Zaten kuruluma alınmış bir repoda skill’i nasıl yükseltirim?
Burada iki farklı yükseltme vardır ve akış onları ayrı tutar. Repo’nun harness’i — `AGENTS.md`, `docs/`, `.agents/` kiti — onboarding’i yeniden çalıştırarak uzlaştırılır; yalnızca eksik veya güncel olmayan kısımları doldurur. Skill’in kendisi `/dwp-upgrade` ile ilerler: son yayımlanmış sürümün salt okunur denetimi, kabul ettiğiniz etiketin doğrulanarak kurulması ve ardından onboarding’in taze bir geçiş olarak yeniden çalıştırılması. Akış boyunca her adım açık onaya bağlıdır, yerel uyarlamalar üzerine yazılmak yerine karşılaştırılır ve korunur, `.dwp/` asla göçürülmez — mevcut planlar kayıtlı biçimlerini korur ve çalışmaya devam eder.
Eklentileri kurmadan çekirdek metodolojiyi kullanabilir miyim?
Evet. Eklentiler isteğe bağlı katmanlardır ve hiçbirini içermeyen bir depo tamamen DWP uyumludur. Devcontainer’lar, Dailybot raporlaması, bağımlılık yükseltmeleri, tasarım sistemi desteği ve isteğe bağlı CI incelemesi yalnızca deponuza uyduğunda ve bunları açıkça kabul ettiğinizde sunulur.
Depomda henüz test veya lint yoksa ne olur?
DWP, bir araç zincirinin yokluğunu bir muafiyet olarak görmez. Kuruluma alma sırasında ajan, yığına uygun bir doğrulama kurulumu önerir, komutları depo dokümantasyonuna kaydeder ve bu komutları gelecekteki kapılar için hedef olarak kullanır; öneri incelemeniz için görünür kalır.
Maliyeti nedir ve verimlilik nasıl ölçülür?
Metodoloji ve skill MIT lisanslı ve ücretsizdir; core akışlarda hizmet, API anahtarı ve telemetri yoktur. Verimlilik, her akışın **girişte** yüklediği talimat byte sayısı olarak raporlanır — bir oturumun başındaki paket — ve buna ek olarak, işin gerçekten sürdüğünde akışın kendi tetikleyicilerinin yüklediklerini de ekleyen adlandırılmış **uçtan uca yollar** ile birlikte yayımlanır (örneğin yürütmeye devam eden bir sürdürme akışı genellikle giriş paketinin birkaç katını yükler). Bu iki rakamdan hiçbiri bir oturumu sınırlamaz: gerçek bir çalışma ayrıca deponun kendi dosyalarını, araç çıktısını ve planın çalışma dosyalarını da okur; bunların hiçbiri bu defterde sayılmaz. Her iki sayı da skill ile commit edilen bir betikle ölçülür, her yayın temel çizgisinde yeniden ölçülür ve bir değerlendirme defterinde yayımlanır; artışlar azalışlar kadar açıkça raporlanır. Token yüzdeleri veya maliyet tasarrufu olarak raporlanmaz; çünkü byte envanteri bunları kanıtlamaz. Donmuş bir protokol altında taze aracılarla bir kamu değerlendirmesi artık yürütüldü: aynı iki özellik; harness olmadan, önceki ana sürümle ve geçerli sürümle — her biri temiz klonlardan inşa edildi. Harness taşıyan ağaçtaki aracıların her iki görevde daha az byte okuduğunu ve geçerli sürümün özellik oturumlarının her iki görevde önceki ana sürümünkinden daha az model girdi ve çıktısı tükettiğini buldu — harness tarafından raporlandığı şekliyle, tek bir iş yükünde. Dürüst sınırları da buldu: onboarding, akışlar kullanıldığında geri ödeyen tek seferlik bir maliyettir; iş yükü başına net token yönü karışıktı; duvar saati avantajı iddia edilmez; ve taze bir aracı akışlara kendi başına girmez — akışlar sizin ya da onları çağırmayı bilen bir aracının çalıştırdığı komutlardır.
Hâlâ bir sorunuz var mı?
Hâlâ bir sorunuz var mı?
GitHub’da bir tartışma veya issue açın. Tekrar tekrar gelen sorular bu sayfaya eklenir.