Claude Code'da Prompt Engineering: Etkili İstem Yazma Rehberi

Claude Code'a aynı görevi iki farklı şekilde verdiğinizde çok farklı sonuçlar aldığınızı fark etmişsinizdir. "Kodu iyileştir" dediğinizde Claude bir şeyler yapar ama genelde tahmin yürütür; "UserService sınıfındaki tekrar eden veritabanı sorgularını tek bir metoda topla, sonra mevcut testleri çalıştır" dediğinizde ise net, doğrulanabilir bir sonuç alırsınız. Aradaki fark prompt kalitesidir. Bu yazıda, Claude Code'un resmi dokümantasyonuna (code.claude.com/docs) ve Claude'un genel prompt mühendisliği rehberine (platform.claude.com/docs) dayanarak, Claude Code'a nasıl etkili istem yazılacağını -- bağlam sağlamadan doğrulama döngüsü kurmaya, plan modundan yön değiştirmeye kadar -- uçtan uca anlatıyorum.

Neden Prompt Kalitesi Bu Kadar Önemli?

Claude Code, Claude'un bir sohbet botu gibi soru bekleyip cevap vermesinden farklı çalışır: dosyalarınızı okur, komut çalıştırır, değişiklik yapar ve siz izlerken ya da başka bir işe geçmişken sorunları kendi başına çözer. Bu otonomi, bir kısıtla birlikte gelir: Claude'un bağlam penceresi hızla dolar. Her mesaj, okunan her dosya ve her komut çıktısı bu pencereye eklenir; tek bir hata ayıklama oturumu ya da kod tabanı keşfi onlarca bin token üretebilir. Bağlam penceresi dolmaya başladıkça performans düşer -- Claude önceki talimatları "unutmaya" başlayabilir ya da daha fazla hata yapabilir.

Bu yüzden iyi bir prompt yalnızca "doğru şeyi ister" değil, aynı zamanda bağlamı verimli kullanır. Net, bağlamlı bir prompt Claude'un gereksiz keşif yapmasını, yanlış varsayımlarda bulunmasını ve sizin defalarca düzeltme yapmanızı önler -- bu da bağlam penceresini daha uzun süre temiz tutar.

Altın Kural: Açık ve Doğrudan Olun

Claude, net ve açık talimatlara iyi yanıt verir. İstediğiniz çıktı hakkında ne kadar spesifik olursanız sonuç o kadar iyileşir. "Beklentilerin ötesinde" bir davranış istiyorsanız bunu açıkça isteyin; Claude'un belirsiz bir promtan bunu çıkarmasını beklemeyin.

Resmi rehberin önerdiği altın kural şu: promptunuzu, görev hakkında sizin kadar bağlamı olmayan bir iş arkadaşınıza gösterin ve onu takip etmesini isteyin. O kişi kafası karışırsa Claude'un da kafası karışır. Pratikte bu şu anlama gelir:

• İstediğiniz çıktı formatı ve kısıtlar hakkında spesifik olun.
• Sıranın ya da eksiksizliğin önemli olduğu durumlarda talimatları numaralı liste ya da madde işaretleriyle sıralı adımlar halinde verin.

Örneğin "bir analiz paneli oluştur" demek yerine "bir analiz paneli oluştur; mümkün olduğunca ilgili özellik ve etkileşim ekle, temel seviyenin ötesine geçip tam özellikli bir uygulama yap" demek çok daha net bir hedef tanımlar ve Claude'un ne kadar kapsamlı çalışması gerektiğini belirsizlikte bırakmaz.

Talimatlarınıza Bağlam Ekleyin: "Neden"i Açıklayın

Bir talimatın arkasındaki motivasyonu açıklamak Claude'un hedefinizi daha iyi anlamasına ve daha isabetli yanıtlar üretmesine yardımcı olur. Örneğin sadece "asla üç nokta (...) kullanma" demek yerine, "bu metin bir sesli okuma motoru tarafından okunacak, üç nokta motorun nasıl telaffuz edeceğini bilemeyeceği için asla kullanma" demek, Claude'un kısıtlamayı genellemesini kolaylaştırır. Claude, verdiğiniz açıklamadan genelleme yapacak kadar yeteneklidir -- bu da benzer ama önceden öngörmediğiniz durumlarda da doğru davranmasını sağlar.

Claude Code'da bu ilke özellikle hata düzeltme ve mimari kararlarda işe yarar: "bu fonksiyonu değiştir" yerine "bu fonksiyon şu anda her istek için veritabanına ayrı ayrı sorgu atıyor, N+1 sorgu problemi yaratıyor, bu yüzden tek bir toplu sorguya çevir" demek Claude'a yalnızca ne yapacağını değil, neden yaptığını da anlatır.

Claude Code Promptlarında Somut Bağlam Sağlama

Claude niyetinizi çıkarsayabilir ama aklınızı okuyamaz. Belirli dosyalara referans verin, kısıtlardan bahsedin ve örnek desenlere işaret edin. Resmi en iyi pratikler rehberi şu dört stratejiyi öneriyor:

Strateji	Zayıf prompt	Güçlü prompt
Görevi kapsa. Hangi dosya, hangi senaryo, test tercihi.	"foo.py için test ekle"	"foo.py için, kullanıcının oturumu kapalıyken oluşan kenar durumunu kapsayan bir test yaz. mock kullanma."
Kaynağa işaret et. Sorunun cevabını verebilecek kaynağı göster.	"ExecutionFactory neden bu kadar garip bir API'ye sahip?"	"ExecutionFactory'nin git geçmişine bak ve API'sinin nasıl bu haline geldiğini özetle"
Mevcut desenlere referans ver. Kod tabanındaki örüntüleri göster.	"bir takvim widget'ı ekle"	"ana sayfadaki mevcut widget'ların nasıl uygulandığına bak, HotDogWidget.php iyi bir örnek. Kullanıcının ay seçip yıl bazında ileri/geri gezinebileceği bir takvim widget'ı yap, mevcut kütüphaneler dışında bir şey kullanma."
Belirtiyi tarif et. Semptom, muhtemel yer, "düzeldi" ne demek.	"login hatasını düzelt"	"kullanıcılar oturum zaman aşımından sonra login'in başarısız olduğunu bildiriyor. src/auth/ içindeki auth akışına, özellikle token yenilemeye bak. Sorunu yeniden üreten başarısız bir test yaz, sonra düzelt."

Belirsiz promptlar da bir işe yarar: keşif yaparken ve sonucu yönlendirmeye vaktiniz olduğunda "bu dosyada neyi geliştirirdin?" gibi bir prompt, sormayı düşünmediğiniz şeyleri gün yüzüne çıkarabilir. Ama üretim kodunda somutluk her zaman daha az düzeltmeye, dolayısıyla daha az bağlam israfına yol açar.

Zengin İçerik: @, Görseller, URL'ler ve Pipe

Claude Code'a bağlamı birkaç farklı yoldan sağlayabilirsiniz, kod dışı içerik dahil:

• @ ile dosya referansı verin -- kodun nerede olduğunu tarif etmek yerine. Claude, yanıt vermeden önce dosyayı okur. @ yazıp yol öneri menüsünden dosyayı seçebilirsiniz; bir dosyaya @ referansı verdiğinizde o dosyanın bulunduğu dizindeki ve üst dizinlerdeki CLAUDE.md dosyaları da bağlama eklenir.
• Görselleri doğrudan yapıştırın. Kopyala/yapıştır ya da sürükle-bırak ile ekran görüntüsü, tasarım mockup'ı veya diyagram ekleyebilirsiniz.
• Dokümantasyon ve API referansları için URL verin. Sık kullandığınız alan adlarını /permissions ile izin listesine ekleyebilirsiniz.
• Veriyi doğrudan pipe'layın. cat error.log | claude komutuyla dosya içeriğini doğrudan Claude'a gönderebilirsiniz.
• İhtiyacı olanı Claude'un kendisinin çekmesine izin verin. Claude'a Bash komutları, MCP araçları ya da dosya okuma ile bağlamı kendisinin toplamasını söyleyebilirsiniz.

git log --oneline -20 | claude -p "bu son commit'leri özetle"

Bu yöntemler, "şu dosyayı biliyor musun" gibi belirsiz sorular yerine Claude'a doğrudan doğru veriyi vermenizi sağlar -- hem daha az tur harcarsınız hem de bağlam israfını azaltırsınız.

Örneklerle ve XML Etiketleriyle Yönlendirme

Örnekler, Claude'un çıktı formatını, tonunu ve yapısını yönlendirmenin en güvenilir yollarından biridir. Az sayıda iyi kurgulanmış örnek (few-shot ya da multishot prompting olarak bilinir) doğruluğu ve tutarlılığı artırır. Örnek eklerken şunlara dikkat edin:

• İlgili: Gerçek kullanım durumunuzu yakından yansıtsın.
• Çeşitli: Kenar durumlarını kapsasın ve Claude'un istemediğiniz bir örüntüyü kopyalamaması için yeterince farklılaşsın.
• Yapılandırılmış: Örnekleri <example> etiketine (birden fazla örneği <examples> etiketine) sararak Claude'un bunları talimattan ayırt etmesini sağlayın.

En iyi sonuç için 3-5 örnek eklemeniz öneriliyor. Claude'dan verdiğiniz örnekleri ilgi ve çeşitlilik açısından değerlendirmesini, ya da ilk setinize dayanarak ek örnekler üretmesini de isteyebilirsiniz.

XML etiketleri genel olarak, promptunuz talimat, bağlam, örnek ve değişken girdiyi karıştırdığında da işe yarar: her içerik türünü kendi etiketine (<instructions>, <context>, <input> gibi) sarmak yanlış yorumlanma riskini azaltır. İçerik doğal bir hiyerarşiye sahipse etiketleri iç içe geçirin. Claude Code'da bu teknik özellikle uzun CLAUDE.md dosyalarında, karmaşık skill talimatlarında ve subagent sistem promptlarında işe yarar -- CLAUDE.md ve Auto Memory rehberimde proje hafızasını nasıl yapılandıracağınızı ayrıntılı anlattım.

Doğrulama Döngüsü Kurun: Claude'a Kontrol Yöntemi Verin

Claude, iş "bitmiş görünene" kadar çalışır. Çalıştırabileceği bir kontrol yoksa "bitmiş görünmek" tek sinyaldir, ve doğrulama döngüsü siz olursunuz: her hata sizin fark etmenizi bekler. Claude'a geçti/kaldı sinyali üreten bir şey verirseniz döngü kendi kendine kapanır -- Claude işi yapar, kontrolü çalıştırır, sonucu okur ve kontrol geçene kadar yineler.

Strateji	Önce	Sonra
Doğrulama kriteri sağla	"e-posta adreslerini doğrulayan bir fonksiyon yaz"	"validateEmail fonksiyonu yaz. örnek test senaryoları: user@example.com true, invalid false, user@.com false. uygulamadan sonra testleri çalıştır"
UI değişikliğini görsel doğrula	"dashboard'u daha iyi görünür yap"	"[ekran görüntüsü yapıştırılmış] bu tasarımı uygula. sonucun ekran görüntüsünü al, orijinaliyle karşılaştır. farkları listele ve düzelt"
Kök nedeni çöz, belirtiyi değil	"build başarısız oluyor"	"build şu hatayla başarısız oluyor: [hata yapıştırılmış]. düzelt ve build'in başarılı olduğunu doğrula. hatayı bastırmak yerine kök nedeni çöz"

Kontrol var olduktan sonra bunun ne kadar sıkı uygulanacağına karar verirsiniz:

• Tek promptta: Claude'dan kontrolü çalıştırıp aynı mesaj içinde yinelemesini isteyin.
• Oturum boyunca: Kontrolü bir /goal koşulu olarak ayarlayın; ayrı bir değerlendirici her turdan sonra koşulu yeniden kontrol eder, Claude koşul sağlanana kadar çalışmaya devam eder.
• Deterministik bir kapı olarak: Bir Stop hook, kontrolünüzü script olarak çalıştırır ve kontrol geçmeden turun bitmesini engeller. Claude Code, 8 ardışık bloktan sonra hook'u geçersiz kılıp turu sonlandırır.
• İkinci bir görüşle: İşi yapan modelin kendi sonucunu değerlendirmemesi için, taze bağlamda çalışan bir doğrulama subagent'ı ya da kendi bulgularını sorgulayan bir dinamik workflow kullanın.

Claude'un yalnızca "başardım" demesindense test çıktısını, çalıştırdığı komutu ve döndürdüğü sonucu ya da sonucun ekran görüntüsünü göstermesini isteyin. Kanıtı incelemek, doğrulamayı kendiniz tekrar çalıştırmaktan daha hızlıdır ve izlemediğiniz oturumlar için de işe yarar.

Önce Keşfet, Sonra Planla, Sonra Kodla: Plan Modu

Claude'un doğrudan koda geçmesine izin vermek, yanlış problemi çözen kod üretebilir. Keşfi uygulamadan ayırmak için plan modunu kullanın. Önerilen iş akışı dört aşamalıdır:

1. Keşfet. Durum çubuğunda ⏸ plan mode on görünene kadar Shift+Tab'a basarak ya da oturumu claude --permission-mode plan ile başlatarak plan moduna girin. Claude bu modda dosyaları okur ve sorulara cevap verir, değişiklik yapmaz.

> src/auth dizinini oku ve oturumları/login'i nasıl yönettiğimizi anla.
> ayrıca sırlar için ortam değişkenlerini nasıl yönettiğimize bak.

2. Planla. Claude'dan detaylı bir uygulama planı oluşturmasını isteyin.

> Google OAuth eklemek istiyorum. Hangi dosyalar değişmeli?
> Oturum akışı nasıl olmalı? Bir plan oluştur.

Claude planı önerdikten sonra Ctrl+G ile planı metin editörünüzde doğrudan düzenleyebilirsiniz.

3. Uygula. Planı onaylayarak ya da Shift+Tab'e basarak plan modundan çıkın, Claude'un plana göre doğrulayarak kod yazmasına izin verin.

> plandaki OAuth akışını uygula. callback handler için testler yaz,
> test paketini çalıştır ve başarısızlıkları düzelt.

4. Commit'le. Claude'dan açıklayıcı bir mesajla commit atmasını ve PR açmasını isteyin.

> açıklayıcı bir mesajla commit at ve PR aç

Plan modu faydalıdır ama ek yük de getirir. Kapsamın net olduğu, düzeltmenin küçük olduğu görevlerde (bir yazım hatası düzeltmek, bir log satırı eklemek, bir değişken adını değiştirmek gibi) Claude'dan doğrudan yapmasını isteyin. Planlama en çok, yaklaşımdan emin olmadığınızda, değişiklik birden fazla dosyayı etkilediğinde ya da değiştirilen koda aşina olmadığınızda değer katar. Diff'i tek cümleyle tarif edebiliyorsanız planı atlayın.

Eylem mi, Öneri mi? Açık Talimat Verin

"Bu fonksiyonu iyileştirmek için önerilerde bulunabilir misin" dediğinizde Claude bazen değişikliği yapmak yerine yalnızca öneri sunar -- değişiklik yapmasını istemiş olsanız bile. Claude'un eyleme geçmesi için daha açık olun:

	Prompt	Sonuç
Zayıf	"bu fonksiyonun performansını iyileştirmek için önerilerde bulunabilir misin?"	Yalnızca öneri sunar, kodu değiştirmez
Güçlü	"bu fonksiyonu performansını iyileştirecek şekilde değiştir" / "kimlik doğrulama akışında bu düzenlemeleri yap"	Değişikliği doğrudan uygular

Bu ayrım özellikle otomasyon script'lerinde ve claude -p ile çalışan non-interactive görevlerde önemlidir: belirsiz bir fiil kullanırsanız Claude'un öneri modunda kalıp hiçbir dosyayı değiştirmediği bir çıktı alabilirsiniz.

Aşırı Mühendislikten Kaçının: Minimal Çözüm İsteyin

Claude, istenmemiş soyutlamalar, gereksiz ekstra dosyalar ya da talep edilmeyen esneklik ekleyerek aşırı mühendisliğe kayabilir. Bunu görüyorsanız çözümü minimal tutmasını isteyen somut bir talimat ekleyin: yalnızca doğrudan istenen ya da açıkça gerekli değişiklikleri yapmasını, bir hata düzeltmesinin çevresindeki kodu temizlemesini gerektirmediğini, değiştirmediği koda docstring ya da yorum eklememesini, gerçekleşemeyecek senaryolar için hata yönetimi ya da doğrulama eklememesini ve tek seferlik işlemler için yardımcı fonksiyon ya da soyutlama oluşturmamasını belirtin.

Aynı ilke test odaklı çalışmada da geçerlidir: Claude bazen testleri geçirmeye o kadar odaklanır ki yalnızca test girdileri için çalışan, genel olmayan bir çözüm üretir ya da standart araçlar yerine yardımcı script'lerle iş görür. Genel, prensipli bir çözüm istediğinizi ve testlerin çözümü tanımlamak değil doğrulamak için var olduğunu açıkça belirtmek bu davranışı önler.

Otonomi ve Güvenlik: Ne Zaman Onay İstemeli

Yönlendirme olmadan Claude, geri alınması zor olan ya da paylaşılan sistemleri etkileyen eylemler alabilir: dosya silmek, force-push yapmak, dış servislere gönderi yapmak gibi. Riskli eylemlerden önce onay istemesini istiyorsanız promptunuza (ya da CLAUDE.md'nize) şunun gibi bir yönlendirme ekleyin: eylemlerin geri alınabilirliğini ve olası etkisini dikkate alması, dosya düzenlemek ya da test çalıştırmak gibi yerel ve geri alınabilir eylemleri serbestçe yapabilmesi, ama dosya/branch silme, veritabanı tablosu düşürme, git push --force, git reset --hard, yayınlanmış commit'leri değiştirme gibi zor geri alınır ya da paylaşılan altyapıyı etkileyen eylemlerden önce kullanıcıya sorması. Bir engelle karşılaştığında güvenlik kontrollerini (--no-verify gibi) atlayarak ya da aşina olmadığı dosyaları silerek kestirmeye gitmemesi de bu yönlendirmenin parçası olmalı.

Yön Değiştirme ve İterasyon: Course-Correct Early

Konuşmalar kalıcı ve geri alınabilirdir; bunu avantajınıza kullanın. En iyi sonuçlar sıkı geri bildirim döngülerinden gelir. Claude nadiren ilk denemede kusursuz çözer; hızlı düzeltme genelde daha iyi ve daha hızlı bir sonuç üretir.

• Esc: Claude'u eylem sırasında durdurur. Bağlam korunur, yönlendirmeye devam edebilirsiniz.
• Esc + Esc ya da /rewind: Rewind menüsünü açar; önceki bir konuşma ve kod durumuna dönebilir ya da seçili bir mesajdan itibaren özetleyebilirsiniz.
• "Bunu geri al": Claude'un yaptığı değişiklikleri geri almasını sağlar.
• /clear: İlgisiz görevler arasında bağlamı sıfırlar. Uzun oturumlarda ilgisiz bağlam performansı düşürebilir.

Aynı sorunu bir oturumda ikiden fazla düzelttiyseniz bağlam başarısız yaklaşımlarla dolmuş demektir. /clear çalıştırıp öğrendiklerinizi içeren daha spesifik bir promptla yeniden başlayın -- temiz bir oturum ve daha iyi bir prompt, birikmiş düzeltmelerle dolu uzun bir oturumdan neredeyse her zaman daha iyi performans gösterir.

Claude'a Sizi Röportaj Yapmasını Sağlayın

Büyük özellikler için, Claude'dan önce sizi röportaj yapmasını isteyin. Bu teknik, henüz düşünmediğiniz teknik uygulama, UI/UX, kenar durum ve trade-off'ları gün yüzüne çıkarır. Minimal bir açıklamayla başlayıp AskUserQuestion aracını kullanarak röportaj yapmasını isteyebilirsiniz:

[kısa özellik açıklaması] geliştirmek istiyorum. AskUserQuestion aracını
kullanarak beni detaylıca röportaj yap.

Teknik uygulama, UI/UX, kenar durumları, endişeler ve trade-off'lar hakkında
sor. Bariz sorular sorma, düşünmemiş olabileceğim zor kısımlara in.

Her şeyi kapsayana kadar röportaja devam et, sonra eksiksiz bir spesifikasyonu
SPEC.md'ye yaz.

Spesifikasyon tamamlandıktan sonra taze bir oturumda uygulamaya başlayın. Yeni oturum, tamamen uygulamaya odaklı temiz bir bağlamla başlar ve elinizde referans alacağınız yazılı bir spesifikasyon olur. En kullanışlı spesifikasyonlar kendi kendine yeterlidir: ilgili dosyaları ve arayüzleri adlandırır, kapsam dışı olanı belirtir ve özelliğin çalıştığını kanıtlayan uçtan uca bir doğrulama adımıyla biter.

Gerçek Dünya İş Akışı: Bir Özellik Ekleme

Yukarıdaki tüm teknikleri tek bir gerçekçi senaryoda birleştirelim -- bir API'ye rate limiter eklemek. Önce plan moduna girip mevcut middleware yapısını keşfedersiniz: "src/middleware/ dizinindeki mevcut middleware'lerin nasıl yapılandırıldığını incele, hangi kütüphaneleri kullandığımıza bak." Ardından somut bir plan istersiniz: "dakikada 100 istekle sınırlayan bir rate limiter ekle, limit aşıldığında 429 dönsün, mevcut middleware desenini takip et. Bir plan oluştur." Planı onayladıktan sonra doğrulama kriteriyle birlikte uygulamayı istersiniz: "planı uygula, limit aşıldığında 429 döndüğünü ve limit altında normal çalıştığını doğrulayan testler yaz, test paketini çalıştır." Son olarak, işi yapan oturumun taraflı olmaması için ayrı bir oturumda ya da subagent'ta gözden geçirme istersiniz: "rate limiter diff'ini kenar durumları, race condition'lar ve mevcut middleware desenleriyle tutarlılık açısından incele." Bu writer/reviewer deseni, taze bağlamın kod incelemesini iyileştirmesinden faydalanır -- ikinci oturum, birinci oturumun az önce yazdığı koda karşı önyargılı değildir.

Aynı desen testler için de işler: bir oturum testleri yazsın, başka bir oturum onları geçecek kodu yazsın. Uzun, otonom çalışan görevlerde bu adımı bir dizi görev boyunca sürdürmek isterseniz subagent'lar ve agent team'ler bu döngüyü siz spot-check yaparken sürdürebilir.

Sık Yapılan Hatalar

Resmi rehber, tekrar eden birkaç hata örüntüsünü ve düzeltmesini şöyle listeliyor:

Hata	Belirti	Düzeltme
Lavabo oturumu	Bir görevle başlayıp ilgisiz bir şey sorup tekrar ilk göreve dönmek; bağlam ilgisiz bilgiyle dolar	İlgisiz görevler arasında /clear çalıştırın
Sürekli düzeltme	Claude bir şeyi yanlış yapar, düzeltirsiniz, yine yanlış yapar; bağlam başarısız yaklaşımlarla kirlenir	İki başarısız düzeltmeden sonra /clear yapıp daha iyi bir başlangıç promptu yazın
Aşırı uzun CLAUDE.md	CLAUDE.md çok uzunsa Claude önemli kurallar gürültüde kaybolduğu için yarısını göz ardı eder	Acımasızca budayın; Claude bir şeyi zaten doğru yapıyorsa talimatı silin ya da hook'a çevirin
Güven-sonra-doğrula boşluğu	Claude, kenar durumlarını ele almayan makul görünümlü bir uygulama üretir	Her zaman doğrulama sağlayın (test, script, ekran görüntüsü); doğrulayamıyorsanız yayınlamayın
Sonsuz keşif	Claude'dan kapsamı belirtilmeden bir şeyi "araştırmasını" istemek; yüzlerce dosya okuyup bağlamı doldurur	Araştırmaları dar kapsamlayın ya da bağlamı doldurmaması için subagent kullanın

Bu örüntüler taş plakaya kazınmış değil; genelde iyi çalışan başlangıç noktalarıdır. Bazen bağlamın birikmesine bilerek izin vermeniz gerekir çünkü tek karmaşık bir problemin derinindesinizdir ve geçmiş değerlidir. Bazen planlamayı atlayıp Claude'un kendi başına çözmesine izin vermeniz gerekir çünkü görev keşif niteliğindedir. Zamanla, ne zaman spesifik ne zaman açık uçlu olacağınıza, ne zaman planlayıp ne zaman keşfedeceğinize dair bir sezgi geliştirirsiniz.

Sıkça Sorulan Sorular

Claude Code'a prompt yazarken en büyük hata nedir?

Belirsiz görev tanımıdır. "kodu iyileştir" ya da "dashboard yap" gibi promptlar Claude'un tahmine dayalı, sizi tatmin etmeyecek bir sonuç üretmesine yol açar. Altın kural: promptunuzu göreve az bağlamı olan bir iş arkadaşınıza gösterin; kafası karışıyorsa Claude'un da kafası karışır.

Claude Code'a verdiğim görevi nasıl doğrulatırım?

Claude'a çalıştırabileceği bir kontrol verin: test paketi, build komutu, ekran görüntüsü karşılaştırması ya da linter. Tek bir oturum boyunca geçerli bir koşul için /goal komutunu, otomasyon için Stop hook'unu, ikinci bir görüş için taze bağlamda çalışan bir doğrulama subagent'ını kullanabilirsiniz.

Plan modu ne zaman kullanılmalı?

Kapsamın belirsiz olduğu, değişikliğin birden fazla dosyayı etkilediği ya da koda aşina olmadığınız durumlarda değer katar. Diff'i tek cümleyle tarif edebiliyorsanız plan adımını atlayabilirsiniz -- plan modu ek yük de getirir.

Örnekle (few-shot) yönlendirme nasıl yapılır?

İstediğiniz format, ton ya da yapıyı gösteren 3-5 örnek en güvenilir yönlendirme yöntemlerinden biridir. Örnekleri gerçek kullanım durumunuza yakın ve kenar durumları kapsayacak kadar çeşitli tutun; birden fazla örneği <examples> etiketi içinde, her birini <example> etiketine sararak Claude'un talimattan ayırt etmesini kolaylaştırın.

Claude bir şeyi yanlış yaptığında ne yapmalıyım?

Fark eder etmez düzeltin. Esc tuşu Claude'u anında durdurur, Esc'e iki kez basmak ya da /rewind önceki bir kontrol noktasına döner. Aynı konuda ikiden fazla düzeltme yaptıysanız /clear ile bağlamı temizleyip öğrendiklerinizi içeren daha net bir promptla yeniden başlayın.

Claude'u daha eyleme geçirici (proaktif) yapmak için ne yapmalıyım?

Fiillerinizi net tutun. "önerilerde bulunabilir misin" gibi ifadeler Claude'u öneri modunda tutabilir; "bu değişikliği yap" ya da "bu düzenlemeleri uygula" gibi doğrudan talimatlar Claude'un dosyaları gerçekten değiştirmesini sağlar. Bu ayrım özellikle claude -p ile çalışan otomasyon script'lerinde önemlidir.

Özet

Claude Code'da iyi prompt yazmak; net ve doğrudan talimat vermek, "neden"i açıklayarak bağlam eklemek, spesifik dosya/senaryo/kısıt belirtmek, @ ve pipe ile zengin içerik sağlamak, örneklerle yönlendirmek, Claude'a çalıştırabileceği bir doğrulama kontrolü vermek, kapsamı belirsiz büyük değişikliklerde plan moduna geçmek, eylem beklediğinizde açık fiiller kullanmak ve Claude yoldan çıktığında hemen -- ikiden fazla denemeden önce -- yön değiştirmek anlamına gelir. Bunların hiçbiri karmaşık değil; asıl fark, bunları alışkanlık haline getirmekte. CLAUDE.md dosyanızı nasıl yapılandıracağınızı öğrenmek için CLAUDE.md ve Auto Memory rehberime, keşif ve doğrulama işlerini ana bağlamınızdan ayırmak için Subagent rehberime göz atabilirsiniz.