Claude Code tarafında “Skills” özelliğini ilk gördüğümde, açık konuşayım, ben de bunun biraz süslenmiş bir prompt katmanı olduğunu sandım. Hani, bir klasöre birkaç talimat koyuyorsun ve model onları okuyor — tamam işte, bitti gibi duruyor. Ama biraz kurcalayınca işin asıl numarasının bambaşka bir yerde yattığını fark ettim: mesele ne yazdığın değil, o bilginin tam olarak ne zaman devreye girdiği.
Tuhaf ama, İşin aslı şu. Büyük dil modelleriyle çalışırken en pahalı şey çoğu zaman token değil… kafa karışıklığı. Geçen ay İstanbul’da bir ekip toplantısında tam da bunu konuştuk; herkes aynı projede, aynı yönergeleri defalarca yapıştırıyordu ve sohbet şiştikçe kalite de gözle görülür biçimde düşüyordu — tıpkı masaya kağıt yığdıkça önemli notu kaybetmen gibi, yani klasik bir düzen problemi (evet, doğru duydunuz). Claude’un Skills yaklaşımı tam burada ilginçleşiyor. Bağlamı baştan boca etmek yerine, gerektiğinde çağrılan küçük ama hedefli bilgi paketleri kuruyorsun.
Skill fikri neden bu kadar dikkat çekiyor?
Şöyle bir şey var. Bir LLM’e sürekli uzun promptlar vermek kısa vadede rahat hissettiriyor; “her şeyi anlattım ya, sorun kalmaz” diyorsun. Gel gelelim birkaç gün sonra aynı yönergeyi yeniden kopyala-yapıştır yaparken kendini buluyorsun. Üstelik bağlam penceresi doldukça modelin odağı da dağılıyor.
Ciddi fark var.
Claude’daki Skill mantığı bu dağınıklığı biraz toparlıyor. Model her şeyi en başta okumak zorunda kalmıyor; bir görev geldiğinde uygun skill’i seçip onun içindeki talimatları kullanıyor. Bu bana 2023’te Ankara’da yaptığım bir danışmanlık işini hatırlattı — ekip, kod inceleme için tek bir dev doküman tutuyordu ve doküman o kadar uzamıştı ki kimse son sürümü gerçekten okumuyordu. Küçük parçalara bölünseydi çok daha temiz olurdu, bu kadar basit.
Bir de şu var: Skills yalnızca “talimat depolama” değil, tetikleme mantığı getiriyor. “Şu işi görünce bunu aç” diyorsun yani. Bu baya iş görüyor çünkü modelle konuşurken her seferinde aynı açıklamayı tekrarlamak zorunda kalmıyorsun.
Klasik prompt ile Skill arasındaki fark
Bir şey dikkatimi çekti: Klasik prompt yaklaşımı şöyle çalışır: kullanıcı ne istiyorsa onu uzun uzun anlatır, ardından model bu metnin içinden anlam çıkarmaya uğraşır. Skill ise daha derli toplu bir düzen kuruyor — görev tanımı ayrı, içerik ayrı. Birisi sana yol tarifi veriyor gibi düşün; diğeriyse cebinde hazır duran küçük harita (buna dikkat edin). Hangisi daha işe yarar? Duruma göre değişiyor tabii ama uzun yolculuklarda haritayı tercih ederim.
Aşağıdaki tabloyu editör masasındayken not aldım; baya sade ama fikri iyi anlatıyor:
| Yaklaşım | Ne yapar? | Zayıf yani |
|---|---|---|
| Uzun prompt | Tüm talimatı tek seferde verir | Bağlamı şişirir, tekrar eder |
| Skill | Tetiklenince ilgili bilgiyi yükler | İlk kurulum biraz emek ister |
| Karma yapı | Kritik işleri skill’e bırakır | Düzgün bakım yapılmazsa karışabilir |
Burası kritik: asıl mesele bağlam tasarımı
Claude Skills’in bana göre en güçlü tarafı şu ayrımda yatıyor: “ne zaman kullanılır?” ile “içinde ne var?” sorularını birbirinden ayırıyor (şaşırtıcı ama gerçek). Kulağa teorik geliyor, biliyorum. Ama pratikte çok şey değiştiriyor. Çünkü iyi bir AI sistemi kurmak sadece akıllı komut yazmak değil; bilgiyi tam doğru anda masaya getirmek demek.
Skills’in gerçek gücü, modeli daha fazla konuşturmakta değil; doğru zamanda doğru bilgiyi çağırmakta yatıyor.
Bunu kendi testimde net gördüm. Geçen hafta Kadıköy’de küçük bir deneme yaptım; kod inceleme için basit bir skill hazırladım. Ona proje standartlarını ekledim. Normalde review sırasında aynı üç kuralı yeniden anlatmam gerekiyordu: isimlendirme tutarlılığı, hata yönetimi. Test kapsamı. Skill devreye girince bu tekrar azaldı (evet, doğru duydunuz). ama tamamen kaybolmadı. Çünkü hâlâ iyi tanımlanmış tetikleyici cümlelere ihtiyaç var. Sihir yok; düzgün tasarım var.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Burada ufak bir hayal kırıklığı da söyleyeyim. Her şey otomatikmiş gibi pazarlanabiliyor — öyle değil (kendi tecrübem). Skill’in adı güzel olsa bile açıklaması muğlaksa model yanlış yere gidebiliyor ya da hiç kullanmayabiliyor. Maalesef. Bu konuyla ilgili Çifte Ücretleri Bitiren Tasarım: Billing’de Üç… yazımıza da göz atmanızı tavsiye ederim.
Nerede işe yarar?
- Kod inceleme standartları için
- Ekip içi commit mesaj formatları için
- Debug checklist’leri için
- Sık tekrarlanan proje kuralları için
- Müşteri destek yanıtlarında ton rehberi için
Tuhaf ama, Küçük bir startup’ta çalışıyorsan Skills sana özellikle hız kazandırabilir — ekip küçüktür. Tekrar eden işler boldur, garip ama gerçek. Kurumsal tarafta ise fayda başka yerde çıkar: farklı ekiplerin aynı standarda göre üretim yapmasını sağlamak, işte asıl güç orada.
Peki nasıl çalışıyor? Basit anlatayım
Size bir şey söyleyeyim, Tamam, şimdi gelelim pratik kısma. Bir skill temelde küçük bir paket gibi düşünülebilir: içinde ne olduğunu biliyorsun ama onu her an açmıyorsun. Kullanıcı isteği geldiğinde sistem eşleştirme yapıyor ve uygun olan paketi devreye sokuyor. Basit ama etkili. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
.claude/skills/code-review/SKILL.md
---
name: code-review
description: Değişen dosyalarda kod incelemesi yapar
---
# Talimatlar
- Kod stilini kontrol et
- Hata olasılıklarını ara
- Test eksiklerini belirt
- Güvenlik risklerine bak
Bence burada önemli nokta şu: skill sadece metin değil, bir düzen fikri de veriyor. Bilgiye nereden bakacağını biliyorsun (klasör), ne zaman kullanılacağını tanımlıyorsun (açıklama), nasıl davranacağını söylüyorsun (talimatlar). Bu üçlü bir araya gelince ortaya basit görünen ama gerçekten işe yarayan bir yapı çıkıyor.
Bunu biraz açayım. Bu konuyla ilgili Linux 7.0 Geldi: Numara Değişti, Asıl Hikâye Başka yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için neden ile ilgili önceki yazımız yazımıza bakabilirsiniz.
Sınıflandırma meselesi göz ardı edilmemeli
Açıkçası, Trigger kısmını kötü yazarsan bütün sistem tökezler. Burada frene basmak lazım çünkü insanlar içerikten çok açıklamayı önemsemiyor — halbuki anahtar tam da orada. “Review modified files” ifadesi ile “check my code” arasında davranış farkı oluşabiliyor mesela. Bu yüzden skill isimlerini fazla yaratıcı yapmak yerine anlaşılır tutmak çok daha mantıklı görünüyor.
Kendi deneyimimden konuşuyorum, Peki neden?
Çünkü model seni okuyucu gözüyle değil, tetikleyici eşleştirme mantığıyla dinliyor (evet, doğru duydunuz). Bunu kavrayınca her şey yerine oturuyor zaten.
Küçük ekip mi büyük organizasyon mu?
Küçük startup senaryosunda avantaj çok net: az kişi, çok görev, bol tekrar (ciddiyim). Bir geliştirici hem ürün yazıyor hem test ediyor hem de deploy tarafına bakıyorsa — ki bunu bizzat yaşadım, inanılmaz yorucu — skills ciddi vakit kazandırabilir. Mesela de ortak kalite kuralları oluşturmak isteyen ekiplerde, tek tek prompt düzeltmek yerine merkezi skill tanımlamak baya rahatlatıcı oluyor.
Şimdi, kurumsal tarafta ise oyun biraz değişiyor. Mesele hızdan çok kontrol. Enterprise seviyede kişisel skills, proje skills’i, hatta plugin tabanlı katmanlar arasında öncelik sırası önem kazanıyor. Benzer yapıyı geçen yıl Maslak’ta büyük bir finans ekibinde gördüm; farklı takımların çakışan yönergeleri yüzünden review çıktıları birbirine benzemiyordu. Kimse bunun neden böyle olduğunu tam açıklayamıyordu. Böyle ortamlarda bağlam tasarımı neredeyse yönetişim konusu oluyor.
Ve işler burada ilginçleşiyor.
Şunu da dürüstçe söyleyeyim: enterprise ortamda esneklik azalabiliyor. Merkezi standart iyi güzel ama bazen geliştiricinin elini bağlıyor. Kağıt üstünde süper, pratikte göreceğiz; çünkü fazla katman bazen otomasyonu hızlandırmaktan çok yavaşlatabiliyor. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Neden sadece daha iyi prompt yazmıyoruz?
Şunu fark ettim: Çünkü problem yalnızca yazının kalitesi değil, ölçek meselesi. Bir iki görevde harika çalışan uzun promptlar onuncu tekrarda can sıkmaya başlıyor. Üstelik modelin ihtiyacı olmayan (söylemesi ayıp) bilgiyle de dolup taşıyor — yani balyozla vida sıkmaya benziyor biraz. Açık konuşayım, herkes bunu sevmez (ciddiyim)
Skills burada daha temiz bir mimari sunuyor: tekrar eden işleri sınıflandır, tetiklemesini ayır, gereksiz bağlam yükünü azalt. Hatta bazı durumlarda bunu spesifik projelerde commit mesaj standardına kadar indirebilirsin. Mesela benim kendi not defterimde “release-note” diye minicik bir akış var; sıradan görünür ama haftalık iş yükünde ciddi fark yaratıyor. Neyse uzatmayalım, fikir basit: düzen eşittir hafiflik.
Bana göre artılar ve eksiler hangileri?
- Artılar: Tekrarlı işleri azaltır, odak sağlar, ölçeklenebilirlik verir.
- Eksi yanlar: Kötü tanımlanırsa yanlış tetiklenir, ilk kurulum zahmetlidir.
- Nötr alan: Her sorun çözülmez; bazı işler hâlâ manuel yorum ister.
Bence en sağlıklı kullanım şekli hibrit yaklaşım. Kritik bilgi skill içinde dursun, genel yönlendirme ise kısa promptlarla gelsin. Böylece ne aşırı şişkinlik oluyor ne de sistem körleşiyor. Ha bu arada — iyi test edilmemiş hiçbir AI katmanından mucize beklememeli; bu konuda yüzde yüz emin değilim ama sahada gördüğüm tablo hep böyleydi.
Sıkça Sorulan Sorular
CClaude Skills tam olarak nedir?
Claude Skills, belirli görevler için hazırlanmış talimat ve kaynak klasörleridir. Model uygun isteği görünce bunları kullanabilir. Amaç her seferinde uzun prompt yazmayı azaltmaktır.
Pprompt yerine neden Skill kullanmalıyım?
Pprompt işe yarar ama tekrar ettikçe ağırlaşır. Skill ise bilgiyi modüler hale getirir ve bağlam penceresini daha temiz tutar. Bilhassa sık yinelenen işlerde faydası belirgin olur.
Kküçük ekipler için gerçekten gerekli mi?
Evet, çoğu zaman gerekli olur. Küçük ekiplerde bile aynı kuralların sürekli tekrarlanması vakit kaybettirir. Basit birkaç skill bile günlük akışı toparlayabilir.
Eenterprise ortamda en büyük risk nedir?
En büyük risk aşırı karmaşıklıktır. Çok fazla katman varsa hangi skill’in ne zaman devreye girdiğini takip etmek zorlaşır. Bu yüzden isimlendirme ve öncelik sırası net olmalı.
Kaynaklar ve İleri Okuma
Anthropic Claude Code Skills Dokümantasyonu
Küçük bir detay: Claude Code GitHub Sayfası
Anthropic Resmi Blog / Duyurular
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
