Beceri Yaratıcı ile Otomatik Claude Kod Becerileri Nasıl Oluşturulur

TL;DR

Claude Code Becerileri, Claude'un belirli iş akışları için işlevselliğini genişleten özel yeteneklerdir. Beceri Oluşturucu sistemi, beceri oluşturmayı yapılandırılmış bir süreçle otomatikleştirir: becerinizin amacını tanımlayın, SKILL.md dosyasını taslağını oluşturun, test senaryoları oluşturun, nicel ölçütlerle değerlendirmeler yapın ve geri bildirimlere dayanarak yinelemeli olarak geliştirin.

Giriş

Claude Code'u her gün kullanıyorsunuz. Kendinizi aynı sıraları tekrarlarken buluyorsunuz: proje yapılarını kurmak, belirli test komutlarını çalıştırmak, çıktıları belirli bir şekilde biçimlendirmek. Her seferinde iş akışını baştan açıklıyorsunuz. Claude hatırlasa ne olurdu? Bu iş akışını bir kez yakalayıp sonsuza kadar kullanılabilir hale getirebilseydiniz? Claude Code Becerileri işte bunu yapar. Bunlar, Claude'un işlevselliğini kendi özel iş akışlarınız için genişletmek üzere oluşturduğunuz özel yeteneklerdir. Ve Beceri Oluşturucu ile süreç otomatik ve sistematiktir.

Bu kılavuz size tüm süreci anlatmaktadır. Beceri anatomisini, oluşturma iş akışını, değerlendirme sistemini ve güvenilir tetikleme için nasıl optimize edeceğinizi öğreneceksiniz. Resmi Anthropic beceri deposundan çalışan örnekleri göreceksiniz.

💡

API ile ilgili beceriler geliştiriyorsanız, Apidog doğal olarak entegre olur. API uç noktalarınızı test edin, yanıtları doğrulayın ve tüm bunları tek bir beceri iş akışı içinde belgeleyin.

düğme

Claude Code Becerileri Nelerdir?

Claude Code Becerileri, Claude'un belirli alanlar veya iş akışları için yeteneklerini genişleten özel talimat setleridir. Bunları markdown dosyalarında yaşayan özel eklentiler olarak düşünebilirsiniz.

Beceri Sistemi Mimarisi

Beceriler üç seviyeli bir yükleme sistemi kullanır:

Meta Veri (~100 kelime) - Ad ve açıklama, her zaman bağlamda
SKILL.md gövdesi (<500 satır) - Temel talimatlar, beceri tetiklendiğinde yüklenir
Paketlenmiş kaynaklar (sınırsız) - Komut dosyaları, referanslar, isteğe bağlı olarak yüklenen varlıklar

skill-name/
├── SKILL.md (gerekli)
│   ├── YAML frontmatter (ad, açıklama)
│   └── Markdown talimatları
└── Bundled Resources (isteğe bağlı)
    ├── scripts/    - Tekrarlayan görevler için yürütülebilir kod
    ├── references/ - İhtiyaç halinde yüklenen belgeler
    └── assets/     - Şablonlar, simgeler, yazı tipleri

Beceriler Ne Zaman Tetiklenir

Beceriler, Claude'un available_skills listesinde adları ve açıklamalarıyla birlikte görünür. Claude, bir beceriye danışıp danışmayacağına bu açıklamaya göre karar verir.

Önemli: Beceriler yalnızca Claude'un doğrudan halledemediği görevler için tetiklenir. "Bu dosyayı oku" gibi basit sorgular, eşleşen bir açıklama olsa bile bir beceriyi tetiklemez. Karmaşık, çok adımlı iş akışları, açıklama eşleştiğinde güvenilir bir şekilde tetiklenir.

Anthropic Deposundaki Gerçek Dünya Örnekleri

Beceri	Amaç	Temel Özellikler
beceri-oluşturucu	Yeni beceriler oluştur	Test senaryosu oluşturma, kıyaslama değerlendirmesi, açıklama optimizasyonu
mcp-oluşturucu	MCP sunucuları oluştur	Python/Node şablonları, değerlendirme çerçevesi, en iyi uygulamalar
docx	Word belgeleri oluştur	python-docx komut dosyaları, şablon sistemi, stil kılavuzu
pdf	PDF'leri çıkar ve manipüle et	Form işleme, metin çıkarma, referans belgeleri
ön uç tasarım	Web arayüzleri oluştur	Bileşen kütüphanesi, Tailwind desenleri, erişilebilirlik kontrolleri

Beceri Oluşturma İş Akışı

Beceri oluşturma süreci sistematik bir döngüyü takip eder:

Amacı yakala - Beceri ne yapmalı?
Bir taslak yaz - SKILL.md dosyasını oluştur
Test senaryoları oluştur - Gerçekçi istemler tanımla
Değerlendirmeleri çalıştır - Becerili ve becerisiz olarak yürüt
Sonuçları gözden geçir - Niteliksel geri bildirim + nicel metrikler
Yinele - Bulgulara dayanarak geliştir
Açıklamayı optimize et - Tetikleme doğruluğunu en üst düzeye çıkar
Paketle - Bir .skill dosyası olarak dağıt

Her adımı inceleyelim.

Adım 1: Amacı Yakala

Becerinin neyi başarmasını istediğinizi anlayarak başlayın. Eğer zaten yapmakta olduğunuz bir iş akışını yakalıyorsanız, konuşma geçmişinizden deseni çıkarın.

Şu dört soruyu sorun:

Bu beceri Claude'a neyi yapma yeteneği kazandırmalıdır? Sonuç konusunda net olun.
Bu beceri ne zaman tetiklenmelidir? Hangi kullanıcı ifadeleri veya bağlamlarda?
Beklenen çıktı formatı nedir? Dosyalar, kod, raporlar?
Test senaryoları kurmalı mıyız? Doğrulanabilir çıktılara sahip beceriler (kod oluşturma, veri çıkarma, dosya dönüştürme) test senaryolarından faydalanır. Öznel çıktılara sahip beceriler (yazım stili, tasarım) genellikle bunlara ihtiyaç duymaz.

Örnek: API Test Becerisi

Amaç: Geliştiricilerin REST API'lerini sistematik olarak test etmesine yardımcı olmak
Tetikleme: Kullanıcı API testi, uç noktalar, REST, GraphQL'den bahsettiğinde veya yanıtları doğrulamak istediğinde
Çıktı: Geçti/kaldı durumu, curl komutları, yanıt karşılaştırmaları içeren test raporları
Test senaryoları: Evet - çıktılar nesnel olarak doğrulanabilir

Adım 2: SKILL.md Dosyasını Yazın

Her beceri, YAML ön bilgi ve markdown talimatları içeren bir SKILL.md dosyasıyla başlar.

Beceri Anatomisi

---
name: api-tester
description: REST API'lerini sistematik olarak nasıl test edeceğinizi açıklar. Kullanıcılar API testi, uç noktalar, REST, GraphQL'den bahsettiğinde veya API yanıtlarını doğrulamak istediğinde kullanın. Testle ilgili olduğu her durumda, bu beceriyi önermeyi unutmayın.
compatibility: curl veya HTTP istemci araçları gerektirir
---

# API Test Uzmanı Becerisi

## Temel İş Akışı

Bir API test edilirken şu adımları izleyin:

1. **Uç noktayı anlayın** - Spesifikasyonu okuyun veya şemayı isteyin
2. **Test senaryoları tasarlayın** - Olumlu senaryo, uç durumlar, hata koşulları
3. **Testleri yürütün** - İstekler için curl veya Apidog kullanın
4. **Yanıtları doğrulayın** - Durum kodlarını, başlıkları, gövde yapısını kontrol edin
5. **Sonuçları raporlayın** - Geçti/kaldı özetini kanıtlarla birlikte sunun

## Test Senaryosu Şablonu

Her uç nokta için şunları test edin:

- Doğru yük ile geçerli kimlik doğrulama
- Eksik gerekli alanlarla geçerli kimlik doğrulama
- Geçersiz kimlik doğrulama (401 bekleniyor)
- Hız sınırlama davranışı
- Yük altında yanıt süresi

## Çıktı Formatı

Raporları her zaman şu şekilde yapılandırın:

# API Test Raporu

## Özet
- Çalıştırılan testler: X
- Başarılı: Y
- Başarısız: Z

## Başarısız Testler

### Test Adı
**Beklenen:** 200 OK
**Gerçekleşen:** 400 Bad Request
**Yanıt:** {...}

## Öneriler
...

En İyi Yazım Uygulamaları

Aşamalı açıklama kullanın: SKILL.md'yi 500 satırın altında tutun. Ayrıntılı referansları ayrı dosyalara taşıyın.

api-tester/
├── SKILL.md (iş akışı genel bakışı)
└── references/
    ├── authentication.md
    ├── rate-limiting.md
    └── response-codes.md

Nedenini açıklayın: Sadece kuralları listelemeyin. Neden önemli olduklarını açıklayın.

## Neden hata durumlarını önce test ederiz

Hata durumlarını olumlu senaryolardan önce test etmek, sorunların %80'ini daha hızlı yakalar.
Kimlik doğrulama sessizce başarısız olduğunda, olumlu senaryo testleri anlamsız hale gelir.
401 kontrolüyle başlayın.

Emir kipini kullanın: "Her zaman önce durum kodunu doğrulayın" değil "Durum kodunu doğrulamalısınız..."

Örnekler ekleyin: Girişi ve beklenen çıktıyı gösterin.

## Commit mesajı formatı

**Örnek:**
Giriş: JWT belirteçleriyle kullanıcı kimlik doğrulaması eklendi
Çıktı: feat(auth): JWT tabanlı kimlik doğrulaması uygula

Adım 3: Test Senaryoları Oluşturun

Beceri taslağını hazırladıktan sonra, 2-3 gerçekçi test istemi oluşturun. Bunlar, gerçek bir kullanıcının yapacağı türden isteklerdir.

Test Senaryosu Formatı

Test senaryolarını evals/evals.json dosyasına kaydedin:

{
  "skill_name": "api-tester",
  "evals": [
    {
      "id": 1,
      "prompt": "api.example.com adresindeki /users uç noktasını test edin - bir Bearer belirteci gerektiriyor ve id, ad, e-posta alanlarına sahip bir kullanıcı listesi döndürüyor",
      "expected_output": "Kimlik doğrulama hatası, başarı ve sayfalama testlerini içeren en az 5 test senaryosu içeren test raporu",
      "files": []
    },
    {
      "id": 2,
      "prompt": "Yeni POST /orders uç noktamızın geçersiz miktarları doğru şekilde işlediğini doğrulamam gerekiyor",
      "expected_output": "Negatif, sıfır ve sayısal olmayan miktarları uygun hata yanıtlarıyla gönderen test senaryoları",
      "files": ["openapi.yaml"]
    }
  ]
}

İyi Bir Test İstemini Ne Oluşturur?

Kötü: "Bu API'yi test et"

İyi: "ekibim yeni ödemeler uç noktasını https://api.stripe.com/v1/charges adresine dağıttı ve uç durumları nasıl ele aldığını doğrulamam gerekiyor - özellikle negatif bir miktar veya mevcut olmayan bir para birimi kodu gönderdiğinizde ne olduğunu. Belgelerde 400 dönmesi gerektiği yazıyor ama gerçek hata mesajlarını görmek istiyorum"

İyi bir test istemi şunları içerir:

Belirli URL
Somut senaryo
Beklenen davranış
Gerçek dünya bağlamı

Çalıştırmadan önce test senaryolarınızı kullanıcıyla paylaşın: "Denemek istediğim birkaç test senaryosu var. Bunlar uygun görünüyor mu, yoksa daha fazlasını eklemek ister misiniz?"

Adım 4: Değerlendirmeleri Çalıştırın

Beceri Oluşturucu burada parlıyor. Her test senaryosunu iki kez çalıştıracaksınız: bir kez beceriyle, bir kez de beceri olmadan (veya mevcut bir beceriyi geliştiriyorsanız eski sürümüyle).

Çalışma Alanı Yapısı

Sonuçlar, beceri dizininin bir eşdeğeri olarak <skill-name>-workspace/ içine gider:

api-tester-workspace/
├── iteration-1/
│   ├── eval-0-auth-failure/
│   │   ├── with_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   ├── without_skill/
│   │   │   ├── outputs/
│   │   │   └── timing.json
│   │   └── eval_metadata.json
│   ├── eval-1-pagination/
│   │   └── ...
│   ├── benchmark.json
│   └── benchmark.md
├── iteration-2/
└── feedback.json

Paralel Çalıştırmaları Başlatın

Her test senaryosu için, aynı turda iki alt temsilci oluşturun:

Becerili çalıştırma:

Bu görevi yürüt:
- Beceri yolu: /path/to/api-tester
- Görev: api.example.com adresindeki /users uç noktasını test edin
- Giriş dosyaları: yok
- Çıktıları şuraya kaydet: api-tester-workspace/iteration-1/eval-0/with_skill/outputs/

Temel çalıştırma:

Bu görevi yürüt:
- Beceri yolu: (yok)
- Görev: api.example.com adresindeki /users uç noktasını test edin
- Giriş dosyaları: yok
- Çıktıları şuraya kaydet: api-tester-workspace/iteration-1/eval-0/without_skill/outputs/

Zamanlama Verilerini Yakalayın

Her alt temsilci tamamlandığında, total_tokens ve duration_ms alırsınız. Hemen timing.json dosyasına kaydedin:

{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

Bu veriler yalnızca görev bildirimi aracılığıyla gelir. Her birini geldiği gibi işleyin.

Adım 5: Çalıştırmalar Tamamlanırken İddiaları Taslağını Oluşturun

Sadece çalıştırmaların bitmesini beklemeyin. Bu zamanı, nicel iddiaların taslağını oluşturarak verimli bir şekilde kullanın.

İyi Bir İddiayı Ne Oluşturur?

İyi iddialar şunlardır:

Nesnel olarak doğrulanabilir - Geçti/kaldı belirsiz değildir
Tanımlayıcı olarak adlandırılmış - Ne kontrol edildiği açık
Yeniden kullanılabilir - Yinelemeler arasında çalışır

API test becerisi için örnek iddialar:

{
  "assertions": [
    {
      "name": "includes_auth_failure_test",
      "description": "Test raporu en az bir kimlik doğrulama hatası test senaryosu içerir",
      "type": "contains",
      "value": "401"
    },
    {
      "name": "includes_success_test",
      "description": "Test raporu en az bir başarılı istek testi içerir",
      "type": "contains",
      "value": "200"
    },
    {
      "name": "includes_curl_commands",
      "description": "Her test senaryosu yürütülebilir curl komutları içerir",
      "type": "regex",
      "value": "curl -"
    },
    {
      "name": "includes_response_validation",
      "description": "Rapor, yanıt yapısını şemaya göre doğrular",
      "type": "contains",
      "value": "schema"
    }
  ]
}

Taslakları oluşturulduktan sonra eval_metadata.json ve evals/evals.json dosyalarını iddialarla güncelleyin.

Adım 6: Not Ver ve Topla

Tüm çalıştırmalar tamamlandığında:

Her Çalıştırmaya Not Ver

agents/grader.md dosyasını okuyan ve her bir iddiayı çıktılara göre değerlendiren bir derecelendirici alt temsilci oluşturun. Sonuçları her çalıştırma dizinindeki grading.json dosyasına kaydedin:

{
  "eval_id": 0,
  "grading": [
    {
      "text": "includes_auth_failure_test",
      "passed": true,
      "evidence": "Test senaryosu 3'te 401 durum kodu bulundu"
    },
    {
      "text": "includes_curl_commands",
      "passed": true,
      "evidence": "Test senaryosu 1'de 'curl -X POST' bulundu"
    }
  ]
}

Önemli: grading.json beklenti dizisi text, passed ve evidence alan adlarını kullanmalıdır. Görüntüleyici bu tam adlara bağlıdır.

Kıyaslamaya Dahil Et

Birleştirme komut dosyasını beceri-oluşturucu dizininden çalıştırın:

python -m scripts.aggregate_benchmark api-tester-workspace/iteration-1 --skill-name api-tester

Bu, her yapılandırma için geçme oranı, süre ve jetonları içeren benchmark.json ve benchmark.md dosyalarını, ortalama ± standart sapma ve delta dahil olmak üzere üretir.

Bir Analist Kontrolü Yapın

Kıyaslama verilerini okuyun ve desenleri ortaya çıkarın:

Ayırt edici olmayan iddialar - Beceriden bağımsız olarak her zaman geçer (faydalı değil)
Yüksek varyanslı değerlendirmeler - Muhtemelen kararsız, araştırma gerektirir
Süre/jeton dengeleri - Beceri, makul bir maliyetle kaliteyi artırır mı?

Ayrıntılı rehberlik için agents/analyzer.md dosyasına bakın.

Adım 7: Değerlendirme Görüntüleyicisini Başlatın

Değerlendirme görüntüleyicisi, hem niteliksel çıktıları hem de nicel metrikleri bir tarayıcı arayüzünde gösterir.

Görüntüleyiciyi Oluşturun

nohup python /path/to/skill-creator/eval-viewer/generate_review.py \
  api-tester-workspace/iteration-1 \
  --skill-name "api-tester" \
  --benchmark api-tester-workspace/iteration-1/benchmark.json \
  > /dev/null 2>&1 &
VIEWER_PID=$!

2. yineleme ve sonrası için, ayrıca --previous-workspace parametresini geçirin:

--previous-workspace api-tester-workspace/iteration-1

Kullanıcının Gördükleri

Çıktılar sekmesi, her seferinde bir test senaryosu gösterir:

İstem - Verilen görev
Çıktı - Üretilen dosyalar, satır içinde işlenmiş
Önceki Çıktı (2. yineleme ve sonrası) - Son yinelemenin çıktısını içeren daraltılmış bölüm
Resmi Notlar - Daraltılmış iddia geçti/kaldı
Geri Bildirim - Yazdıkça otomatik kaydolan metin kutusu
Önceki Geri Bildirim (2. yineleme ve sonrası) - Son yinelemeden gelen yorumlar

Kıyaslama sekmesi şunları gösterir:

Her yapılandırma için geçme oranları
Zamanlama karşılaştırmaları
Jeton kullanımı
Değerlendirme başına dökümler
Analist gözlemleri

Kullanıcıya söyleyin: "Sonuçları tarayıcınızda açtım. İki sekme var - 'Çıktılar' her test senaryosuna tıklamanıza ve geri bildirim bırakmanıza olanak tanır, 'Kıyaslama' nicel karşılaştırmayı gösterir. İşiniz bittiğinde buraya geri gelin ve bana bildirin."

Ortak Çalışma / Başsız Ortamlar

Eğer webbrowser.open() mevcut değilse, bağımsız bir HTML dosyası yazmak için --static kullanın:

--static /path/to/output/review.html

Kullanıcı "Tüm İncelemeleri Gönder"e tıkladığında geri bildirim feedback.json olarak indirilir.

Adım 8: Geri Bildirimleri Oku ve Yinele

Kullanıcı bitirdiğinde, feedback.json dosyasını okuyun:

{
  "reviews": [
    {
      "run_id": "eval-0-with_skill",
      "feedback": "grafikte eksen etiketleri eksik",
      "timestamp": "2026-03-23T10:30:00Z"
    },
    {
      "run_id": "eval-1-with_skill",
      "feedback": "",
      "timestamp": "2026-03-23T10:31:00Z"
    },
    {
      "run_id": "eval-2-with_skill",
      "feedback": "mükemmel, çok beğendim",
      "timestamp": "2026-03-23T10:32:00Z"
    }
  ],
  "status": "complete"
}

Boş geri bildirim, kullanıcının bunun iyi olduğunu düşündüğü anlamına gelir. İyileştirmeleri belirli şikayetleri olan test senaryolarına odaklayın.

İyileştirmeler Hakkında Nasıl Düşünmeli?

Geri bildirimden genelleştirin: Birçok istemde binlerce kez kullanılan beceriler yaratıyorsunuz. Belirli test senaryolarına aşırı uymayın. İnatçı bir sorun varsa, kısıtlayıcı ZORUNLULUK ifadeleri yerine farklı metaforlar veya desenler deneyin.

İstemi yalın tutun: İş görmeyen kısımları kaldırın. Sadece nihai çıktıları değil, transkriptleri de okuyun. Eğer beceri, modelin üretken olmayan adımlarda zaman kaybetmesine neden oluyorsa, bu kısımları kaldırın.

Nedenini açıklayın: Büyük Dil Modelleri (LLM'ler) iyi bir zihin teorisine sahiptir. İyi bir çerçeve verildiğinde, ezbere talimatların ötesine geçerler. Her gereksinimin neden önemli olduğunu açıklayın. Eğer kendinizi her zaman veya asla büyük harflerle yazarken buluyorsanız, bunun yerine yeniden ifade edin ve gerekçeyi açıklayın.

Tekrarlayan işleri arayın: Tüm test senaryoları bağımsız olarak benzer yardımcı komut dosyaları mı yazdı? Bu, becerinin o komut dosyasını paketlemesi gerektiğinin bir işaretidir. Bir kez yazın, scripts/ içine koyun ve beceriye kullanmasını söyleyin.

Yineleme Döngüsü

Beceriye iyileştirmeler uygulayın
Tüm test senaryolarını iteration-<N+1>/ içine temel çalıştırmalarla yeniden çalıştırın
Görüntüleyiciyi, önceki yinelemeyi işaret eden --previous-workspace ile başlatın
Kullanıcı incelemesini bekleyin
Yeni geri bildirimleri okuyun, tekrar geliştirin, tekrarlayın

Şunlar olana kadar devam edin:

Kullanıcı memnun olduğunu söyler
Tüm geri bildirimler boş (her şey yolunda görünüyor)
Anlamlı bir ilerleme kaydedemiyorsunuz

İşiniz bittiğinde görüntüleyiciyi kapatın:

kill $VIEWER_PID 2>/dev/null

Adım 9: Beceri Açıklamasını Optimize Edin

SKILL.md ön bilgisindeki açıklama alanı, birincil tetikleme mekanizmasıdır. Bir beceri oluşturduktan veya geliştirdikten sonra, daha iyi tetikleme doğruluğu için onu optimize edin.

Tetikleyici Değerlendirme Sorguları Oluşturun

20 değerlendirme sorgusu oluşturun - tetiklemesi gereken ve tetiklememesi gerekenlerin bir karışımı:

[
  {
    "query": "patronum bana bu xlsx dosyasını gönderdi (indirilenlerde, 'Q4 satışları son SON v2.xlsx' gibi bir şey) ve bana kar marjını yüzde olarak gösteren bir sütun eklememi istiyor. Gelir C sütununda, maliyetler ise D sütununda sanırım",
    "should_trigger": true
  },
  {
    "query": "Bu CSV'den bir özet tablo oluşturup ekibe e-posta ile göndermem gerekiyor",
    "should_trigger": false
  }
]

Tetiklemesi gereken sorgular için (8-10):

Aynı amacın farklı ifadeleri
Resmi ve gündelik dil
Kullanıcıların beceriyi açıkça adlandırmadığı ancak açıkça ihtiyaç duyduğu durumlar
Uç durumlar ve yaygın olmayan kullanım durumları

Tetiklememesi gereken sorgular için (8-10):

Anahtar kelimeleri paylaşan ancak farklı bir şeye ihtiyaç duyan yakın kaçırmalar
Başka bir aracın daha uygun olduğu bitişik alanlar
Basit anahtar kelime eşleşmesinin yanlış tetikleyeceği belirsiz ifadeler

Kötü negatif testler: Bir PDF becerisi için negatif test olarak "Bir fibonacci fonksiyonu yaz" çok kolaydır. Negatif durumlar gerçekten zorlayıcı olmalıdır.

Kullanıcıyla Gözden Geçirme

Değerlendirme setini HTML şablonunu kullanarak sunun:

assets/eval_review.html dosyasını okuyun
Yer tutucuları değerlendirme verileri, beceri adı ve açıklamasıyla değiştirin
Geçici dosyaya yazın ve açın: open /tmp/eval_review_api-tester.html
Kullanıcı sorguları düzenleyebilir, tetiklemeli/tetiklememeli durumunu değiştirebilir, girişleri ekleyip kaldırabilir
Kullanıcı "Değerlendirme Setini Dışa Aktar"a tıklar
Dosya ~/Downloads/eval_set.json konumuna indirilir

Bu adım önemlidir. Kötü değerlendirme sorguları, kötü açıklamalara yol açar.

Optimizasyon Döngüsünü Çalıştırın

python -m scripts.run_loop \
  --eval-set /path/to/trigger-eval.json \
  --skill-path /path/to/api-tester \
  --model claude-sonnet-4-6 \
  --max-iterations 5 \
  --verbose

Geçerli oturumunuzu güçlendiren model kimliğini kullanın, böylece tetikleme testleri kullanıcı deneyimiyle eşleşir.

Komut dosyası:

Değerlendirme setini %60 eğitim, %40 tutulan test olarak böler
Mevcut açıklamayı değerlendirir (güvenilirlik için her biri 3 çalıştırma)
Hatalara dayanarak iyileştirmeler önermek için Claude'u çağırır
Eğitim ve test üzerinde yeniden değerlendirir
5 kez tekrarlar
Test puanıyla seçilen best_description değerini döndürür (aşırı uydurmayı önlemek için eğitim puanı değil)

Sonucu Uygula

JSON çıktısındaki best_description değerini alın ve becerinin SKILL.md ön bilgisini güncelleyin. Kullanıcıya skorlarla birlikte öncesi/sonrası gösterin.

Öncesi:

description: REST API'lerini sistematik olarak nasıl test edeceğinizi açıklar

Sonrası:

description: REST API'lerini sistematik olarak nasıl test edeceğinizi açıklar. Kullanıcılar API testi, uç noktalar, REST, GraphQL'den bahsettiğinde veya API yanıtlarını doğrulamak istediğinde kullanın. Testle ilgili olduğu her durumda, açıkça 'test' kelimesini belirtmeseler bile bu beceriyi önermeyi unutmayın.

Adım 10: Paketle ve Dağıt

Beceri tamamlandığında, dağıtım için paketleyin:

python -m scripts.package_skill /path/to/api-tester

Bu, kullanıcıların yükleyebileceği bir .skill dosyası oluşturur. Kullanıcıları sonuçtaki dosya yoluna yönlendirin.

Kurulum

Kullanıcılar becerileri, .skill dosyasını beceriler dizinlerine yerleştirerek veya Claude Code beceri yükleme komutunu kullanarak kurarlar.

Yaygın Beceri Oluşturma Hataları

Hata 1: Belirsiz Açıklama

Kötü:

description: API'lerle çalışmak için bir beceri

İyi:

description: REST API'lerini sistematik olarak nasıl test edeceğinizi açıklar. Kullanıcılar API testi, uç noktalar, REST, GraphQL'den bahsettiğinde veya API yanıtlarını doğrulamak istediğinde kullanın. Testle ilgili olduğu her durumda, açıkça 'test' kelimesini belirtmeseler bile bu beceriyi önermeyi unutmayın.

Hata 2: Aşırı Kısıtlayıcı Talimatlar

Kötü:

HER ZAMAN bu tam formatı kullanın. ASLA sapmayın. Bu bölümleri İÇERMELİDİR.

İyi:

Bu formatı kullanın çünkü paydaşların ihtiyaç duydukları bilgiyi hızlı bir şekilde bulmasını sağlar. Hedef kitlenizin farklı ihtiyaçları varsa, yapıyı buna göre uyarlayın.

Hata 3: Test Senaryolarını Atlamak

Test senaryoları, kullanıcılar sorunlarla karşılaşmadan önce onları yakalar. Öznel beceriler için bile, çıktı kalitesini doğrulamak için 2-3 örnek çalıştırın.

Hata 4: Zamanlama Verilerini Göz Ardı Etmek

10 kat daha uzun süren beceriler sürdürülebilir değildir. Zamanlama verilerini yakalayın ve kaliteyle birlikte verimlilik için optimize edin.

Hata 5: Tekrarlayan Komut Dosyalarını Paketlememek

Eğer her test çalıştırması bağımsız olarak bir generate_report.py yazıyorsa, onu beceriye dahil edin. Bu, zaman kazandırır ve tutarlılık sağlar.

Gerçek Dünya Beceri Örnekleri

MCP Oluşturucu Becerisi

Anthropic tarafından MCP (Model Bağlam Protokolü) sunucuları oluşturmak için geliştirilmiştir.

Temel özellikler:

Python ve Node.js şablonları
MCP sunucuları için değerlendirme çerçevesi
En iyi uygulamalar referans belgeleri

Yapı:

mcp-builder/
├── SKILL.md
├── reference/
│   ├── mcp_best_practices.md
│   ├── python_mcp_server.md
│   └── node_mcp_server.md
└── evaluation/
    └── evaluation.md

Docx Becerisi

Word belgelerini programlı olarak oluşturur.

Temel özellikler:

Paketlenmiş python-docx komut dosyaları
Yaygın belgeler için şablon sistemi
Tutarlı biçimlendirme için stil kılavuzu

İş akışı:

Belge gereksinimlerini anlayın
Şablonu seçin veya oluşturun
python-docx komut dosyası aracılığıyla oluşturun
Çıktı yapısını doğrulayın

Ön Uç Tasarım Becerisi

Modern desenlerle web arayüzleri oluşturur.

Temel özellikler:

Bileşen kütüphanesi
Tailwind CSS desenleri
Erişilebilirlik kontrolleri

Aşamalı açıklama: SKILL.md'de temel iş akışı, references/ içinde bileşen belgeleri.

Becerinizi Apidog ile Test Etme

API ile ilgili beceriler geliştiriyorsanız, Apidog iş akışına doğal olarak entegre olur.

Örnek: API Test Becerisi Entegrasyonu

## API Testlerini Çalıştırma

Sistematik test için Apidog kullanın:

1. OpenAPI spesifikasyonunu Apidog'a aktarın
2. Spesifikasyondan test senaryoları oluşturun
3. Testleri çalıştırın ve sonuçları JSON olarak dışa aktarın
4. Yanıtları beklenen şemalara göre doğrulayın

Özel iddialar için Apidog'un komut dosyası özelliğini kullanın.

Apidog Komut Dosyalarını Paketle

api-tester/
├── SKILL.md
└── scripts/
    ├── run-apidog-tests.py
    └── generate-report.py

Bu, gelecekteki her çağrıyı tekerleği yeniden icat etmekten kurtarır.

Sonuç

Claude Code Becerileri, Claude'un yeteneklerini özel iş akışlarınız için genişletir. Beceri Oluşturucu sistemi sistematik bir süreç sunar:

Amacı yakala - Becerinin ne yapması gerektiğini tanımla
SKILL.md taslağını oluştur - Örneklerle açık talimatlar yaz
Test senaryoları oluştur - Kullanıcıların gerçekten yapacağı gerçekçi istemler
Değerlendirmeleri çalıştır - Becerili ve becerisiz paralel yürütme
Sonuçları gözden geçir - Niteliksel geri bildirim + nicel kıyaslamalar
Yinele - Bulgulara dayanarak geliştir
Açıklamayı optimize et - Tetikleme doğruluğunu en üst düzeye çıkar
Paketle - .skill dosyası olarak dağıt

düğme

SSS

Bir beceri oluşturmak ne kadar sürer?

Basit beceriler 15-30 dakika sürer. Birden çok referans dosyası ve paketlenmiş komut dosyaları olan karmaşık beceriler, değerlendirme yinelemeleri dahil 2-3 saat sürebilir.

Her beceri için test senaryoları yazmam gerekiyor mu?

Hayır. Nesnel olarak doğrulanabilir çıktılara sahip beceriler (kod oluşturma, dosya dönüştürme, veri çıkarma) test senaryolarından faydalanır. Öznel çıktılara sahip beceriler (yazım stili, tasarım kalitesi) niteliksel olarak daha iyi değerlendirilir.

Becerim güvenilir bir şekilde tetiklenmezse ne olur?

Açıklama alanını optimize edin. Belirli tetikleme ifadeleri ve bağlamları ekleyin. Biraz "ısrarcı" olun - becerinin ne zaman kullanılacağını açıkça belirtin. 20 değerlendirme sorgusuyla açıklama optimizasyon döngüsünü çalıştırın.

Becerileri ekibimle nasıl paylaşırım?

Beceriyi python -m scripts.package_skill <yol> ile paketleyin, ardından .skill dosyasını dağıtın. Ekip üyeleri bu dosyayı beceri dizinlerine yerleştirir.

Beceriler harici API'leri çağırabilir mi?

Evet. API çağrıları yapan komut dosyalarını paketleyin. Beceri talimatları, Claude'a bunları ne zaman ve nasıl kullanacağını söyler. API anahtarlarını becerinin kendisinde değil, ortam değişkenlerinde saklayın.

Beceriler için dosya boyutu sınırı nedir?

Kesin bir sınır yoktur, ancak SKILL.md'yi 500 satırın altında tutun. Ayrıntılı referansları ayrı dosyalara taşıyın. Komut dosyaları ve varlıklar, isteğe bağlı yüklendikleri için satır sınırlamasına dahil değildir.

Mevcut bir beceriyi nasıl güncellerim?

Yüklü beceriyi yazılabilir bir konuma kopyalayın, orada düzenleyin ve yeniden paketleyin. Orijinal adı koruyun - farklı bir varyant oluşturmuyorsanız sürüm son ekleri eklemeyin.