Plan Mode ve Günlük İş Akışı: Keşfet, Planla, Uygula, Doğrula ve Context'i Yönetmek

Sürüm notu: Bu yazı Claude Code 2.1.325'i (13 Kasım 2026) anlatır; plan mode, /goal, checkpoint ve session komutları 15 Kasım 2026'da code.claude.com/docs'taki Permission modes, Keep Claude working toward a goal, Checkpointing, Manage sessions ve How Claude Code works sayfalarından kontrol edilmiştir. Bu yazıda resmî belgelerden yararlanılmıştır.

Önce Tahmin Et

Ayşe, sitedeki serilerin ortak örnek uygulaması Bookstore'da (bir online kitapçı) düşük stok bildirimi özelliğini Claude Code'la yazmaya karar verdi. Bütün özelliği tek bir uzun prompt'a yazdı ve session'ı Auto modda bıraktı. Konuşmanın başında bir de not düştü: "E-posta göndermek için Notifications module'ündeki mevcut servisi kullan, doğrudan SMTP (e-posta gönderme protokolü) kodu yazma." İki saat ve birkaç otomatik compaction sonra Claude, bildirim kodunun içine doğrudan bir SMTP istemcisi koydu. Ayşe Esc'e iki kez basıp kodu bir önceki noktaya geri aldı; ama yerel veritabanına uygulanmış migration geri gelmedi ve Claude'un bir sed komutuyla değiştirdiği bir dosya da eski hâline dönmedi.

Tahminin ne? Konuşmanın başında verilen talimat neden kayboldu? Geri alma menüsü hangi değişiklikleri geri getirir, hangilerini getiremez? Birinci cevap context bölümünde, ikincisi checkpoint bölümünde.

Keşfet, planla, uygula, doğrula akışının araçtan bağımsız hâlini ve spec-driven development'ı AI Destekli Geliştirme serisinin üçüncü yazısında, aynı akışın Copilot agent'ıyla uygulanışını da GitHub Copilot serisinin beşinci yazısında anlatmıştık. Burada akışı Claude Code'un komutlarıyla kuruyoruz: plan mode, plan onayı, /goal, context komutları ve checkpoint'ler.

Plan Mode: Değiştirmeden Önce Keşfetmek

Plan mode'da Claude dosyaları okuyor, keşif için shell komutları çalıştırabiliyor ve bir plan yazıyor, ama kaynak kodunu düzenlemiyor; düzenlemeler sen planı onaylayana kadar kapalı. Üç yolla girersin: session içinde Shift+Tab ile, tek bir prompt'un başına /plan yazarak ya da session'ı claude --permission-mode plan ile başlatarak. Auto mode kullanılabiliyorsa ve useAutoModeDuringPlan açıksa (varsayılan), plan sırasındaki komutları classifier değerlendiriyor; değilse yerleşik salt okuma listesi dışındaki komutlar sana soruluyor.

Plan hazır olduğunda üç seçenek çıkıyor. "Yes, and use auto mode" planı onaylayıp Auto modda uygulamaya başlatıyor (Auto kullanılamıyorsa bu seçenek "Yes, auto-accept edits" olarak görünüyor). "Yes, manually approve edits" onaylıyor ama her düzenlemeyi sana sorduruyor. "No, keep planning" planlamaya devam ettiriyor. Onaydan önce Ctrl+G planı varsayılan metin editöründe açıyor; adımları silebilir, sıralamayı değiştirebilir, eksik bir kısıtı ekleyebilirsin. Planlar ~/.claude/plans/ altına ya da ayarlarda verdiğin plansDirectory klasörüne kaydediliyor ve onaylanan plan, adı olmayan session'a plandan türetilmiş bir başlık veriyor.

Bir tuzağa dikkat: onay penceresi açıkken Shift+Tab'a basmak planı onaylıyor. Plan mode'dan onaylamadan çıkmak istiyorsan önce Esc, sonra Shift+Tab.

Bookstore: Düşük Stok Bildirimi İçin Plan

Özellik üç katmana dokunuyor: Inventory module'ünde stok eşiği ve bir uyarı entity'si (yeni bir EF (Entity Framework; .NET'in veritabanı erişim library'si) Core migration'ıyla), yönetim tarafı için bir Minimal API endpoint'i ve web/bookstore-web içinde bir yönetim sayfası. Tek bir dev "yap" prompt'u yerine önce planı istiyoruz:

/plan Add low-stock notifications to Bookstore.
When a StockItem's available quantity drops below its LowStockThreshold,
create a LowStockAlert and notify the book's publisher through the existing
Notifications module (do not send e-mail directly).
Scope: the Inventory entity and an EF Core migration, a Minimal API endpoint
GET /api/admin/low-stock-alerts, and an admin page in web/bookstore-web.
Before planning, read how Ordering reserves stock and how Notifications sends
messages. The plan must list every file to create or change, the migration
name and the tests to add. Do not plan changes to existing migrations.

Prompt'un son üç cümlesi planı review edilebilir yapıyor. "Önce şunu oku" Claude'u mevcut pattern'lere bakmaya yönlendiriyor; stok rezervasyonu Ordering'de nasıl yapılıyorsa uyarı da aynı noktada üretilmeli. "Her dosyayı, migration adını ve testleri listele" ise planı, onaydan sonra git status ile karşılaştırabileceğin bir kontrol listesine çeviriyor.

Plan geldiğinde dört soruya bak. Dosya listesinde kapsam dışı bir şey var mı, örneğin Ordering'in kendi dosyalarında beklenmedik bir değişiklik? Migration yeni mi, yoksa bir mevcut migration'a ek mi? Testler her katman için var mı, yalnız backend için mi? Belirsiz bir karar (eşiğin varsayılan değeri, aynı kitap için ikinci uyarının ne zaman üretileceği) Claude'a mı bırakılmış? Eksikleri Ctrl+G ile plana kendin yazabilirsin: "Default LowStockThreshold is 5" ya da "At most one open alert per StockItem" gibi. Migration adımında her düzenlemeyi görmek istiyorsan "Yes, manually approve edits" ile onayla; ikinci ve üçüncü katmanda Auto'ya geçmek için Shift+Tab yeterli.

Uygula ve Doğrula: /goal ile Bitiş Koşulu

Onaydan sonra Claude planı uygulamaya başlıyor. İş birkaç tur sürecekse, her turda "devam et" yazmak yerine /goal ile bir bitiş koşulu verebilirsin. Her tur bittiğinde küçük ve hızlı bir model koşulun sağlanıp sağlanmadığına bakıyor; sağlanmadıysa Claude yeni bir tura başlıyor, sağlandıysa ya da model koşulun imkânsız olduğuna karar verdiyse hedef temizleniyor:

/goal dotnet test and npm test both exit 0, the new LowStockAlert tests exist and pass, and no file under src/Bookstore.Api/Data/Migrations is modified except the new migration; or stop after 15 turns

Koşulu yazarken belgelerdeki iki ayrıntı belirleyici. Birincisi, değerlendirici model komut çalıştırmıyor ve dosya okumuyor; yalnız Claude'un konuşmada ortaya koyduğu şeye bakıyor. Bu yüzden koşul, Claude'un kendi çıktısıyla kanıtlayabileceği bir şey olmalı: "testler geçer" işe yarıyor, çünkü Claude testleri çalıştırıyor ve sonuç transcript'te görünüyor. İkincisi, /goal permission mode'u değiştirmiyor. Manual modda Claude izin verilmemiş her komutta yine sana soruyor; turların gözetimsiz ilerlemesini istiyorsan hedefi Auto modda koyman gerekiyor. Belgeler iyi bir koşulun ölçülebilir tek bir bitiş durumu, bunun nasıl kanıtlanacağı ve yol boyunca değişmemesi gerekenleri içerdiğini söylüyor; koşul en fazla 4.000 karakter olabiliyor ve "or stop after 15 turns" gibi bir ek süreyi sınırlıyor.

Session başına tek bir hedef var. Argümansız /goal koşulu, süreyi, değerlendirilen tur sayısını, harcanan token'ı ve değerlendiricinin son gerekçesini gösteriyor; /goal clear hedefi erken kaldırıyor. Aktif bir hedef --continue ya da --resume ile dönülen session'da geri geliyor. Hedef bir hook mekanizması üzerine kurulu olduğu için hook'larla aynı workspace trust kuralına tabi.

Hedef sağlandığında da iş bitmiş sayılmaz. Planın dosya listesini git status ile karşılaştır, /diff ile değişiklikleri oku, testleri kendi terminalinde çalıştır ve doğrulanan her katmandan sonra commit at.

Context'i Yönetmek

Tahmindeki ilk sorunun cevabı burada. Context window dolmaya yaklaşınca Claude Code konuşmayı otomatik olarak bir özete çeviriyor. Belgelere göre özet isteklerini ve önemli kod parçalarını koruyor, ama konuşmanın başında verilen ayrıntılı talimatlar kaybolabiliyor. Ayşe'nin SMTP notu tam olarak böyle bir talimattı. Kalıcı kuralın yeri konuşma değil CLAUDE.md: kökteki CLAUDE.md compaction'dan sonra diskten yeniden okunuyor.

Compaction'da neyin korunacağını yönlendirmenin iki yolu var. Anlık olarak /compact'a bir odak verebilirsin: /compact focus on the low-stock feature and the failing tests. Kalıcı olarak da CLAUDE.md'ye bir "Compact Instructions" bölümü eklenebiliyor. Bookstore'un kök dosyasına eklediğimiz bölüm:

## Compact Instructions
When compacting, keep: the approved plan and which of its steps are done,
the exact test commands and their last results, and every rule I gave in
this session that is not already in this file.

Context'in neyle dolduğunu /context gösteriyor. Ama en etkili araç hâlâ /clear: bir iş bitince yeni bir konuşmaya geçmek, eski konunun yeni cevaplara karışmasını ve her mesajda gereksiz geçmişin taşınmasını önlüyor. /clear low-stock-api gibi bir ad verirsen bıraktığın konuşma /resume listesinde bu adla görünüyor. Session'ları başta claude -n low-stock-ui ile ya da ortada /rename ile adlandırmak, paralel işlerde doğru konuşmaya dönmeyi kolaylaştırıyor. claude --continue bu dizindeki son konuşmayı, claude --resume seçim listesini, claude --from-pr 123 de o pull request'e (PR) bağlı session'ları açıyor.

İki küçük komut daha işe yarıyor. /btw konuşmaya eklenmeyen bir yan soru sormanı sağlıyor; "bu projede hangi test framework'ü kullanılıyor?" gibi bir soru ana işin context'ini kirletmiyor. /branch ise konuşmanın o anki kopyasını oluşturup seni ona geçiriyor; farklı bir yaklaşımı denerken asıl konuşma olduğu gibi kalıyor. Aynı session'ı iki terminalde aynı anda açmaktan kaçın: ikisi tek bir transcript'e yazıyor ve sonradan döndüğünde bazı mesajlar eksik olabiliyor.

Checkpoint'ler ve /rewind

Claude Code, bir tur başlatan her prompt'tan önce kodun durumunu kaydediyor. Bir session'da en son 100 checkpoint'in dosya kopyaları tutuluyor; checkpoint'ler konuşmayla birlikte saklandığı için session'a sonradan döndüğünde de kullanılabiliyor ve varsayılan olarak yaklaşık 30 gün sonra temizleniyor. Prompt kutusu boşken Esc'e iki kez basmak ya da /rewind (takma adları /undo ve /checkpoint) gönderdiğin prompt'ları listeliyor. Bir noktayı seçince şu seçenekler geliyor: kodu ve konuşmayı geri al, yalnız konuşmayı geri al, yalnız kodu geri al, o noktadan sonrasını özete çevir, o noktaya kadarını özete çevir ya da vazgeç. Özet seçenekleri dosyalara dokunmuyor; hedefli bir compaction gibi context'te yer açıyor.

Tahmindeki ikinci sorunun cevabı belgelerin sınırlar bölümünde. Checkpoint yalnız Claude'un dosya düzenleme tool'larıyla yaptığı değişiklikleri izliyor. Yalnız Bash komutlarıyla değişen bir dosya izlenmiyor; Ayşe'nin sed ile değişen dosyası buydu. Subagent'ların düzenlemeleri çoğu durumda geri alınmıyor. Senin elle yaptığın ya da başka bir session'ın yaptığı değişiklikler izlenmiyor. Veritabanı, API çağrıları ve deploy gibi dış sistemleri etkileyen işlemler hiç geri alınamıyor: dotnet ef database update ile yerel veritabanına uygulanan migration, kodu geri alsan da veritabanında kalıyor ve onu bir önceki migration'a dotnet ef database update ile senin döndürmen gerekiyor.

Belgelerin cümlesi açık: checkpoint'ler session içinde hızlı geri dönüş için var, kalıcı geçmiş ve ekip çalışması için version control kullanmaya devam et. Pratikte bunun anlamı, plandaki her katman doğrulandığında bir commit atmak. Checkpoint bir sonraki yanlış adımı ucuz yapıyor; commit ise doğrulanmış her durumu kalıcı yapıyor.

Üretimde Dikkat

Planı bir sözleşme gibi kullan. Onayladığın dosya listesi ile git status arasındaki her fark bir soru: Claude kapsam dışına çıktıysa nedenini sor ya da o dosyayı geri al. Plan dosyasını bir pull request açıklamasına eklemek, review eden kişiye neyin amaçlandığını da gösterir.

Uzun session'ların maliyeti var. Her mesaj bütün konuşma geçmişini yeniden işliyor; uzun bir aradan sonra büyük bir konuşmaya dönmek, prompt cache soğuduğu için pahalı olabiliyor. Belgelere göre Pro, Max ve Ultra planlarında böyle bir durumda "Resume this conversation?" penceresi, kayıtlı konuşmanın beş saatlik limitinden ne kadar kullanacağını tahmin ediyor. Yeni iş için yeni konuşma açmak çoğu zaman daha ucuz; maliyet ayrıntıları serinin son yazısında.

Gözetimsiz /goal koşularını sınırla. Tur ya da süre sınırı olmayan bir hedef, Auto modda saatlerce çalışabilir. Koşula her zaman bir "or stop after N turns" ekle ve sonucu commit'lemeden önce kendin doğrula.

Sık Düşülen Tuzaklar

Tek dev prompt. Planlanmamış bir özellik, ilk yanlış varsayımı bütün katmanlara taşıyor. Önce plan, sonra katman katman uygulama.

Uzun session'da bayat context. İki saat önce söylenen bir kural compaction'da kaybolabilir. Kalıcı kuralları CLAUDE.md'ye yaz, iş değişince /clear kullan.

Checkpoint'i git yerine koymak. Bash'in değiştirdiği dosyalar, veritabanı ve push geri alınmaz. Doğrulanan her adımdan sonra commit at.

Plan dışı dosya değişikliklerini kaçırmak. Hedef sağlandı diye diff okunmadan bırakılan bir iş, review'da en çok soru çıkaran iş olur.

Onay penceresinde Shift+Tab. Mod değiştirmek isterken planı onaylamış olursun; önce Esc.

Küçük Bir Deneme

★☆☆ Kendi repo'nda küçük bir değişikliği /plan ile iste, planı Ctrl+G ile aç ve bir kısıt ekle. Onaydan sonra uygulanan değişiklik eklediğin kısıta uydu mu?

★★☆ Bir özellik için dosya listesi içeren bir plan onayla ve iş bitince planın listesini git status --short çıktısıyla karşılaştır. Fark varsa her biri için "neden?" diye sor.

★★★ Bir hedefi /goal ile tur sınırıyla birlikte koy, bitince /goal ile durum raporuna bak. Ardından bir dosyayı yalnız bir shell komutuyla değiştirtip /rewind ile "Restore code" dene; belgelerdeki sınırla tutarlı olarak hangi dosyanın geri geldiğini, hangisinin gelmediğini not et.

Plan mode ve checkpoint'ler aynı işi daha kontrollü yapmayı sağlıyor; ama Bookstore'da her migration'da aynı adımları yazmak hâlâ tekrar eden bir iş. Beşinci yazıda bu tekrarları skill'lere ve slash command'lara paketleyeceğiz: /add-migration ve proje kurallarına uygun Angular component iskeleti.