Claude Kod Komut Satırları: Kopyalamaya Hazır 25 Komut Satırı ve Kendi Komut Satırlarınızı Yazma Yöntemleri

Süresi dolmuş bir kupon kullanan müşteriler, ödeme sırasında 500 hata alır. @src/checkout/coupons.ts dosyasını ve testlerini inceleyin. Beklenen davranış, sipariş oluşturulmadan geçersiz kupon mesajının görüntülenmesidir. Hatiyi yeniden oluşturan ve başarısız olan bir test yazın, ardından geçerli kupon davranışını değiştirmeden hatayı düzeltin. [checkout test komutu]'nu çalıştırın ve değişiklik öncesi ve sonrası sonuçları gösterin. Hatiyi yeniden oluşturamıyorsanız, uygulamayı değiştirmeden önce neleri kontrol ettiğinizi bildirin.

[rezervasyon formu yolu]'na bir tarih seçici ekleyin. @src/components/TimeSelect.tsx dosyasındaki bileşen ve doğrulama kurallarına uyun. Kullanıcılar [izin verilen tarihler]'i seçebilmeli, [kullanılamayan tarihler] ise devre dışı kalmalıdır. Kütüphane eklemeyin. [bileşen testi komutu] ve [tip denetimi komutu]'nu çalıştırın ve bu denetimlerin kapsamadığı kriterleri bildirin.

@src/reports/export.py dosyasını, girdi, çıktı biçimi ve hata davranışını koruyarak daha küçük fonksiyonlara bölün. Düzenlemeden önce [export test komutu]’nu çalıştırın ve mevcut hataları bildirin. Yeniden düzenlemeden sonra testleri yeniden çalıştırın ve her iki sonucu da gösterin. Genel arayüzü veya konuyla ilgisi olmayan dosyaları değiştirmeyin.

“Claude, Claude Chrome uzantısını kullanarak claude.ai/code adresine yaptığım her bir değişikliği test ediyor. Bir tarayıcı açıyor, kullanıcı arayüzünü test ediyor ve kod çalışana ve kullanıcı deneyimi iyi hale gelene kadar bu işlemi tekrarlıyor. ”

Bu deponun README dosyasını, proje yapılandırmasını ve üst düzey dizin yapısını inceleyin. Aşağıdakileri açıklamak için yalnızca gerektiği kadar referanslara başvurun: Uygulamanın ne yaptığı, ana giriş noktaları ve başlıca bileşenleri, testlerin bulunduğu yerler ve deponun bunları çalıştırmak için tanımladığı komutlar. Açıklamanızı destekleyen dosya yollarını belirtin. Belgelenmiş davranışları kendi çıkarımlarınızdan ayırın ve belirleyemediğiniz her şeyi işaretleyin. Gizli bilgileri veya ortam dosyalarını okumayın, yüklü bağımlılıkları incelemeyin veya herhangi bir dosyayı değiştirmeyin. Son olarak, ilk olarak okumam gereken üç dosyayı ve nedenlerini belirtin.

[Dosya, fonksiyon veya sınıf]'ın Git geçmişini, [davranış veya tasarım sorusu]na odaklanarak inceleyin. Bu davranışı ortaya çıkaran veya önemli ölçüde değiştiren commits'leri belirleyin. İlgili her commit için hash değerini verin, değişikliği özetleyin ve commit mesajında veya erişebileceğiniz bağlantılı tartışmada belgelenen gerekçeleri açıklayın. Çıkarım yoluyla elde edilen nedenleri "çıkarım" olarak etiketleyin. Geçmişte bir kararın gerekçesi açıklanmamışsa, bunu belirtin. Dosyaları veya Git geçmişini değiştirmeyin.

[Bilinen yol, işleyici veya klasör]'den başlayarak, [kullanıcı eylemi veya sistem etkinliki] gerçekleştiğinde neler olduğunu izleyin. Doğrulama, iş mantığı ve tüm veritabanı yazma işlemleri veya harici istekler boyunca ilgili çağrıları takip edin. Dosyaları ve fonksiyonları yürütme sırasına göre listeleyin; mümkünse satır referanslarını da ekleyin. Ana hata yollarını açıklayın ve akışı kapsayan mevcut testleri belirleyin. Koda göre doğrulayamadığınız bağlantıları işaretleyin. Akışı çalıştırmayın, harici hizmetleri çağırmayın veya dosyaları düzenlemeyin.

[Özellik]'i [depo alanı]'nda nasıl uygulayacağınızı planlayın. Beklenen davranış [gereksinimler]'dir ve şu alanlar değişmemelidir: [kısıtlamalar]. İlgili kodu ve mevcut testleri inceleyin. Değiştirilmesi gereken dosyaları, uygulama sırasını ve herhangi bir uyumluluk veya veri taşıma riskini belirleyin. Her bir gereksinimi önerilen bir teste veya başka bir doğrulama adımına eşleştirin. Çözülmemiş soruları ve varsayımları ayrı bir liste halinde belirtin. Özelliği henüz uygulamayın. Planı incelemem için bana geri gönderin.

[Kullanıcılar ve kullanım senaryosu] için [kısa açıklama] oluşturmak istiyorum. Önce [ilgili dosyaları veya gereksinimleri] okuyun, ardından AskUserQuestion'ı kullanarak uygulamayı önemli ölçüde etkileyecek kararları netleştirin. Sınır durumlarına, veri işleme, izinlere, beklenen kullanıcı arayüzü davranışına ve ödünleşimlere odaklanın. Sağlanan bağlamda zaten yanıtı bulunan soruları sormayın. Anahtar kararlar alındıktan sonra, gereksinimleri, kabul kriterlerini, kısıtlamaları ve kapsam dışı olanları içeren bir şartname taslağı hazırlayın. Kalan varsayımları işaretleyin. Şartnameyi [şartname yolu] konumuna kaydetmeden önce bana gösterin ve onay almadan mevcut bir dosyanın üzerine yazmayın.

Fonksiyon, bileşen veya arayüz]'ün [mevcut davranış]'tan [önerilen davranış]'a değiştirilmesinin etkisini değerlendirin. Tanımını, doğrudan çağıranları, içe aktarmaları ve ilgili testleri bulmak için [depo veya dizin kapsamı]'nda arama yapın. Değişiklik gerektirebilecek dosyaları listeye alın ve her birinin nasıl etkilenebileceğini, mümkünse dosya ve satır referanslarıyla birlikte açıklayın. Doğrulayamadığınız dinamik olarak çözümlenen çağrıları, harici tüketicileri veya diğer bağımlılıkları işaretleyin. Uygulamaya geçmeden önce yanıtlanması gereken uyumluluk sorunlarını belirleyin. Dosyaları değiştirmeyin; etki değerlendirmesini gönderin ve incelememi bekleyin.

[Dosya veya sayfa]'ya şu davranışa sahip [özellik]'i ekleyin: [kabul kriterleri]. [Mevcut uygulamayı] inceleyin ve veri alma, hataları işleme ve bileşenleri düzenleme konusunda bu uygulamanın kurallarına uyun. Yalnızca projeye önceden yüklenmiş kütüphaneleri kullanın. Değişiklikleri [kapsam] içinde tutun ve [mevcut davranışı veya genel arayüzü] koruyun. Kabul kriterleri için testler ekleyin veya güncelleyin. [test komutu] ve [tip denetimi veya lint komutu] komutlarını çalıştırın, ardından değiştirilen dosyaları, sonuçları ve tamamlayamadığınız denetimleri raporlayın. Mevcut model bir gereksinimle çakışıyorsa, devam etmeden önce bu çakışmayı açıklayın.

[Gereksinimleri] karşılamak için [dosya] içinde [fonksiyon adı]'nı uygulayın. [Normal durum], [sınır durum] ve [geçersiz girdi davranışı]'nı kapsayın. Önce [ilgili test komutunu] çalıştırın ve mevcut hataları raporlayın. İstenen davranış için testler yazın, ardından bunları uygulamadan önce çalıştırın. Yeni testlerin beklenen nedenden dolayı başarısız olduğunu doğrulayın. Fonksiyonu uygulayın ve testleri yeniden çalıştırın. Testlerin başarılı olması için doğrulama koşullarını gevşetmeyin, testleri atlamayın veya beklenen davranışı değiştirmeyin. Gereksinimler mevcut testlerle çelişiyorsa, durun ve çelişkiyi açıklayın. Öncesi ve sonrası sonuçlarını gösterin.

Projenin mevcut bileşenlerini ve stillerini kullanarak ek dosya içindeki tasarımı [bileşen veya sayfa] içinde uygulayın. [Gerekli davranışı] koruyun ve [kapsam] dışındaki değişikliklerden kaçının. [Yapılandırılmış tarayıcı veya ekran görüntüsü alma aracı] kullanarak [test verileri ve kullanıcı arayüzü durumu] ile [görünüm alanı boyutlarında] [yerel rotayı] yakalayın. Araç veya uygulama kullanılamıyorsa, görsel kontrol yapıldığını belirtmek yerine neye ihtiyaç duyulduğunu bildirin. Ekran görüntüsünü referansla karşılaştırın ve [düzen, alanlar, tipografi veya diğer kabul kriterleri]ne odaklanın. En fazla [sayı] düzeltme turu yapın, ardından kalan farklılıkları bildirin. Referans görüntüsünü değiştirmeyin. [İlgili bileşen testlerini] ve [tip kontrolü veya derleme komutunu] çalıştırın. Özetinize yakalanan ekran görüntüsünü ve gerçek kontrol sonuçlarını ekleyin.

Kullanıcılar, [tetikleyici veya girdi] olduğunda [belirti] ile karşılaşır. Beklenen davranış [beklenen sonuç]'tur. Öncelikle [klasör, fonksiyon veya akış] ile ilgili testleri inceleyin. Bildirilen davranışı yeniden üreten, başarısız bir test oluşturun. Davranışı yeniden üretemezseniz, uygulamayı değiştirmeden önce neleri kontrol ettiğinizi ve hangi bilgilerin eksik olduğunu açıklayın. Davranış yeniden üretildiğinde, [değişmemesi gereken davranış]'ı değiştirmeden sorunun nedenini giderin. Yeni testi ve [ilgili test komutunu] çalıştırın. Düzeltme öncesindeki hatayı, düzeltme sonrasındaki sonuçları ve kalan hataları gösterin.

[Derleme komutu], [yerel veya CI ortamında] şu çıktı ile başarısız oluyor: [temizlenmiş hata günlüğü]. Nedeni belirlemek için ilgili kodu ve yapılandırmayı inceleyin. Hata yerel ortamda tekrarlanmıyorsa, ortam veya bağımlılık farklılıklarını kontrol edin. Nedeni gideren en küçük değişikliği yapın. Sırf derlemeyi geçebilmek için kontrolleri devre dışı bırakmayın, hataları gizlemeyin, testleri atlamayın veya derleyici ayarlarını gevşetmeyin. Değişiklikten sonra derlemeyi yeniden çalıştırın. [sayı] düzeltme denemesinden sonra hala başarısız olursa, durun ve denediklerinizi, mevcut hatayı ve bir sonraki teşhis adımıyı bildirin. Nedeni özetleyin ve gerçek derleme sonucunu ekleyin.

Düzeltme önerisinde bulunmadan önce bir hatayı daraltmama yardımcı olun. Gözlemlenen davranış: [ne oluyor] Beklenen davranış: [ne olması gerekiyor] Ne zaman ortaya çıkıyor: [koşullar veya sıklık] Denediklerim: [adımlar ve sonuçlar] Olası nedenleri en iyi şekilde ayırt edecek soruyu seçerek, her seferinde tek bir soru sorun. Sağlanan bilgilerle zaten cevaplanmış soruları tekrarlamayın. Yeterli kanıt toplandığında, en olası açıklamayı, belirsiz kalan noktaları ve bunu doğrulayabilecek veya ekarte edebilecek en küçük testi özetleyin. Henüz dosyaları düzenlemeyin.

Bir alt ajan kullanarak [onaylanmış plan veya gereksinim dosyası] ile [temel ile karşılaştırılan fark veya dal] arasında inceleme yapın. Gereksinimler eksik veya belirsizse, eksiksizliği değerlendirmeden önce bunu bildirin. Her bir gereksinimin uygulanıp uygulanmadığını, ilgili sınır durumları için testlerin olup olmadığını ve herhangi bir değişikliğin kararlaştırılan kapsamın dışında kalıp kalmadığını kontrol edin. Farkları anlamak için gerektiğinde çevredeki kodu inceleyin. Onaylanmış sorunları çözülmemiş sorulardan ayırın. Kota doldurmak için bulgular uydurmayın veya konuyla ilgisiz stil tercihlerini dahil etmeyin. Dosyaları düzenlemeyin.

[Dosyaları veya farkları] enjeksiyon riskleri, eksik yetkilendirme kontrolleri, açığa çıkan gizli bilgiler ve kullanıcı girdilerinin güvenli olmayan şekilde işlenmesi açısından inceleyin. Bir bulguyu bildirmeden önce ilgili çağrı yapanları ve doğrulama mantığını kontrol edin. Her bir sorun için, etkilenen dosyayı ve satırları, sorunun tetiklenmesi için gerekli koşulları, olası etkisini ve önerilen düzeltmeyi belirleyin. Onaylanmış bir güvenlik açığı içeren yolu, daha fazla test gerektiren bir endişe durumundan ayırt edin. Raporda gizli değerleri tekrarlamayın, dosyaları değiştirmeyin veya canlı hizmetler üzerinde test yapmayın. Hangi alanları incelediğinizi ve kapsam dışında kalanları belirtin.

Tamamlanan değişikliği [kabul kriterleri] ile karşılaştırarak nasıl doğruladığınızı özetleyin. Her bir kriter için, gerçekleştirilen kontrolü, varsa tam komutu ve gözlemlenen sonucu listeye ekleyin. Gizli ve hassas veriler gizlenmiş şekilde ilgili çıktıları ekleyin. Önceden var olan hataları ayrı olarak belirtin. Başarılı geçen kontrolleri, başarısız olan kontrolleri ve çalıştırılmayan kontrolleri açıkça ayırt edin. Atlanan kontrolleri veya kapsamdaki sınırlamaları açıklayın. Bazı kriterler kontrol edilmemişse, değişikliğin tamamının doğrulanmış olduğunu belirtmeyin.

[Dosya veya modülü], [büyük bir fonksiyonu bölmek veya iç içe geçmiş geri çağırmaları kaldırmak gibi belirli bir hedef] doğrultusunda yeniden yapılandırın. Kamu arayüzünü, dönüş değerlerini, hata davranışını ve yan etkileri koruyun. Bir referans noktası oluşturmak için düzenlemeye başlamadan önce [ilgili test komutunu] çalıştırın. Başarısızlık olursa, devam etmeden önce hataları raporlayın. Mevcut testlerin kapsamadığı davranışları belirleyin ve gerektiğinde odaklanmış testler ekleyin. Yeniden yapılandırmayı, konuyla ilgisiz değişiklikler veya yeni bağımlılıklar olmadan gerçekleştirin. Uygulamaya uyum sağlamak için mevcut doğrulamaları zayıflatmayın. Testleri ve [tip denetimi veya lint komutunu] yeniden çalıştırın. Öncesi ve sonrası sonuçlarını gösterin, yapısal değişiklikleri özetleyin ve doğrulayamadığınız davranışları işaretleyin.

Oluşturulan ve satıcıya ait dosyalar hariç, [dizin kapsamı] içinde [eski API veya kütüphane] kullanımlarını bulun. Etkilenen dosyaları ve geçişin etkileyebileceği paylaşılan yapılandırmaları veya bağımlılıkları listeleyin. [Geçiş kılavuzu veya mevcut örnek] kullanarak, [yeni API veya sürüm]e pilot geçiş için üç temsili dosya önerin. Bunları neden seçtiğinizi açıklayın ve gerekli davranış değişikliklerini işaretleyin. Düzenleme öncesinde onayımı bekleyin. Onaylandıktan sonra, yalnızca pilot dosyaları ve açıkça onaylanmış paylaşılan bağımlılıkları taşıyın. [İlgili testleri] ve [derleme veya tür denetimi komutunu] çalıştırın. Taşıma işlemini diğer dosyalara genişletmeyin. Farkları, test sonuçlarını, uyumluluk sorunlarını ve taşıma yaklaşımında yapılması gereken değişiklikleri raporlayın. Kalan dosyalara devam etmeden önce inceleme için durun.

[Özellik veya düzeltme] için mevcut dalı, Git durumu ve farkları inceleyin. Bu değişikliğe ait dosyaları belirleyin ve ilgisiz veya izlenmeyen dosyaları ayrı olarak listeye alın. Son 10 commit'in biçimini takip ederek bir commit mesajı taslağı hazırlayın. Nelerin değiştiğini, neden değiştiğini, gerçekten çalıştırılan testleri ve kalan sınırları kapsayan bir Çekme Talebi açıklaması hazırlayın. Herhangi bir şeyi hazırlama aşamasına almadan veya yayınlamadan önce önerilen dosya listesini, commit mesajını ve PR açıklamasını gösterin. Onayımı bekleyin. Onaylandıktan sonra, yalnızca üzerinde anlaşmaya varılan dosyaları hazırlama aşamasına alın, [özellik dalı] üzerinde commit yapın, [uzak sunucu]ya push edin ve [temel dal] için bir Çekme Talebi açın. Mevcut commit'leri değiştirmeyin, zorla push yapmayın veya birleştirme işlemi gerçekleştirmeyin. Commit hash'ini ve PR bağlantısını gönderin.

[Projeye katılan bir arka uç mühendisi gibi] [okuyucu]'ya yönelik [modül] için bir README bölümü hazırlayın. Ön koşulları, kurulumu, en çok kullanacakları üç komutu ve kod veya mevcut belgelerde desteklenen yaygın hataları ele alın. Komut adlarını ve seçeneklerini [paket komut dosyaları, Makefile, CLI yardımı veya CI yapılandırması] ile karşılaştırarak doğrulayın. Doğrulayamadığınız her şeyi işaretleyin. Mümkünse [test ortamında] güvenli yerel komutları test edin. Bağımlılıkları yükleyen, dosyaları silen, verileri taşıyan, dağıtım yapan veya harici hizmetlere erişen komutları çalıştırmadan önce, bunların etkilerini açıklayın ve onay isteyin. Başarıyla çalıştırdığınız komutları, yalnızca yapılandırma veya belgelere göre kontrol edilen komutlardan açıkça ayırın. [belge yolu]'nu düzenlemeden önce önerilen README bölümünü gösterin ve konuyla ilgisi olmayan içeriği koruyun.

[CLAUDE.md dosyasının yolu] dosyasını, deponun mevcut yapısı, komut dosyaları ve kurallarıyla karşılaştırarak inceleyin. Henüz dosyayı düzenlemeyin. Güncelliğini yitirmiş talimatları, yinelemeleri, çelişkileri ve koddan güvenilir bir şekilde çıkarılabilecek kuralları belirleyin. Dosyayı kısaltmak amacıyla talimatları körü körüne çıkarmak yerine, kaldırılması önerilen her bir öğeyi açıklayın. Eksik derleme veya test komutlarını yalnızca proje komut dosyalarında, bir Makefile'da, CI yapılandırmasında veya mevcut belgelerde doğrulayabildiğinizde önerin. Her ekleme için kaynağını belirtin. Önemli proje kısıtlamalarını koruyan bir diff önerisi sunun. Bir beceri veya yol kapsamlı kurala daha uygun olacak görevle ilgili talimatları işaretleyin ve değişiklikleri uygulamadan önce onay bekleyin.

[Dosya kalıpları] üzerinde Düzenle veya Yaz değişiklikleri yapıldıktan sonra [mevcut biçimlendirici komutunu] çalıştıran bir Claude Code komut kancası önerin. Öncelikle claude/settings.json dosyasındaki mevcut ayarları ve biçimlendiricinin ayarlarını inceleyin. Yüklü Claude Code sürümü için uygun PostToolUse ayarını kullanın. Yalnızca etkilenen dosyayı biçimlendirin, yolları güvenli bir şekilde işleyin ve [oluşturulan dosyaları veya diğer hariç tutulan yolları] hariç tutun. Bağımlılıkları yüklemeyin veya mevcut kancaları değiştirmeyin. Önerilen ayarların farklarını gösterin ve biçimlendirici hatalarının nasıl raporlanacağını açıklayın. Uygulamadan önce onay bekleyin. Onaylandıktan sonra, projedeki geçici bir dosyayla test edin ve sonucu bildirin. Kabuk komutları aracılığıyla yapılan değişiklikler de dahil olmak üzere, hangi düzenleme yollarını kapsadığını ve hangilerini kapsamadığını belirtin.

[araç] –help komutunu ve [görev] ile ilgili alt komutların yardım bilgilerini inceleyin. Araç eksikse yüklemeyin; bunun yerine ön koşulu bildirin. Görevi tamamlamak için gereken komutları tam olarak önerin. Komutların girdilerini, çıktılarını ve dosya yazıp yazmadıklarını, uzak kaynakları değiştirip değiştirmediklerini veya kimlik bilgilerini kullanıp kullanmadıklarını açıklayın. Araçta bir deneme seçeneği belgelenmişse bunu da ekleyin. Eksik yapılandırma veya izinleri işaretleyin ve kaynak adlarını veya hedefleri tahmin etmek yerine açıklama isteyin. Görev komutlarını çalıştırmadan önce onay bekleyin. Onaylandıktan sonra, yalnızca üzerinde anlaşmaya varılan komutları çalıştırın ve hatalar veya tamamlanmamış adımlar dahil olmak üzere gerçek sonuçlarını raporlayın.

[Fatura ID veya eşleştirme anahtarı] kullanarak [invoices.csv] ve [ödeme.csv] dosyalarını karşılaştırın. Kaynak dosyaları değiştirmeyin. Şu kuralları uygulayın: [para birimi ve yuvarlama toleransı], [kısmi ödeme tahsisi] ve [iade, kredi ve fazla ödemelerin işlenmesi]. Bir kural eksikse veya eşleşme belirsizse, ödemeyi otomatik olarak atamak yerine işaretleyin. Kaynak satır ID'lerini koruyun. Her fatura için faturalandırılan tutarı, uygulanan ödemeleri ve kalan bakiyeyi gösterin. Yinelenen ID'leri, eşleşmeyen faturaları, eşleşmeyen ödemeleri ve tolerans sınırının dışındaki bakiyeleri raporlayın. Fatura ve ödeme toplamlarını ayrı ayrı mutabakatlayın. Her kaynak satırını çift sayım yapmadan hesaba katın; bir ödeme birden fazla faturaya bölünmüşse, her bir tahsisi gösterin ve tahsislerin ödeme tutarını aşmadığını doğrulayın. Sonuçları [yeni çıktı yollarına] kaydedin ve incelenmesi gereken istisnaları özetleyin.

[Zaman dilimi] ve [tarih sütunu] kullanılarak, [başlangıç tarihi ve saati (dahil)] ile [bitiş tarihi ve saati (dahil değil)] arasındaki [export.csv] dosyasını özetleyen bir komut dosyası yazın. Kayıtları [kategori kuralları]na göre gruplandırın ve [gerekli metrikleri] hesaplayın. Yinelenen ID'leri ve eksik değerleri [kurallara] göre işleyin. Giriş dosyasını değiştirmeyin. Komut dosyasını [tam giriş dosyası] üzerinde çalıştırın. Dahil edilen ve hariç tutulan satır sayılarını, kategori toplamlarını ve sınıflandırılamayan kayıtları raporlayın. [Üç kategori] için elde edilen sonuçları, [referans dosyası]ndaki bağımsız olarak kontrol edilmiş sayılarla karşılaştırın. Bu sayılar mevcut değilse, bağımsız doğrulamanın henüz tamamlanmadığını belirtin. Tutarsızlıkları gösterin ve raporu [yeni çıktı yolu]na kaydedin.

[Belirtilen dosyaları veya klasörü] okuyun ve [hedef kitle] için [sorular veya konular]ı kapsayan [belge türü ve uzunluğu]nda bir taslak hazırlayın. Her bir maddi iddiayı, mümkünse bir dosya adı ve sayfa, bölüm veya satır referansı ile destekleyin. Doğrudan alıntıları, kendi sözlerinizle ifade edilen alıntılardan ayırın ve bir teklif veya güncelliğini yitirmiş bir belgeyi, onaylanmış güncel bir karar olarak değerlendirmeyin. Çelişen kaynakları, eksik bilgileri ve doğrulayamadığınız iddiaları işaretleyin. Boşlukları varsayımlarla doldurmayın veya kaynak dosyaları düzenlemeyin. Taslağı, kaynak gösterimleriyle birlikte ve gözden geçiren için çözülmemiş soruların kısa bir listesiyle birlikte iade edin.

Bir şablonu uyarlamak için, şablondaki yer tutucuları projenizdeki ayrıntılarla değiştirin ve değişiklikleri yapmadan önce Claude'un ne yapması gerektiğini belirleyin. İsteği hazırlamak ve sonucu incelemek için bu adımları izleyin.

Küçük ve iyi tanımlanmış bir değişiklik için, Claude'dan bunu doğrudan uygulamasını isteyebilirsiniz. Tanımadığınız kodlar, birden fazla dosyayı etkileyen değişiklikler veya çözülmemiş gereksinimler söz konusu olduğunda, bir planla başlayın.

Plan modu görünene kadar Shift+Tab tuşlarına basın veya claude --permission-mode plan komutuyla Claude Code'u başlatın. Bu modda Claude, kaynak kodunuzu düzenlemeden dosyaları inceleyebilir ve salt okunur komutları çalıştırabilir. Uygulamayı onaylamadan önce önerilen dosyaları, bağımlılıkları ve testleri inceleyin. Önerilen planı düzenleyicinizde açmak için Ctrl+G tuşlarına basın.

Görevi anlaması için Claude’a gerekli kanıtları sağlayın: bir dosya referansı, temizlenmiş bir hata günlüğü, bir ekran görüntüsü veya bir gereksinim belgesi. @ işaretini ve ardından dosya yolunu kullanarak o dosyanın içeriğini ekleyin.

Kullanışlı olan en küçük kaynak kümesini seçin. Bir günlüğün veya dizinin tamamını dahil etmek, konuyla ilgisiz içerik ekleyebilir ve bağlamı boğabilir. Günlük paylaşımında kimlik bilgilerini ve hassas verileri kaldırın ve Claude'un, sağladığınız dokümantasyon URL'lerini almak için gerekli araçlara sahip olup olmadığını kontrol edin.

Örneğin, `cat hata.log | claude -p "Bu hatayı açıkla"` komutu, etkileşimli olmayan bir istekle bir günlüğü gönderir. Bunu yalnızca dosyanın içeriğini kontrol ettikten sonra kullanın. Bağlamsal yapay zekanın pratik değeri budur: modele görevle ilgili bilgileri sağlamak.

Bir özellik eklerken, depoda benzer bir bileşen veya fonksiyon belirleyin. Claude'a API istemcisi, doğrulama mantığı, hata işleme veya test yapısı gibi hangi kurallara uyması gerektiğini belirtin.

“@src/widgets/Weather.tsx dosyasının verileri nasıl aldığı ve önbelleğe kaydettiğini takip edin” ifadesi, Claude’a somut bir referans sağlar. Ayrıca, yeni özelliğin gerektirdiği farklılıkları da belirtin; böylece artık uygun olmayan davranışların kopyalanmasını önleyin. Bu kurallar, takımınızın yazılım geliştirme ş akışını yansıtmalıdır.

Kod değişiklikleri için ilgili test, derleme veya lint komutunu ve kontrol edilmesi gereken davranışı belirtin. Araştırma amacıyla dosya referansları veya commit ID'lerini talep edin. Kullanıcı arayüzü işleri için bir referans görüntü ve uygulamanın aynı görüntü alanında yakalanmasını sağlayacak yapılandırılmış bir yöntem sağlayın.

Claude'dan, hatalar ve atlanan kontroller dahil olmak üzere gerçekte neleri kontrol ettiğini rapor etmesini isteyin. Kanıtların gereksinimi karşılayıp karşılamadığını gözden geçirin; derlemenin başarılı olması, istenen her davranışın işlediğini garanti etmez.

Daha uzun görevler için Claude Code, /goal koşulu ve Stop kancaları da sunar. Hedef değerlendiricisi, dosyaları bağımsız olarak incelemek veya testler çalıştırmak yerine, konuşma sırasında ortaya çıkan kanıtları değerlendirir. Yapılandırılmış bir Stop kancası, görevin tamamlanmasını engelleyebilir, ancak tekrarlanan engelleme konusunda sınırları vardır. Bunların hiçbiri, uygun testlerin ve insan tarafından yapılan incelemenin yerini almaz.

Tekrarlanan düzeltmeler sorunu çözmüyorsa, durun ve orijinal talebin hangi noktaları netleştirmediğini belirleyin. Konuşmayı silmeden önce yararlı bulguları, güncel Git durumunu ve kalan işleri kaydedin.

Anthropic’in en iyi uygulamalar kılavuzu, aynı sorunla ilgili iki başarısız düzeltme denemesinden sonra baştan başlamanızı önerir. /clear komutunu kullanın, ardından öğrendiklerinizi içeren revize edilmiş bir komut girin. Konuşmayı silmek, dosyadaki değişiklikleri geri almaz.

Çalışmakta olan bir yanıtı durdurmak için Esc tuşuna basın. Komut satırı boşken Esc tuşuna iki kez basarak geri sarma menüsünü açın ve geri yüklenecek öğeyi seçin. Geri sarma işlemi tüm harici etkileri geri almaz; bu nedenle, veritabanlarında veya uzak hizmetlerdeki değişiklikler için Git kontrol noktalarını ve ayrı kurtarma prosedürlerini kullanın.

Proje genelindeki kılavuzları CLAUDE.md dosyasına, tekrarlanabilir prosedürleri becerilere ve belirli dosyalara yönelik talimatları yol kapsamlı kurallara kaydedin. Düzenlemeden sonra biçimlendiriciyi çalıştırmak gibi belirli etkinliklere bağlı eylemler için kancalar kullanın.

Talimatın ne zaman geçerli olması gerektiğine göre seçim yapın:

Bir özelliğe ait gereksinim genellikle CLAUDE.md dosyasında değil, ilgili görev talimatında veya spesifikasyonunda yer alır. Proje genelinde geçerli bir dosyaya geçici talimatlar eklemek, bunların depo genelinde geçerli olması gereken kurallardan ayırt edilmesini zorlaştırır.

Örnek olarak, projenin test komutunu CLAUDE.md dosyasında tutun, bileşene özgü kuralları yol kapsamlı bir kuralda belirleyin ve tekrarlanan inceleme prosedürünü bir beceri olarak kaydedin. Komutlar veya kurallar değiştiğinde, diğer proje belgelerinde olduğu gibi bu dosyaları da gözden geçirin.

Yönergeler, CLAUDE.md dosyası ve beceriler, Claude’un davranışını yönlendirir; ancak bir talimatın yerine getirileceğini garanti etmezler. Kancalar, yapılandırılmış etkinliklerde denetimler gerçekleştirebilir, ancak güvenilirlikleri kanca türüne ve uygulamasına bağlıdır.

Bir komut kancası bir komut dosyasını çalıştırır. Bir komut istemi veya ajan kancası ise bir modelin kararına dayanır. Anthropic’in en iyi uygulamalar kılavuzunda da açıklandığı gibi: “Bir komut istemi veya ajan kancası, karar vermesi için başka bir modele başvurur; dolayısıyla bu da deterministik değildir.” Uygulanması gereken bir kural için uygun izin denetimlerini kullanın ve ilgili komut veya HTTP kancasını, hataları nasıl işlediğini de dahil olmak üzere test edin.

Özel alt ajanlar, tekrarlayan işleri düzenlemenin başka bir yoludur. Her uzman talimatını ana oturuma eklemek yerine, farklı bir inceleme rolüne veya araç kapsamına ihtiyaç duyulduğunda in.claude/agents/ içinde bir uzman tanımlayın. İş için en iyi Claude modeli ve yapay zeka ajan türlerine ilişkin bu kılavuzlar ek bilgi sağlar.

Takımınız birkaç farklı AI ürününe ait komutları yönetiyorsa, Claude Code'un ötesinde kütüphaneleri yönetmek için bu komut mühendisliği araçlarına göz atın.

Bir oturumda eksik veya uygun olmayan bir sonuç ortaya çıktığında, isteğin önemli kararları çözülmemiş bırakıp bırakmadığını kontrol edin. Bu beş hata, işin teşhis edilmesini ve kodun gözden geçirilmesini zorlaştırabilir.

“Depoyu incele” komutu, Claude’a hangi dosyaların önemli olduğu veya ne zaman durması gerektiği konusunda çok az yönlendirme sağlar. İsteğe neden olan soruna bir cevap içermeyen, genel bir özet alabilirsiniz.

Anlamanız gereken davranışı veya kararı adlandırın, başlangıç konumunu belirleyin ve beklenen çıktıyı tanımlayın. Örneğin: “Bu uç noktanın izinleri nasıl kontrol ettiğini izleyin ve ilgili fonksiyonları belirtin.” Alt ajanlar kullanıyorsanız, aynı sınırsız aramayı devretmek yerine her birine sınırlı bir soru verin.

Bir özellik, konuyla ilgisi olmayan bir hata ve bir dokümantasyon talebi arasında geçiş yapmak, konuşmada mevcut göreve uymayabilecek bir bağlam bırakır. “O dosya” veya “önceki yaklaşım” gibi referanslar belirsiz hale gelir.

Birbiriyle ilgisi olmayan işler için ayrı oturumlar kullanın. Birden fazla oturumun depoyu düzenleyeceği durumlarda, aynı çalışma dizinini değiştirmemeleri için ayrı Git çalışma ağaçları kullanın. Kısa bir yan soru için, Claude Code’un /btw komutu, bu alışverişi ana konuşma geçmişinin dışında tutar.

Bir özellik hatalı çalışsa bile derleme başarılı olabilir. Bir test paketi, hataya neden olan girdiyi hiç denemediği için başarılı olabilir. Claude’dan “testleri çalıştır” demek, bu testlerin hangi gereksinimi doğruladığını belirlemez.

Kabul kriterlerini belirli kontrollere eşleştirin. Bir hata düzeltmesi için, değişiklikten önce yeniden üretme testinin başarısız olduğunu ve değişiklikten sonra başarılı olduğunu gösteren kanıt isteyin. Tek bir başarılı komutu tüm değişikliğin doğrulaması olarak kabul etmek yerine, test edilmemiş kriterlerin görünürlüğünü koruyun.

Genişleyen bir CLAUDE.md dosyası, güncel olmayan komutlar, yinelenen kurallar ve görevle ilgili gereksinimlerle çelişen talimatlar içerebilir. Daha kesin ifadeler eklemek bu çelişkileri çözmez.

Dosyayı mevcut depo ile karşılaştırarak gözden geçirin. Güncelliğini yitirmiş kılavuzları kaldırın, çelişen kuralları netleştirin ve dar kapsamlı talimatları yol kapsamlı kurallara veya becerilere taşıyın. Bir gerekliliğin uygulanması gerekiyorsa, tekrarlanan hatırlatıcılara güvenmek yerine uygun denetimleri yapılandırın ve test edin.

Bir inceleme, gerçek hataları, belirsiz sorunları ve isteğe bağlı yeniden yapılandırma önerilerini bir arada ortaya çıkarabilir. Her öneriyi uygulamak, istenen davranışı iyileştirmeden değişikliği genişletebilir.

Her bulgunun ardındaki kanıtları ve etkilerini sorgulayın. Doğruluk sorunlarına ve karşılanmamış gereksinimlere öncelik verin, belirsiz iddiaları araştırın ve konuyla ilgisi olmayan iyileştirmeleri mevcut fark listesinin dışında tutun. Bir gözden geçiren, kanıtlar bu sonucu desteklediğinde, eyleme geçilmesini gerektiren herhangi bir bulgu olmadığını bildirebilmelidir.

Bir şablonu uyarlamak için, şablondaki yer tutucuları projenizdeki ayrıntılarla değiştirin ve değişiklikleri yapmadan önce Claude'un ne yapması gerektiğini belirleyin. İsteği hazırlamak ve sonucu incelemek için bu adımları izleyin.

Küçük ve iyi tanımlanmış bir değişiklik için, Claude'dan bunu doğrudan uygulamasını isteyebilirsiniz. Tanımadığınız kodlar, birden fazla dosyayı etkileyen değişiklikler veya çözülmemiş gereksinimler söz konusu olduğunda ise bir planla başlayın.

Plan modu görünene kadar Shift+Tab tuşlarına basın veya claude --permission-mode plan komutuyla Claude Code'u başlatın. Bu modda Claude, kaynak kodunuzu düzenlemeden dosyaları inceleyebilir ve salt okunur komutları çalıştırabilir. Uygulamayı onaylamadan önce önerilen dosyaları, bağımlılıkları ve testleri inceleyin. Önerilen planı düzenleyicinizde açmak için Ctrl+G tuşlarına basın.

Görevi anlaması için Claude’a gerekli kanıtları sağlayın: bir dosya referansı, temizlenmiş bir hata günlüğü, bir ekran görüntüsü veya bir gereksinim belgesi. Dosyanın içeriğini eklemek için @ işaretini ve ardından dosya yolunu kullanın.

Kullanışlı olan en küçük kaynak kümesini seçin. Bir günlüğün veya dizinin tamamını dahil etmek, konuyla ilgisiz içerik ekleyebilir ve bağlamı boğabilir. Günlük paylaşımında kimlik bilgilerini ve hassas verileri kaldırın ve Claude'un, sağladığınız dokümantasyon URL'lerini almak için gerekli araçlara sahip olup olmadığını kontrol edin.

Örneğin, `cat error.log | claude -p "Bu hatayı açıkla"` komutu, etkileşimli olmayan bir istekle bir günlüğü gönderir. Bunu yalnızca dosyanın içeriğini kontrol ettikten sonra kullanın. Bağlamsal yapay zekanın pratik değeri budur: modele görevle ilgili bilgileri sağlamak.

Bir özellik eklerken, depoda benzer bir bileşen veya fonksiyon belirleyin. Claude'a API istemcisi, doğrulama mantığı, hata işleme veya test yapısı gibi hangi kurallara uyması gerektiğini belirtin.

“@src/widgets/Weather.tsx dosyasının verileri nasıl aldığı ve önbelleğe kaydettiğini takip edin” ifadesi, Claude’a somut bir referans sağlar. Ayrıca, yeni özelliğin gerektirdiği farklılıkları da belirtin; böylece artık uygun olmayan davranışların kopyalanmasını önleyin. Bu kurallar, takımınızın yazılım geliştirme ş Akışını yansıtmalıdır.

Kod değişiklikleri için ilgili test, derleme veya lint komutunu ve kontrol edilmesi gereken davranışı belirtin. Araştırma amacıyla dosya referansları veya commit ID'lerini talep edin. Kullanıcı arayüzü işleri için bir referans görüntü ve uygulamanın aynı görüntü alanında yakalanmasını sağlayacak yapılandırılmış bir yöntem sağlayın.

Claude'dan, hatalar ve atlanan kontroller dahil olmak üzere gerçekte neleri kontrol ettiğini rapor etmesini isteyin. Kanıtların gereksinimi karşılayıp karşılamadığını gözden geçirin; derlemenin başarılı olması, istenen her davranışın çalıştığını garanti etmez.

Daha uzun görevler için Claude Code ayrıca bir /hedef koşulu ve Stop kancaları sunar. Hedef değerlendiricisi, dosyaları bağımsız olarak incelemek veya testler çalıştırmak yerine, konuşma sırasında ortaya çıkan kanıtları değerlendirir. Yapılandırılmış bir Stop kancası, görevin tamamlanmasını engelleyebilir, ancak tekrarlı engelleme konusunda sınırlamaları vardır. Bunların hiçbiri, uygun testlerin ve insan tarafından yapılan incelemenin yerini almaz.

Tekrarlanan düzeltmeler bir sorunu çözmüyorsa, durun ve orijinal talebin hangi noktaları belirsiz bıraktığını belirleyin. Konuşmayı silmeden önce yararlı bulguları, güncel Git durumunu ve kalan işleri kaydedin.

Anthropic’in en iyi uygulamalar kılavuzu, aynı sorunla ilgili iki başarısız düzeltme denemesinden sonra baştan başlamanızı önerir. /clear komutunu kullanın, ardından öğrendiklerinizi içeren revize edilmiş bir komut girin. Konuşmayı silmek, dosyadaki değişiklikleri geri almaz.

Çalışmakta olan bir yanıtı durdurmak için Esc tuşuna basın. Komut satırı boşken Esc tuşuna iki kez basarak geri sarma menüsünü açın ve geri yüklenecek öğeyi seçin. Geri sarma işlemi tüm harici etkileri geri almaz; bu nedenle, veritabanlarında veya uzak hizmetlerdeki değişiklikler için Git kontrol noktalarını ve ayrı kurtarma prosedürlerini kullanın.

Proje genelindeki kılavuzları CLAUDE.md dosyasına, tekrarlanabilir prosedürleri becerilere ve belirli dosyalara yönelik talimatları yol kapsamlı kurallara kaydedin. Düzenlemeden sonra biçimlendiriciyi çalıştırmak gibi belirli etkinliklere bağlı eylemler için kancalar kullanın.

Talimatın ne zaman geçerli olması gerektiğine göre seçim yapın:

Bir özelliğe ait gereksinim genellikle CLAUDE.md dosyasında değil, ilgili görev talimatında veya spesifikasyonunda yer alır. Proje genelinde geçerli bir dosyaya geçici talimatlar eklemek, bunların depo genelinde geçerli olması gereken kurallardan ayırt edilmesini zorlaştırır.

Örnek olarak, projenin test komutunu CLAUDE.md dosyasında tutun, bileşene özgü kuralları yol kapsamlı bir kuralda belirleyin ve tekrarlanan inceleme prosedürünü bir beceri olarak kaydedin. Komutlar veya kurallar değiştiğinde, diğer proje belgelerinde olduğu gibi bu dosyaları da gözden geçirin.

Yönergeler, CLAUDE.md dosyası ve beceriler, Claude’un davranışını yönlendirir; ancak bir talimatın yerine getirileceğini garanti etmezler. Kancalar, yapılandırılmış etkinliklerde denetimler gerçekleştirebilir, ancak güvenilirlikleri kanca türüne ve uygulamasına bağlıdır.

Bir komut kancası bir komut dosyasını çalıştırır. Bir komut istemi veya ajan kancası ise bir modelin kararına dayanır. Anthropic’in en iyi uygulamalar kılavuzunda da açıklandığı gibi: “Bir komut istemi veya ajan kancası, karar vermesini başka bir modelden ister; dolayısıyla bu da deterministik değildir.” Uygulanması gereken bir kural için uygun izin denetimlerini kullanın ve ilgili komut veya HTTP kancasını, hataları nasıl işlediğini de dahil olmak üzere test edin.

Özel alt ajanlar, tekrarlayan işleri düzenlemenin başka bir yoludur. Her uzman talimatını ana oturuma eklemek yerine, farklı bir inceleme rolüne veya araç kapsamına ihtiyaç duyulduğunda in.claude/agents/ içinde bir uzman tanımlayın. İş için en iyi Claude modeli ve yapay zeka ajan türlerine ilişkin bu kılavuzlar ek bilgi sağlar.

Takımınız birkaç farklı AI ürününe ait komutları yönetiyorsa, Claude Code'un ötesinde kütüphaneleri yönetmek için komut mühendisliği araçlarına göz atın.

Bir oturumda eksik veya uygun olmayan bir sonuç ortaya çıktığında, isteğin önemli kararları çözülmemiş bırakıp bırakmadığını kontrol edin. Bu beş hata, işin teşhis edilmesini ve kodun gözden geçirilmesini zorlaştırabilir.

“Depoyu incele” komutu, Claude’a hangi dosyaların önemli olduğu veya ne zaman durması gerektiği konusunda çok az yönlendirme sağlar. İsteğe neden olan soruna bir cevap içermeyen, genel bir özet alabilirsiniz.

Anlamanız gereken davranışı veya kararı adlandırın, başlangıç konumunu belirleyin ve beklenen çıktıyı tanımlayın. Örneğin: “Bu uç noktanın izinleri nasıl kontrol ettiğini izleyin ve ilgili fonksiyonları belirtin.” Alt ajanlar kullanıyorsanız, her birine aynı sınırsız aramayı devretmek yerine sınırlı bir soru verin.

Bir özellik, konuyla ilgisi olmayan bir hata ve bir dokümantasyon talebi arasında geçiş yapmak, konuşmada mevcut göreve uymayabilecek bir bağlam bırakır. “O dosya” veya “önceki yaklaşım” gibi referanslar belirsiz hale gelir.

Birbiriyle ilgisi olmayan işler için ayrı oturumlar kullanın. Birden fazla oturumun depoyu düzenleyeceği durumlarda, aynı çalışma dizinini değiştirmemeleri için ayrı Git çalışma ağaçları kullanın. Kısa bir yan soru için, Claude Code’un /btw komutu, bu alışverişi ana konuşma geçmişinin dışında tutar.

Bir özellik hatalı çalışsa bile derleme başarılı olabilir. Bir test paketi, hataya neden olan girdiyi hiç denemediği için başarılı olabilir. Claude’dan “testleri çalıştır” demek, bu testlerin hangi gereksinimi doğruladığını belirlemez.

Kabul kriterlerini belirli kontrollere eşleştirin. Bir hata düzeltmesi için, değişiklikten önce yeniden üretme testinin başarısız olduğunu ve değişiklikten sonra başarılı olduğunu gösteren kanıt isteyin. Tek bir başarılı komutu tüm değişikliğin doğrulaması olarak kabul etmek yerine, test edilmemiş kriterlerin görünürlüğünü koruyun.

Genişleyen bir CLAUDE.md dosyası, güncel olmayan komutlar, yinelenen kurallar ve görevle ilgili gereksinimlerle çelişen talimatlar içerebilir. Daha kesin ifadeler eklemek bu çelişkileri çözmez.

Dosyayı mevcut depo ile karşılaştırarak gözden geçirin. Güncelliğini yitirmiş kılavuzları kaldırın, çelişen kuralları netleştirin ve dar kapsamlı talimatları yol kapsamlı kurallara veya becerilere taşıyın. Bir gerekliliğin uygulanması gerekiyorsa, tekrarlanan hatırlatıcılara güvenmek yerine uygun denetimleri yapılandırın ve test edin.

Bir inceleme, gerçek hataları, belirsiz sorunları ve isteğe bağlı yeniden yapılandırma önerilerini bir arada ortaya çıkarabilir. Her öneriyi uygulamak, istenen davranışı iyileştirmeden değişikliği genişletebilir.

Her bulgunun ardındaki kanıtları ve etkilerini sorgulayın. Doğruluk sorunlarına ve karşılanmamış gereksinimlere öncelik verin, belirsiz iddiaları araştırın ve konuyla ilgisi olmayan iyileştirmeleri mevcut fark listesinin dışında tutun. Bir gözden geçiren, kanıtlar bu sonucu desteklediğinde, eyleme geçilmesini gerektiren herhangi bir sorun olmadığını bildirebilmelidir.

Bir şablonu uyarlamak için, şablondaki yer tutucuları projenizdeki ayrıntılarla değiştirin ve değişiklikleri yapmadan önce Claude'un ne yapması gerektiğini belirleyin. İsteği hazırlamak ve sonucu incelemek için bu adımları izleyin.

Küçük ve iyi tanımlanmış bir değişiklik için, Claude'dan bunu doğrudan uygulamasını isteyebilirsiniz. Tanımadığınız kodlar, birden fazla dosyayı etkileyen değişiklikler veya çözülmemiş gereksinimler söz konusu olduğunda, bir planla başlayın.

Plan modu görünene kadar Shift+Tab tuşlarına basın veya claude --permission-mode plan komutuyla Claude Code'u başlatın. Bu modda Claude, kaynak kodunuzu düzenlemeden dosyaları inceleyebilir ve salt okunur komutları çalıştırabilir. Uygulamayı onaylamadan önce önerilen dosyaları, bağımlılıkları ve testleri inceleyin. Önerilen planı düzenleyicinizde açmak için Ctrl+G tuşlarına basın.

Görevi anlaması için Claude’a gerekli kanıtları sağlayın: bir dosya referansı, temizlenmiş bir hata günlüğü, bir ekran görüntüsü veya bir gereksinim belgesi. @ işaretini ve ardından dosya yolunu kullanarak o dosyanın içeriğini ekleyin.

Kullanışlı olan en küçük kaynak kümesini seçin. Bir günlüğün veya dizinin tamamını dahil etmek, konuyla ilgisiz içerik ekleyebilir ve bağlamı boğabilir. Günlük paylaşımında önce kimlik bilgilerini ve hassas verileri kaldırın ve Claude'un, sağladığınız dokümantasyon URL'lerini almak için gerekli araçlara sahip olup olmadığını kontrol edin.

Örneğin, `cat hata.log | claude -p "Bu hatayı açıkla"` komutu, etkileşimli olmayan bir istekle bir günlüğü gönderir. Bunu yalnızca dosyanın içeriğini kontrol ettikten sonra kullanın. Bağlamsal yapay zekanın pratik değeri budur: modele görevle ilgili bilgileri sağlamak.

Bir özellik eklerken, depoda benzer bir bileşen veya fonksiyon belirleyin. Claude'a API istemcisi, doğrulama mantığı, hata işleme veya test yapısı gibi hangi kurallara uyması gerektiğini belirtin.

“@src/widgets/Weather.tsx dosyasının verileri nasıl aldığı ve önbelleğe kaydettiğini takip edin” ifadesi, Claude’a somut bir referans sağlar. Ayrıca, yeni özelliğin gerektirdiği farklılıkları da belirtin; böylece artık uygun olmayan davranışların kopyalanmasını önleyin. Bu kurallar, takımınızın yazılım geliştirme ş Akışını yansıtmalıdır.

Kod değişiklikleri için ilgili test, derleme veya lint komutunu ve kontrol edilmesi gereken davranışı belirtin. Araştırma amacıyla dosya referansları veya commit ID'lerini talep edin. Kullanıcı arayüzü işleri için bir referans görüntü ve uygulamanın aynı görüntü alanında yakalanmasını sağlayacak yapılandırılmış bir yöntem sağlayın.

Claude'dan, hatalar ve atlanan kontroller dahil olmak üzere gerçekte neleri kontrol ettiğini rapor etmesini isteyin. Kanıtların gereksinimi karşılayıp karşılamadığını gözden geçirin; derlemenin başarılı olması, istenen her davranışın çalıştığını kanıtlamaz.

Daha uzun görevler için Claude Code ayrıca bir /goal koşulu ve Stop kancaları sunar. Hedef değerlendiricisi, dosyaları bağımsız olarak incelemek veya testler çalıştırmak yerine, konuşma sırasında ortaya çıkan kanıtları değerlendirir. Yapılandırılmış bir Stop kancası, görevin tamamlanmasını engelleyebilir, ancak tekrarlı engelleme konusunda sınırları vardır. Hiçbiri, uygun testlerin ve insan tarafından yapılan incelemenin yerini almaz.

Tekrarlanan düzeltmeler bir sorunu çözmüyorsa, durun ve orijinal talebin hangi noktaları belirsiz bıraktığını belirleyin. Konuşmayı silmeden önce yararlı bulguları, güncel Git durumunu ve kalan işleri kaydedin.

Anthropic’in en iyi uygulamalar kılavuzu, aynı sorunla ilgili iki başarısız düzeltme denemesinden sonra baştan başlamanızı önerir. /clear komutunu kullanın, ardından öğrendiklerinizi içeren revize edilmiş bir komut girin. Konuşmayı silmek, dosyadaki değişiklikleri geri almaz.

Çalışmakta olan bir yanıtı durdurmak için Esc tuşuna basın. Komut satırı boşken Esc tuşuna iki kez basarak geri sarma menüsünü açın ve geri yüklenecek öğeyi seçin. Geri sarma işlemi tüm harici etkileri geri almaz; bu nedenle, veritabanlarında veya uzak hizmetlerdeki değişiklikler için Git kontrol noktalarını ve ayrı kurtarma prosedürlerini kullanın.

Proje genelindeki kılavuzları CLAUDE.md dosyasına, tekrarlanabilir prosedürleri becerilere ve belirli dosyalara yönelik talimatları yol kapsamlı kurallara kaydedin. Düzenlemeden sonra biçimlendiriciyi çalıştırmak gibi belirli etkinliklere bağlı eylemler için kancalar kullanın.

Talimatın ne zaman geçerli olması gerektiğine göre seçim yapın:

Bir özelliğe ait gereksinim genellikle CLAUDE.md dosyasında değil, ilgili görev talimatında veya spesifikasyonunda yer alır. Proje genelinde geçerli bir dosyaya geçici talimatlar eklemek, bunların depo genelinde geçerli olması gereken kurallardan ayırt edilmesini zorlaştırır.

Örneğin, projenin test komutunu CLAUDE.md dosyasında tutun, bileşene özgü kuralları yol kapsamlı bir kuralda belirleyin ve tekrarlanan inceleme prosedürünü bir beceri olarak kaydedin. Komutlar veya kurallar değiştiğinde, diğer proje belgelerinde olduğu gibi bu dosyaları da gözden geçirin.

Yönergeler, CLAUDE.md dosyası ve beceriler, Claude’un davranışını yönlendirir; ancak bir talimatın yerine getirileceğini garanti etmezler. Hook’lar, yapılandırılmış etkinliklerde kontroller gerçekleştirebilir, ancak güvenilirlikleri hook türüne ve uygulamasına bağlıdır.

Bir komut kancası bir komut dosyasını çalıştırır. Bir komut istemi veya ajan kancası ise bir modelin kararına dayanır. Anthropic’in en iyi uygulamalar kılavuzunda da açıklandığı gibi: “Bir komut istemi veya ajan kancası, karar vermesi için başka bir modele başvurur; dolayısıyla bu da deterministik değildir.” Uygulanması gereken bir kural için uygun izin denetimlerini kullanın ve ilgili komut veya HTTP kancasını, hataları nasıl işlediğini de dahil olmak üzere test edin.

Özel alt ajanlar, tekrarlayan işleri düzenlemenin başka bir yoludur. Her uzman talimatını ana oturuma eklemek yerine, farklı bir inceleme rolüne veya araç kapsamına ihtiyaç duyulduğunda in.claude/agents/ içinde bir uzman tanımlayın. İş için en iyi Claude modeli ve yapay zeka ajan türlerine ilişkin bu kılavuzlar ek bilgi sağlar.

Takımınız birkaç farklı AI ürününe ait komutları yönetiyorsa, Claude Code'un ötesinde kütüphaneleri yönetmek için bu komut mühendisliği araçlarına göz atın.

Bir oturumda eksik veya uygun olmayan bir sonuç ortaya çıktığında, isteğin önemli kararları çözülmemiş bırakıp bırakmadığını kontrol edin. Bu beş hata, işin teşhis edilmesini ve gözden geçirilmesini zorlaştırabilir.

“Depoyu incele” komutu, Claude’a hangi dosyaların önemli olduğu veya ne zaman durması gerektiği konusunda çok az yönlendirme sağlar. İsteğe neden olan soruna bir cevap içermeyen, genel bir özet alabilirsiniz.

Anlamanız gereken davranışı veya kararı adlandırın, başlangıç konumunu belirleyin ve beklenen çıktıyı tanımlayın. Örneğin: “Bu uç noktanın izinleri nasıl kontrol ettiğini izleyin ve ilgili fonksiyonları belirtin.” Alt ajanlar kullanıyorsanız, aynı sınırsız aramayı devretmek yerine her birine sınırlı bir soru verin.

Bir özellik, konuyla ilgisi olmayan bir hata ve bir dokümantasyon talebi arasında geçiş yapmak, konuşmada mevcut göreve uymayabilecek bir bağlam bırakır. “O dosya” veya “önceki yaklaşım” gibi referanslar belirsiz hale gelir.

Birbiriyle ilgisi olmayan işler için ayrı oturumlar kullanın. Birden fazla oturumun depoyu düzenleyeceği durumlarda, aynı çalışma dizinini değiştirmemeleri için ayrı Git çalışma ağaçları kullanın. Kısa bir yan soru için, Claude Code’un /btw komutu, bu alışverişi ana konuşma geçmişinin dışında tutar.

Bir özellik hatalı çalışsa bile derleme başarılı olabilir. Bir test paketi, hataya neden olan girdiyi hiç denemediği için başarılı olabilir. Claude’dan “testleri çalıştır” demek, bu testlerin hangi gereksinimi doğruladığını belirlemez.

Kabul kriterlerini belirli kontrollerle eşleştirin. Bir hata düzeltmesi için, değişikliğin öncesinde yeniden üretme testinin başarısız olduğunu ve sonrasında başarılı olduğunu gösteren kanıt isteyin. Tek bir komutun başarısını tüm değişikliğin doğrulaması olarak kabul etmek yerine, test edilmemiş kriterlerin görünürlüğünü koruyun.

Genişleyen bir CLAUDE.md dosyası, güncel olmayan komutlar, yinelenen kurallar ve görevle ilgili gereksinimlerle çelişen talimatlar içerebilir. Daha kesin ifadeler eklemek bu çelişkileri çözmez.

Dosyayı mevcut depo ile karşılaştırarak gözden geçirin. Güncelliğini yitirmiş kılavuzları kaldırın, çelişen kuralları netleştirin ve dar kapsamlı talimatları yol kapsamlı kurallara veya becerilere taşıyın. Bir gerekliliğin uygulanması gerekiyorsa, tekrarlanan hatırlatıcılara güvenmek yerine uygun denetimleri yapılandırın ve test edin.

Bir inceleme, gerçek hataları, belirsiz sorunları ve isteğe bağlı yeniden yapılandırma önerilerini bir arada ortaya çıkarabilir. Her öneriyi uygulamak, istenen davranışı iyileştirmeden değişikliği genişletebilir.

Her bulgunun ardındaki kanıtları ve etkilerini sorgulayın. Doğruluk sorunlarına ve karşılanmamış gereksinimlere öncelik verin, belirsiz iddiaları araştırın ve konuyla ilgisi olmayan iyileştirmeleri mevcut fark listesinin dışında tutun. Bir gözden geçiren, kanıtlar bu sonucu desteklediğinde, eyleme geçilmesini gerektiren herhangi bir bulgu olmadığını bildirebilmelidir.

Bir şablonu uyarlamak için, şablondaki yer tutucuları projenizdeki ayrıntılarla değiştirin ve değişiklikleri yapmadan önce Claude'un ne yapması gerektiğini belirleyin. İsteği hazırlamak ve sonucu incelemek için bu adımları izleyin.

Küçük ve iyi tanımlanmış bir değişiklik için, Claude'dan bunu doğrudan uygulamasını isteyebilirsiniz. Tanımadığınız kodlar, birden fazla dosyayı etkileyen değişiklikler veya çözülmemiş gereksinimler söz konusu olduğunda, bir planla başlayın.

Plan modu görünene kadar Shift+Tab tuşlarına basın veya claude --permission-mode plan komutuyla Claude Code'u başlatın. Bu modda Claude, kaynak kodunuzu düzenlemeden dosyaları inceleyebilir ve salt okunur komutları çalıştırabilir. Uygulamayı onaylamadan önce önerilen dosyaları, bağımlılıkları ve testleri inceleyin. Önerilen planı düzenleyicinizde açmak için Ctrl+G tuşlarına basın.

Görevi anlaması için Claude’a gerekli kanıtları sağlayın: bir dosya referansı, temizlenmiş bir hata günlüğü, bir ekran görüntüsü veya bir gereksinim belgesi. @ işaretini ve ardından dosya yolunu kullanarak o dosyanın içeriğini ekleyin.

Kullanışlı olan en küçük kaynak kümesini seçin. Bir günlüğün veya dizinin tamamını dahil etmek, konuyla ilgisiz içerik ekleyebilir ve bağlamı boğabilir. Günlükleri paylaşım öncesinde kimlik bilgilerini ve hassas verileri kaldırın ve Claude'un, sağladığınız dokümantasyon URL'lerini almak için gerekli araçlara sahip olup olmadığını kontrol edin.

Örneğin, `cat error.log | claude -p "Bu hatayı açıkla"` komutu, etkileşimli olmayan bir istekle bir günlüğü gönderir. Bunu yalnızca dosyanın içeriğini kontrol ettikten sonra kullanın. Bağlamsal yapay zekanın pratik değeri budur: modele görevle ilgili bilgileri sağlamak.

Bir özellik eklerken, depoda benzer bir bileşen veya fonksiyon belirleyin. Claude'a API istemcisi, doğrulama mantığı, hata işleme veya test yapısı gibi hangi kurallara uyması gerektiğini belirtin.

“@src/widgets/Weather.tsx dosyasının verileri nasıl aldığı ve önbelleğe kaydettiğini takip edin” ifadesi, Claude’a somut bir referans sağlar. Ayrıca, yeni özelliğin gerektirdiği farklılıkları da belirtin; böylece artık uygun olmayan davranışların kopyalanmasını önleyin. Bu kurallar, takımınızın yazılım geliştirme ş Akışını yansıtmalıdır.

Kod değişiklikleri için ilgili test, derleme veya lint komutunu ve kontrol edilmesi gereken davranışı belirtin. Araştırma amacıyla dosya referansları veya commit ID'lerini talep edin. Kullanıcı arayüzü işleri için bir referans görüntü ve uygulamanın aynı görüntü alanında yakalanmasını sağlayacak yapılandırılmış bir yöntem sağlayın.

Claude'dan, hatalar ve atlanan kontroller dahil olmak üzere gerçekte neleri kontrol ettiğini rapor etmesini isteyin. Kanıtların gereksinimi karşılayıp karşılamadığını gözden geçirin; derlemenin başarılı olması, istenen her davranışın çalıştığını garanti etmez.

Daha uzun görevler için Claude Code, /goal koşulu ve Stop kancaları da sunar. Hedef değerlendiricisi, dosyaları bağımsız olarak incelemek veya testler çalıştırmak yerine, konuşma sırasında ortaya çıkan kanıtları değerlendirir. Yapılandırılmış bir Stop kancası, görevin tamamlanmasını engelleyebilir, ancak tekrarlanan engelleme konusunda sınırlamaları vardır. Bunların hiçbiri, uygun testlerin ve insan tarafından yapılan incelemenin yerini almaz.

Tekrarlanan düzeltmeler bir sorunu çözmüyorsa, durun ve orijinal talebin hangi noktaları belirsiz bıraktığını belirleyin. Konuşmayı silmeden önce yararlı bulguları, güncel Git durumunu ve kalan işleri kaydedin.

Anthropic’in en iyi uygulamalar kılavuzu, aynı sorunla ilgili iki başarısız düzeltme denemesinden sonra baştan başlamanızı önerir. /clear komutunu kullanın, ardından öğrendiklerinizi içeren revize edilmiş bir komut girin. Konuşmayı silmek, dosyadaki değişiklikleri geri almaz.

Çalışmakta olan bir yanıtı durdurmak için Esc tuşuna basın. Komut satırı boşken Esc tuşuna iki kez basarak geri sarma menüsünü açın ve geri yüklenecek öğeyi seçin. Geri sarma işlemi tüm harici etkileri geri almaz; bu nedenle, veritabanlarında veya uzak hizmetlerdeki değişiklikler için Git kontrol noktalarını ve ayrı kurtarma prosedürlerini kullanın.

Proje genelindeki kılavuzları CLAUDE.md dosyasına, tekrarlanabilir prosedürleri becerilere ve belirli dosyalara yönelik talimatları yol kapsamlı kurallara kaydedin. Düzenlemeden sonra biçimlendiriciyi çalıştırmak gibi belirli etkinliklere bağlı eylemler için kancalar kullanın.

Talimatın ne zaman geçerli olması gerektiğine göre seçim yapın:

Bir özelliğe ait gereksinim genellikle CLAUDE.md dosyasında değil, ilgili görev talimatında veya spesifikasyonunda yer alır. Proje genelinde geçerli bir dosyaya geçici talimatlar eklemek, bunların depo genelinde geçerli olması gereken kurallardan ayırt edilmesini zorlaştırır.

Örneğin, projenin test komutunu CLAUDE.md dosyasında tutun, bileşene özgü kuralları yol kapsamlı bir kuralda belirleyin ve tekrarlanan inceleme prosedürünü bir beceri olarak kaydedin. Komutlar veya kurallar değiştiğinde, diğer proje belgelerinde olduğu gibi bu dosyaları da gözden geçirin.

Yönergeler, CLAUDE.md dosyası ve beceriler, Claude’un davranışını yönlendirir; ancak bir talimatın yerine getirileceğini garanti etmezler. Kancalar, yapılandırılmış etkinliklerde denetimler gerçekleştirebilir, ancak güvenilirlikleri kanca türüne ve uygulamasına bağlıdır.

Bir komut kancası bir komut dosyasını çalıştırır. Bir komut istemi veya ajan kancası ise bir modelin kararına dayanır. Anthropic’in en iyi uygulamalar kılavuzunda da açıklandığı gibi: “Bir komut istemi veya ajan kancası, karar vermesini başka bir modelden ister; dolayısıyla bu da deterministik değildir.” Uygulanması gereken bir kural için uygun izin denetimlerini kullanın ve ilgili komut veya HTTP kancasını, hataları nasıl işlediğini de dahil olmak üzere test edin.

Özel alt ajanlar, tekrarlayan işleri düzenlemenin başka bir yoludur. Her uzman talimatını ana oturuma eklemek yerine, farklı bir inceleme rolüne veya araç kapsamına ihtiyaç duyulduğunda in.claude/agents/ içinde bir uzman tanımlayın. İş için en iyi Claude modeli ve yapay zeka ajan türlerine ilişkin bu kılavuzlar ek bilgi sağlar.

Takımınız birkaç farklı AI ürününe ait komutları yönetiyorsa, Claude Code'un ötesinde kütüphaneleri yönetmek için bu komut mühendisliği araçlarına göz atın.

Bir oturumda eksik veya uygun olmayan bir sonuç ortaya çıktığında, isteğin önemli kararları çözülmemiş bırakıp bırakmadığını kontrol edin. Bu beş hata, işin teşhis edilmesini ve gözden geçirilmesini zorlaştırabilir.

“Depoyu incele” komutu, Claude’a hangi dosyaların önemli olduğu veya ne zaman durması gerektiği konusunda çok az yönlendirme sağlar. İsteğe neden olan soruna bir cevap içermeyen, genel bir özet alabilirsiniz.

Anlamanız gereken davranışı veya kararı adlandırın, başlangıç konumunu belirleyin ve beklenen çıktıyı tanımlayın. Örneğin: “Bu uç noktanın izinleri nasıl kontrol ettiğini izleyin ve ilgili fonksiyonları belirtin.” Alt ajanlar kullanıyorsanız, her birine aynı sınırsız aramayı devretmek yerine sınırlı bir soru verin.

Bir özellik, konuyla ilgisiz bir hata ve bir dokümantasyon talebi arasında geçiş yapmak, konuşmada mevcut göreve uymayabilecek bir bağlamın kalmasına neden olur. “O dosya” veya “önceki yaklaşım” gibi referanslar belirsiz hale gelir.

Birbiriyle ilgisi olmayan işler için ayrı oturumlar kullanın. Birden fazla oturumun depoyu düzenleyeceği durumlarda, aynı çalışma dizinini değiştirmemeleri için ayrı Git çalışma ağaçları kullanın. Kısa bir yan soru için, Claude Code’un /btw komutu, bu alışverişi ana konuşma geçmişinin dışında tutar.

Bir özellik hatalı çalışsa bile derleme başarılı olabilir. Bir test paketi, hataya neden olan girdiyi hiç denemediği için başarılı olabilir. Claude’dan “testleri çalıştır” demek, bu testlerin hangi gereksinimi doğruladığını belirlemez.

Kabul kriterlerini belirli kontrollere eşleştirin. Bir hata düzeltmesi için, değişikliğin öncesinde yeniden üretme testinin başarısız olduğunu ve sonrasında başarılı olduğunu gösteren kanıt isteyin. Tek bir başarılı komutu tüm değişikliğin doğrulaması olarak kabul etmek yerine, test edilmemiş kriterlerin görünürlüğünü koruyun.

Genişleyen bir CLAUDE.md dosyası, güncel olmayan komutlar, yinelenen kurallar ve görevle ilgili gereksinimlerle çelişen talimatlar içerebilir. Daha kesin ifadeler eklemek bu çelişkileri çözmez.

Dosyayı mevcut depo ile karşılaştırarak gözden geçirin. Güncelliğini yitirmiş kılavuzları kaldırın, çelişen kuralları netleştirin ve dar kapsamlı talimatları yol kapsamlı kurallara veya becerilere taşıyın. Bir gerekliliğin uygulanması gerekiyorsa, tekrarlanan hatırlatıcılara güvenmek yerine uygun denetimleri yapılandırın ve test edin.

Bir inceleme, gerçek hataları, belirsiz sorunları ve isteğe bağlı yeniden yapılandırma önerilerini bir arada ortaya çıkarabilir. Her öneriyi uygulamak, istenen davranışı iyileştirmeden değişikliği genişletebilir.

Her bulgunun ardındaki kanıtları ve etkilerini sorgulayın. Doğruluk sorunlarına ve karşılanmamış gereksinimlere öncelik verin, belirsiz iddiaları araştırın ve konuyla ilgisi olmayan iyileştirmeleri mevcut fark listesinin dışında tutun. Bir gözden geçiren, kanıtlar bu sonucu desteklediğinde, eyleme geçilmesini gerektiren herhangi bir sorun olmadığını bildirebilmelidir.

Bir şablonu uyarlamak için, şablondaki yer tutucuları projenizdeki ayrıntılarla değiştirin ve değişiklikleri yapmadan önce Claude'un ne yapması gerektiğini belirleyin. İsteği hazırlamak ve sonucu incelemek için bu adımları izleyin.

Küçük ve iyi tanımlanmış bir değişiklik için, Claude'dan bunu doğrudan uygulamasını isteyebilirsiniz. Tanımadığınız kodlar, birden fazla dosyayı etkileyen değişiklikler veya çözülmemiş gereksinimler söz konusu olduğunda ise bir planla başlayın.

Plan modu görünene kadar Shift+Tab tuşlarına basın veya claude --permission-mode plan komutuyla Claude Code'u başlatın. Bu modda Claude, kaynak kodunuzu düzenlemeden dosyaları inceleyebilir ve salt okunur komutları çalıştırabilir. Uygulamayı onaylamadan önce önerilen dosyaları, bağımlılıkları ve testleri inceleyin. Önerilen planı düzenleyicinizde açmak için Ctrl+G tuşlarına basın.

Görevi anlaması için Claude’a gerekli kanıtları sağlayın: bir dosya referansı, temizlenmiş bir hata günlüğü, bir ekran görüntüsü veya bir gereksinim belgesi. @ işaretini ve ardından dosya yolunu kullanarak o dosyanın içeriğini ekleyin.

Kullanışlı olan en küçük kaynak kümesini seçin. Bir günlüğün veya dizinin tamamını dahil etmek, konuyla ilgisiz içerik ekleyebilir ve bağlamı boğabilir. Günlükleri paylaşım öncesinde kimlik bilgilerini ve hassas verileri kaldırın ve Claude'un, sağladığınız dokümantasyon URL'lerini almak için gerekli araçlara sahip olup olmadığını kontrol edin.

Örneğin, `cat error.log | claude -p "Bu hatayı açıkla"` komutu, etkileşimli olmayan bir istekle bir günlüğü gönderir. Bunu yalnızca dosyanın içeriğini kontrol ettikten sonra kullanın. Bağlamsal yapay zekanın pratik değeri budur: modele görevle ilgili bilgileri sağlamak.

Bir özellik eklerken, depoda benzer bir bileşen veya fonksiyon belirleyin. Claude'a API istemcisi, doğrulama mantığı, hata işleme veya test yapısı gibi hangi kurallara uyması gerektiğini belirtin.

“@src/widgets/Weather.tsx dosyasının verileri nasıl aldığı ve önbelleğe kaydettiğini takip edin” ifadesi, Claude’a somut bir referans sağlar. Ayrıca, yeni özelliğin gerektirdiği farklılıkları da belirtin; böylece artık uygun olmayan davranışların kopyalanmasını önleyin. Bu kurallar, takımınızın yazılım geliştirme ş akışını yansıtmalıdır.

Kod değişiklikleri için ilgili test, derleme veya lint komutunu ve kontrol edilmesi gereken davranışı belirtin. Araştırma amacıyla dosya referansları veya commit ID'lerini talep edin. Kullanıcı arayüzü işleri için bir referans görüntü ve uygulamanın aynı görüntü alanında yakalanmasını sağlayacak yapılandırılmış bir yöntem sağlayın.

Claude'dan, hatalar ve atlanan kontroller dahil olmak üzere gerçekte neleri kontrol ettiğini rapor etmesini isteyin. Kanıtların gereksinimi karşılayıp karşılamadığını gözden geçirin; derlemenin başarılı olması, istenen her davranışın işlediğini garanti etmez.

Daha uzun görevler için Claude Code, /hedef koşulu ve Stop kancaları da sunar. Hedef değerlendiricisi, dosyaları bağımsız olarak incelemek veya testler çalıştırmak yerine, konuşma sırasında ortaya çıkan kanıtları değerlendirir. Yapılandırılmış bir Stop kancası, görevin tamamlanmasını engelleyebilir, ancak tekrarlanan engelleme konusunda sınırları vardır. Bunların hiçbiri, uygun testlerin ve insan tarafından yapılan incelemenin yerini almaz.

Tekrarlanan düzeltmeler bir sorunu çözmüyorsa, durun ve orijinal talebin hangi noktaları belirsiz bıraktığını belirleyin. Konuşmayı silmeden önce yararlı bulguları, güncel Git durumunu ve kalan işleri kaydedin.

Anthropic’in en iyi uygulamalar kılavuzu, aynı sorunla ilgili iki başarısız düzeltme denemesinden sonra baştan başlamanızı önerir. /clear komutunu kullanın, ardından öğrendiklerinizi içeren revize edilmiş bir komut girin. Konuşmayı silmek, dosyadaki değişiklikleri geri almaz.

Çalışmakta olan bir yanıtı durdurmak için Esc tuşuna basın. Komut satırı boşken Esc tuşuna iki kez basarak geri sarma menüsünü açın ve geri yüklenecek öğeyi seçin. Geri sarma işlemi tüm harici etkileri geri almaz; bu nedenle, veritabanlarında veya uzak hizmetlerdeki değişiklikler için Git kontrol noktalarını ve ayrı kurtarma prosedürlerini kullanın.

Proje genelindeki kılavuzları CLAUDE.md dosyasına, tekrarlanabilir prosedürleri becerilere ve belirli dosyalara yönelik talimatları yol kapsamlı kurallara kaydedin. Düzenlemeden sonra biçimlendiriciyi çalıştırmak gibi belirli etkinliklere bağlı eylemler için kancalar kullanın.

Talimatın ne zaman geçerli olması gerektiğine göre seçim yapın:

Bir özelliğe ait gereksinim genellikle CLAUDE.md dosyasında değil, ilgili görev talimatında veya spesifikasyonunda yer alır. Proje genelinde geçerli bir dosyaya geçici talimatlar eklemek, bunların depo genelinde geçerli olması gereken kurallardan ayırt edilmesini zorlaştırır.

Örneğin, projenin test komutunu CLAUDE.md dosyasında tutun, bileşene özgü kuralları yol kapsamlı bir kuralda belirleyin ve tekrarlanan inceleme prosedürünü bir beceri olarak kaydedin. Komutlar veya kurallar değiştiğinde, diğer proje belgelerinde olduğu gibi bu dosyaları da gözden geçirin.

Yönergeler, CLAUDE.md dosyası ve beceriler, Claude’un davranışını yönlendirir; ancak bir talimatın yerine getirileceğini garanti etmezler. Kancalar, yapılandırılmış etkinliklerde denetimler gerçekleştirebilir, ancak güvenilirlikleri kanca türüne ve uygulamasına bağlıdır.

Bir komut kancası bir komut dosyasını çalıştırır. Bir komut istemi veya ajan kancası ise bir modelin kararına dayanır. Anthropic’in en iyi uygulamalar kılavuzunda da açıklandığı gibi: “Bir komut istemi veya ajan kancası, karar vermesini başka bir modelden ister; dolayısıyla bu da deterministik değildir.” Uygulanması gereken bir kural için uygun izin denetimlerini kullanın ve ilgili komut veya HTTP kancasını, hataları nasıl işlediğini de dahil olmak üzere test edin.

Özel alt ajanlar, tekrarlayan işleri düzenlemenin başka bir yoludur. Her uzman talimatını ana oturuma eklemek yerine, farklı bir inceleme rolüne veya araç kapsamına ihtiyaç duyulduğunda in.claude/agents/ içinde bir uzman tanımlayın. İş için en iyi Claude modeli ve yapay zeka ajan türleri hakkındaki bu kılavuzlar ek bilgi sağlar.

Takımınız birkaç farklı AI ürününe yayılmış komutlar kullanıyorsa, Claude Code'un ötesinde kütüphaneleri yönetmek için bu komut mühendisliği araçlarına göz atın.

Bir oturumda eksik veya uygun olmayan bir sonuç ortaya çıktığında, isteğin önemli kararları çözülmemiş bırakıp bırakmadığını kontrol edin. Bu beş hata, işin teşhis edilmesini ve gözden geçirilmesini zorlaştırabilir.

“Depoyu incele” komutu, Claude’a hangi dosyaların önemli olduğu veya ne zaman durması gerektiği konusunda çok az yönlendirme sağlar. İsteğe neden olan soruna bir cevap içermeyen, genel bir özet alabilirsiniz.

Anlamanız gereken davranışı veya kararı adlandırın, başlangıç konumunu belirleyin ve beklenen çıktıyı tanımlayın. Örneğin: “Bu uç noktanın izinleri nasıl kontrol ettiğini izleyin ve ilgili fonksiyonları belirtin.” Alt ajanlar kullanıyorsanız, her birine aynı sınırsız aramayı devretmek yerine sınırlı bir soru verin.

Bir özellik, konuyla ilgisi olmayan bir hata ve bir dokümantasyon talebi arasında geçiş yapmak, konuşmada mevcut göreve uymayabilecek bir bağlam bırakır. “O dosya” veya “önceki yaklaşım” gibi referanslar belirsiz hale gelir.

Birbiriyle ilgisi olmayan işler için ayrı oturumlar kullanın. Birden fazla oturumun depoyu düzenleyeceği durumlarda, aynı çalışma dizinini değiştirmemeleri için ayrı Git çalışma ağaçları kullanın. Kısa bir yan soru için, Claude Code’un /btw komutu, bu alışverişi ana konuşma geçmişinin dışında tutar.

Bir özellik hatalı çalışsa bile derleme başarılı olabilir. Bir test paketi, hataya neden olan girdiyi hiç denemediği için başarılı olabilir. Claude’dan “testleri çalıştır” demek, bu testlerin hangi gereksinimi doğruladığını belirlemez.

Kabul kriterlerini belirli kontrollere eşleştirin. Bir hata düzeltmesi için, değişikliğin öncesinde yeniden üretme testinin başarısız olduğunu ve sonrasında başarılı olduğunu gösteren kanıt isteyin. Tek bir başarılı komutu tüm değişikliğin doğrulaması olarak kabul etmek yerine, test edilmemiş kriterlerin görünürlüğünü koruyun.

Genişleyen bir CLAUDE.md dosyası, güncel olmayan komutlar, yinelenen kurallar ve görevle ilgili gereksinimlerle çelişen talimatlar içerebilir. Daha kesin ifadeler eklemek bu çelişkileri çözmez.

Dosyayı mevcut depo ile karşılaştırarak gözden geçirin. Güncelliğini yitirmiş kılavuzları kaldırın, çelişen kuralları netleştirin ve dar kapsamlı talimatları yol kapsamlı kurallara veya becerilere taşıyın. Bir gerekliliğin uygulanması gerekiyorsa, tekrarlanan hatırlatıcılara güvenmek yerine uygun denetimleri yapılandırın ve test edin.

Bir inceleme, gerçek hataları, belirsiz sorunları ve isteğe bağlı yeniden yapılandırma önerilerini bir arada ortaya çıkarabilir. Her öneriyi uygulamak, istenen davranışı iyileştirmeden değişikliği genişletebilir.

Her bulgunun ardındaki kanıtları ve etkilerini sorgulayın. Doğruluk sorunlarına ve karşılanmamış gereksinimlere öncelik verin, belirsiz iddiaları araştırın ve konuyla ilgisi olmayan iyileştirmeleri mevcut fark listesinin dışında tutun. Bir gözden geçiren, kanıtlar bu sonucu desteklediğinde, eyleme geçilmesini gerektiren herhangi bir sorun olmadığını bildirebilmelidir.

Bir şablonu uyarlamak için, şablondaki yer tutucuları projenizdeki ayrıntılarla değiştirin ve değişiklikleri yapmadan önce Claude'un ne yapması gerektiğini belirleyin. İsteği hazırlamak ve sonucu incelemek için bu adımları izleyin.

Küçük ve iyi tanımlanmış bir değişiklik için, Claude'dan bunu doğrudan uygulamasını isteyebilirsiniz. Tanımadığınız kodlar, birden fazla dosyayı etkileyen değişiklikler veya çözülmemiş gereksinimler söz konusu olduğunda ise bir planla başlayın.

Plan modu görünene kadar Shift+Tab tuşlarına basın veya claude --permission-mode plan komutuyla Claude Code'u başlatın. Bu modda Claude, kaynak kodunuzu düzenlemeden dosyaları inceleyebilir ve salt okunur komutları çalıştırabilir. Uygulamayı onaylamadan önce önerilen dosyaları, bağımlılıkları ve testleri inceleyin. Önerilen planı düzenleyicinizde açmak için Ctrl+G tuşlarına basın.

Görevi anlaması için Claude’a gerekli kanıtları sağlayın: bir dosya referansı, temizlenmiş bir hata günlüğü, bir ekran görüntüsü veya bir gereksinim belgesi. @ işaretini ve ardından dosya yolunu kullanarak o dosyanın içeriğini ekleyin.

Kullanışlı olan en küçük kaynak kümesini seçin. Bir günlüğün veya dizinin tamamını dahil etmek, konuyla ilgisiz içerik ekleyebilir ve bağlamı boğabilir. Günlüklerin paylaşımı öncesinde kimlik bilgilerini ve hassas verileri kaldırın ve Claude'un, sağladığınız dokümantasyon URL'lerini almak için gerekli araçlara sahip olup olmadığını kontrol edin.

Örneğin, `cat hata.log | claude -p "Bu hatayı açıkla"` komutu, etkileşimli olmayan bir istekle bir günlüğü gönderir. Bunu yalnızca dosyanın içeriğini kontrol ettikten sonra kullanın. Bağlamsal yapay zekanın pratik değeri budur: modele görevle ilgili bilgileri sağlamak.

Bir özellik eklerken, depoda benzer bir bileşen veya fonksiyon belirleyin. Claude'a API istemcisi, doğrulama mantığı, hata işleme veya test yapısı gibi hangi kurallara uyması gerektiğini belirtin.

“@src/widgets/Weather.tsx dosyasının verileri nasıl aldığı ve önbelleğe kaydettiğini takip edin” ifadesi, Claude’a somut bir referans sağlar. Ayrıca, yeni özelliğin gerektirdiği farklılıkları da belirtin; böylece artık uygun olmayan davranışların kopyalanmasını önleyin. Bu kurallar, takımınızın yazılım geliştirme ş akışını yansıtmalıdır.

Kod değişiklikleri için ilgili test, derleme veya lint komutunu ve kontrol edilmesi gereken davranışı belirtin. Araştırma amacıyla dosya referansları veya commit ID'lerini talep edin. Kullanıcı arayüzü işleri için bir referans görüntü ve uygulamanın aynı görüntü alanında yakalanmasını sağlayacak yapılandırılmış bir yöntem sağlayın.

Claude'dan, hatalar ve atlanan kontroller dahil olmak üzere gerçekte neleri kontrol ettiğini rapor etmesini isteyin. Kanıtların gereksinimi karşılayıp karşılamadığını gözden geçirin; derlemenin başarılı olması, istenen her davranışın işlediğini garanti etmez.

Daha uzun görevler için Claude Code, /goal koşulu ve Stop kancaları da sunar. Hedef değerlendiricisi, dosyaları bağımsız olarak incelemek veya testler çalıştırmak yerine, konuşma sırasında ortaya çıkan kanıtları değerlendirir. Yapılandırılmış bir Stop kancası, görevin tamamlanmasını engelleyebilir, ancak tekrarlanan engelleme konusunda sınırlamaları vardır. Bunların hiçbiri, uygun testlerin ve insan tarafından yapılan incelemenin yerini almaz.

Tekrarlanan düzeltmeler bir sorunu çözmüyorsa, durun ve orijinal talebin hangi noktaları belirsiz bıraktığını belirleyin. Konuşmayı silmeden önce yararlı bulguları, güncel Git durumunu ve kalan işleri kaydedin.

Anthropic’in en iyi uygulamalar kılavuzu, aynı sorunla ilgili iki başarısız düzeltme denemesinden sonra baştan başlamanızı önerir. /clear komutunu kullanın, ardından öğrendiklerinizi içeren revize edilmiş bir komut girin. Konuşmayı silmek, dosyadaki değişiklikleri geri almaz.

Çalışmakta olan bir yanıtı durdurmak için Esc tuşuna basın. Komut satırı boşken Esc tuşuna iki kez basarak geri sarma menüsünü açın ve geri yüklenecek öğeyi seçin. Geri sarma işlemi tüm harici etkileri geri almaz; bu nedenle, veritabanlarında veya uzak hizmetlerdeki değişiklikler için Git kontrol noktalarını ve ayrı kurtarma prosedürlerini kullanın.

Proje genelindeki kılavuzları CLAUDE.md dosyasına, tekrarlanabilir prosedürleri becerilere ve belirli dosyalara yönelik talimatları yol kapsamlı kurallara kaydedin. Düzenlemeden sonra biçimlendiriciyi çalıştırmak gibi belirli etkinliklere bağlı eylemler için kancaları kullanın.

Talimatın ne zaman geçerli olması gerektiğine göre seçim yapın:

Bir özelliğe ait gereksinim genellikle CLAUDE.md dosyasında değil, ilgili görev talimatında veya spesifikasyonunda yer alır. Proje genelinde geçerli bir dosyaya geçici talimatlar eklemek, bunların depo genelinde geçerli olması gereken kurallardan ayırt edilmesini zorlaştırır.

Örnek olarak, projenin test komutunu CLAUDE.md dosyasında tutun, bileşene özgü kuralları yol kapsamlı bir kuralda belirleyin ve tekrarlanan inceleme prosedürünü bir beceri olarak kaydedin. Komutlar veya kurallar değiştiğinde, diğer proje belgelerinde olduğu gibi bu dosyaları da gözden geçirin.

Yönergeler, CLAUDE.md dosyası ve beceriler, Claude’un davranışını yönlendirir; ancak bir talimatın yerine getirileceğini garanti etmezler. Kancalar, yapılandırılmış etkinliklerde denetimler gerçekleştirebilir, ancak güvenilirlikleri kanca türüne ve uygulamasına bağlıdır.

Bir komut kancası bir komut dosyasını çalıştırır. Bir komut istemi veya ajan kancası ise bir modelin kararına dayanır. Anthropic’in en iyi uygulamalar kılavuzunda da açıklandığı gibi: “Bir komut istemi veya ajan kancası, karar vermesini başka bir modelden ister; dolayısıyla bu da deterministik değildir.” Uygulanması gereken bir kural için uygun izin denetimlerini kullanın ve ilgili komut veya HTTP kancasını, hataları nasıl işlediğini de dahil olmak üzere test edin.

Özel alt ajanlar, tekrarlayan işleri düzenlemenin başka bir yoludur. Her uzman talimatını ana oturuma eklemek yerine, farklı bir inceleme rolüne veya araç kapsamına ihtiyaç duyulduğunda in.claude/agents/ içinde bir uzman tanımlayın. İş için en iyi Claude modeli ve yapay zeka ajan türleri hakkındaki bu kılavuzlar ek bilgi sağlar.

Takımınız birkaç farklı AI ürününe ait komutları yönetiyorsa, Claude Code'un ötesinde kütüphaneleri yönetmek için bu komut mühendisliği araçlarına göz atın.

Bir oturumda eksik veya uygun olmayan bir sonuç ortaya çıktığında, isteğin önemli kararları çözülmemiş bırakıp bırakmadığını kontrol edin. Bu beş hata, işin teşhis edilmesini ve gözden geçirilmesini zorlaştırabilir.

“Depoyu incele” komutu, Claude’a hangi dosyaların önemli olduğu veya ne zaman durması gerektiği konusunda çok az yönlendirme sağlar. İsteğe neden olan soruna bir cevap içermeyen, genel bir özet alabilirsiniz.

Anlamanız gereken davranışı veya kararı adlandırın, başlangıç konumunu belirleyin ve beklenen çıktıyı tanımlayın. Örneğin: “Bu uç noktanın izinleri nasıl kontrol ettiğini izleyin ve ilgili fonksiyonları belirtin.” Alt ajanlar kullanıyorsanız, aynı sınırsız aramayı devretmek yerine her birine sınırlı bir soru verin.

Bir özellik, konuyla ilgisi olmayan bir hata ve bir dokümantasyon talebi arasında geçiş yapmak, konuşmada mevcut göreve uymayabilecek bir bağlam bırakır. “O dosya” veya “önceki yaklaşım” gibi referanslar belirsiz hale gelir.

Birbiriyle ilgisi olmayan işler için ayrı oturumlar kullanın. Birden fazla oturumun depoyu düzenleyeceği durumlarda, aynı çalışma dizinini değiştirmemeleri için ayrı Git çalışma ağaçları kullanın. Kısa bir yan soru için, Claude Code’un /btw komutu, bu alışverişi ana konuşma geçmişinin dışında tutar.

Bir özellik hatalı çalışsa bile derleme başarılı olabilir. Bir test paketi, hataya neden olan girdiyi hiç denemediği için başarılı olabilir. Claude’dan “testleri çalıştır” demek, bu testlerin hangi gereksinimi doğruladığını belirlemez.

Kabul kriterlerini belirli kontrollere eşleştirin. Bir hata düzeltmesi için, değişikliğin öncesinde yeniden üretme testinin başarısız olduğunu ve sonrasında başarılı olduğunu gösteren kanıt isteyin. Tek bir başarılı komutu tüm değişikliğin doğrulaması olarak kabul etmek yerine, test edilmemiş kriterlerin görünürlüğünü koruyun.

Genişleyen bir CLAUDE.md dosyası, güncel olmayan komutlar, yinelenen kurallar ve görevle ilgili gereksinimlerle çelişen talimatlar içerebilir. Daha kesin ifadeler eklemek bu çelişkileri çözmez.

Dosyayı mevcut depo ile karşılaştırarak gözden geçirin. Güncelliğini yitirmiş kılavuzları kaldırın, çelişen kuralları netleştirin ve dar kapsamlı talimatları yol kapsamlı kurallara veya becerilere taşıyın. Bir gerekliliğin uygulanması gerekiyorsa, tekrarlanan hatırlatıcılara güvenmek yerine uygun denetimleri yapılandırın ve test edin.

Bir inceleme, gerçek hataları, belirsiz sorunları ve isteğe bağlı yeniden yapılandırma önerilerini bir arada ortaya çıkarabilir. Her öneriyi uygulamak, istenen davranışı iyileştirmeden değişikliği genişletebilir.

Her bulgunun ardındaki kanıtları ve etkilerini sorgulayın. Doğruluk sorunlarına ve karşılanmamış gereksinimlere öncelik verin, belirsiz iddiaları araştırın ve konuyla ilgisi olmayan iyileştirmeleri mevcut fark listesinin dışında tutun. Bir gözden geçiren, kanıtlar bu sonucu desteklediğinde, eyleme geçilmesini gerektiren herhangi bir bulgu olmadığını bildirebilmelidir.