Slash Commands'tan Skills'e: Ne Zaman ve Nasıl Geçmeli

Önceki üç yazı slash command'in tüm kullanımını anlattı: Markdown dosyasından !command enjeksiyonuna, oradan da subagent ve MCP orkestrasyonuna kadar. Bu içeriklerin hiçbiri eskimedi—ama perde arkasında resmi taraf bir birleşme yaptı: custom commands artık Skills'in içinde.

.claude/commands/review.md dosyan hâlâ çalışıyor, /review hâlâ kullanılabilir, hiçbir şeyi değiştirmen gerekmiyor. Ama bu command'in daha fazla yetenek kazanmasını istiyorsan (birden fazla dosya, fork'ta çalıştırma, path'e göre otomatik aktivasyon), yeni yol .claude/skills/review/SKILL.md. Bu yazı iki şeyi netleştiriyor: nasıl göç ettirilir ve göç etmeye değer mi.

Minimum göç: tek bir path'i değiştir, gerisine dokunma

Resmi uyumluluk sözü net: .claude/commands/deploy.md ve .claude/skills/deploy/SKILL.md ikisi de /deploy olarak kaydolur, işlevleri tamamen aynıdır. Aynı isim çakıştığında skills öncelikli olur.

Minimum göç adımları:

cd .claude/commands
mkdir -p ../skills/review
mv review.md ../skills/review/SKILL.md

Dosya içeriğinde tek bir satır bile değişmez. YAML frontmatter, !`command`, @file, $ARGUMENTS—hepsi uyumlu.

Ama sadece bu kadarını yaparsan okur soracak: o zaman neden göç ettik? Cevap şu: skill dizini birden çok dosya barındırabilir, command ise sadece bir.

Neden göç etmeli: SKILL.md'nin getirdiği dört şey

1. Destek dosyaları: uzun belgeleri ayırmak

SKILL.md giriş noktası, aynı dizine istediğin kadar yan dosya koyabilirsin. Şöyle bir yapı düşün:

.claude/skills/review/
├── SKILL.md            # giriş noktası, kısa talimat + referanslar
├── checklist.md        # uzun code review checklist'i
├── examples/
│   └── good-diff.md    # iyi örnek
└── scripts/
    └── lint.sh         # SKILL.md'nin çağırabileceği script

SKILL.md içinde göreli path ile referans veriyorsun:

Mevcut diff'i [checklist.md](checklist.md) içindeki standartlara göre gözden geçir.
Beklenen çıktı formatı için [examples/good-diff.md](examples/good-diff.md) dosyasına bak.

Bu destek dosyaları otomatik olarak context'e girmez—Claude ihtiyaç duydukça okur. Resmi öneri SKILL.md'yi 500 satırın altında tutmak, geri kalanını destek dosyalarına taşımak yönünde.

2. `disable-model-invocation`: hangi skill sadece elle tetiklenir

Varsayılan olarak Claude uygun bir an gördüğünde herhangi bir skill'i kendi başına çağırabilir. Bu, /deploy, /commit, /send-email gibi yan etkisi olan command'ler için tehlikeli—Claude'un "kodu iyi gördüm, deploy edeyim" demesini istemezsin.

---
name: deploy
description: Production'a deploy et
disable-model-invocation: true
allowed-tools: Bash(kamal deploy:*), Bash(git push:*)
---

Bu satırı ekledikten sonra /deploy yalnızca senin elle tetiklemenle çalışır, Claude konuşma sırasında kafasına göre çağırmaz.

Tersi olan user-invocable: false ise "yalnızca Claude çağırabilir ama / menüsünde görünmez" demek—arka plan bilgisi niteliğindeki skill'ler için uygundur (mesela legacy-system-context: ilgili senaryolarda Claude otomatik yükler, senin elle tetiklemen bir anlam ifade etmez).

3. `context: fork`: skill'i alt ajan içinde çalıştırmak

En büyük yükseltme bu. Önceki yazıda command'in allowed-tools: Task ile modele subagent açtırabileceğini anlatmıştık—ama prompt'un içinde "Explore subagent'ı aç ve şunu yap..." diye elle tarif etmen gerekiyordu.

SKILL bunu frontmatter'da tek satırla çözüyor:

---
name: deep-research
description: Bir sembolü derinlemesine araştır
context: fork
agent: Explore
---

$ARGUMENTS'in tüm kullanımlarını araştır:
- Tüm çağrı noktaları
- İş senaryoları
- Alternatif implementasyonlar

≤300 kelimelik özet döndür.

/deep-research SomeClass tetiklendiğinde: tüm SKILL.md bağımsız bir subagent'ın prompt'una dönüşür, Explore agent type ile çalışır, iş bitince yalnızca sonucu döndürür. Ana konuşmanın context'i tertemiz kalır.

Yani "subagent açmak" işi prompt içindeki metin tariflerinden çıkıp skill'in deklaratif bir özelliğine dönüşmüş oluyor.

4. `paths`: dosya tipine göre otomatik aktivasyon

---
name: rails-conventions
description: Rails projesi için kodlama kuralları
paths: ["app/**/*.rb", "config/**/*.rb"]
---

Bu projenin Rails konvansiyonlarına uy:
- Fat controller yerine service object kullan
- ActiveRecord scope'ları adlandırılmış olmalı
...

app/models/user.rb dosyasını düzenlerken bu skill otomatik olarak context'e eklenir; package.json düzenlerken eklenmez. Global CLAUDE.md'den çok daha isabetli—"path'e göre katmanlara bölünmüş CLAUDE.md" gibi düşün.

Uygulama: `/plan`'i skill'e yükseltmek

Önceki yazının sonundaki /plan örneği tek dosyalı bir command'di:

.claude/commands/plan.md

Skill'e yükseltirsek:

.claude/skills/plan/
├── SKILL.md
├── research-prompt.md     # subagent 1'in talimatı
└── risk-prompt.md         # subagent 2'nin talimatı

SKILL.md:

---
name: plan
description: Linear ticket'a göre uygulama planı üret
disable-model-invocation: true
allowed-tools: mcp__linear__*, Task, Read, Grep, Bash(git log:*)
---

## Context

@.claude/context/architecture.md

## Durum

!`git log --oneline -10`

## Görev

$ARGUMENTS Linear ticket'ının açıklama ve yorumlarını çek.

Task ile iki subagent'ı paralel çalıştır:
1. Kod araştırması: prompt için [research-prompt.md](research-prompt.md)
2. Risk değerlendirmesi: prompt için [risk-prompt.md](risk-prompt.md)

İki sonucu birleştirip uygulama adımları + risk listesi + commit granülerlik önerisi çıkar.

İki subagent'ın prompt'u ayrı dosyalarda; bakım sırasında tek bir yeri değiştirirsin, SKILL.md'ye dokunmana gerek kalmaz. Skill'in kendisi 30 satırdan az kalır temiz şekilde, destek dosyaları da ayrı ayrı yüzlerce satır detaylı olabilir.

Eğer subagent'ları kendin yönlendirmek istemiyorsan daha radikal olabilirsin—tüm skill'i fork'un içine at, Explore agent tek seferde çalıştırsın:

---
name: plan
context: fork
agent: Explore
allowed-tools: mcp__linear__*
---

/plan ENG-4213 tetiklenir → bağımsız context'teki Explore agent tüm SKILL.md içeriğini görev olarak devralır → yalnızca nihai planı döndürür. Ana konuşma hiç kirlenmez.

Hangi durumda göç etmeye gerek yok

Her command yükseltilmeyi hak etmez. .claude/commands/'de kalması daha uygun olan durumlar:

Tek Markdown yeter: ayrılması gereken checklist, examples, scripts yok
Fork gereksiz: görev ana konuşmayla derinden bağlantılı, tüm geçmişi görmesi gerekiyor
Path'e göre otomatik aktivasyona gerek yok: kullanıcı zaten elle tetikliyor
Erişim kontrolüne gerek yok: Claude kendi kendine çağırsa da sorun çıkmaz

Basit /commit, /pr-desc gibi şeyler zaten bir frontmatter ve birkaç satır prompt'tan ibaret—.claude/commands/ içinde durmaları çok daha sezgisel. Resmi taraf açıkça söyledi: iki biçim de yan yana yaşayacak, hiçbiri deprecate olmayacak.

Birlikte var olma tablosu

Şu an .claude/'un en temiz organizasyonu:

.claude/
├── commands/           # hafif: tek dosya + basit prompt
│   ├── commit.md
│   └── pr-desc.md
├── skills/             # ağır: çok dosya / fork / yetki kontrolü
│   ├── plan/
│   │   ├── SKILL.md
│   │   ├── research-prompt.md
│   │   └── risk-prompt.md
│   ├── deploy/
│   │   └── SKILL.md    # disable-model-invocation
│   └── rails-conventions/
│       └── SKILL.md    # paths glob ile otomatik aktivasyon
└── context/
    └── coding-standards.md

Her şeyi toptan göç ettirme. Göçün tetikleyici koşulu "bu command şişmeye başladı"—içerik 200 satırı aşıyor, dokümanı bölmek gerekiyor, subagent'ta çalıştırmak istiyorsun. O zaman path'i değiştirirsin, birkaç dakikalık iş.

Özet

İstenen yetenek	`commands/`	`skills/`
Tek dosya prompt kısayolu	✅	✅
!`command` / `@file` / `$ARGUMENTS`	✅	✅
`allowed-tools` ile yetki kontrolü	✅	✅
Destek dosyaları (reference, scripts)	❌	✅
`disable-model-invocation` yanlış tetiklenmeye karşı	❌	✅
`context: fork` + `agent:` izole çalıştırma	❌	✅
`paths:` glob ile path bazlı otomatik aktivasyon	❌	✅

İlk üç madde commands ve skills'te tamamen eşdeğer; son dört madde skills'e özgü. İhtiyacın olana başvur, olmayana dokunma.

Resmi yön skills'e doğru eğiliyor ama commands/ için uyumluluk sözü çok net—bu, "hemen göç et yoksa elenirsin" türünde bir değişiklik değil, "yeni yetenekleri sana veriyoruz ama dayatmıyoruz" türünden bir genişleme. Farkları kavra, ihtiyaca göre göç et, biçimsel düzen uğruna boşuna uğraşma.