Skills Skill (Skill Dokümantasyonunu Yönetmek)

Bu skill, .claude/skills/*/SKILL.md altındaki skill dokümantasyonunu yönetme sürecini açıklar.

Amaç, gelecekteki LLM düzenlemeleri doğru, uygulanabilir ve repoya dayalı kalmasını sağlamaktır (vibes değil).

Hızlı Başlangıç

Herhangi bir skill güncellerken:

1. Modülün "kaynak-gerçeği" dokümantasyonunu bulun (README/tasarım notları).
2. İddiaları doğrudan kodda doğrulayın (giriş noktaları + değişmez-zorlayan dosyalar).
3. Yanlış yollar/API'ler/testleri repoda arayarak düzeltin.
4. Bu repoda gerçekten çalışan küçük bir ## Quick Start ekleyin/güncelleyin.
5. Frontmatter ve referans edilen yolları doğrulayın.

"İyi" Neye Benzer

İyi bir skill dokü:

• Spesifik: kesin dosyaları ve gerçek giriş noktalarını gösterir.
• Değişmez-yönelimli: kod tarafından zorlanan doğruluk kurallarını dokümante eder (aspirasyonel tasarım değil).
• Çalıştırılabilir: Quick Start kod parçacıkları derlenebilir/içe aktarılabilir (veya en azından mevcut API yüzeyiyle eşleşir).
• İzlenebilir: herhangi bir açık olmayan iddia, repodaki bir dosya yoluna izlenebilir.

Standart İş Akışı (Kaynak-Gerçeği Birincil)

1) Skill'in kapsamını envanter yapın

• Modül sınırını (dizinler, paketler) ve anahtar tüketicileri tanımlayın ("çağrı siteleri").
• Bellek yerine rg kullanmayı tercih edin: içe aktarımları, giriş noktalarını ve anahtar sınıf/fonksiyonları arayın.

2) Dokları okuyun, sonra değişmezleri zorlayan kodu okuyun

Bu hiyerarşiyi kullanın:

1. Bir modül README/tasarım dokümanı (varsa)
2. Reponun geri kalanı tarafından kullanılan runtime giriş noktaları
3. Değişmezleri zorlayan dosyalar (doğru kalması gereken yerler)
4. Davranışı kodifiye eden testler

Örnekler:

• Solver: src/faebryk/core/solver/README.md + src/faebryk/core/solver/symbolic/invariants.py
• Graph: src/faebryk/core/zig/src/graph/graph.zig + src/faebryk/core/zig/src/python/graph/graph_py.zig + üretilen stubs
• Library: tools/library/gen_F.py is the source-of-truth for _F.py

3) Yanlış ifadeleri düzeltin (bozuk tarihi korumayın)

Skill dokülarındaki yaygın hata modları:

• eski dosya yolları (atopile/src/... vs src/...)
• yeniden adlandırılmış giriş noktaları (lsp_server.py vs hayali server.py)
• artık var olmayan test yolları
• gerçek API yüzeyiyle çelişen davranış hakkındaki iddialar (özellikle Zig bağlamaları)

Kural: bunu repadan kanıtlayamıyorsanız, ya kaldırın ya da doğrulama yapılacak yer gösteren bir hipotez olarak etiketleyin.

4) Minimal, doğru bir ## Quick Start ekleyin

Quick Start şunları içermeli:

• 5–20 satır
• public API yüzeyini repoda başka yerde kullanıldığı şekilde kullanır
• src/.../something.zig gibi yer tutuculara kaçınır

İyi kalıplar:

• Kullanıcı yüzü akışları için CLI kod parçası (ato build, ato dev test --llm)
• Çekirdek API'ler için Python kod parçası (GraphView.create() / TypeGraph.create(...))

5) Doğrulama kontrol listesi (gerekli)

• Frontmatter YAML'ı parse edilir ve name ve description içerir.
• Referans edilen tüm src/, tools/ ve test/ yolları vardır (üretilen yapı çıktılarını hariç tutun).
• Belirtilen herhangi bir kod tanımlayıcısı (sınıf/fonksiyon) vardır (rg kontrolü).
• Quick Start doğru import yolları ve fonksiyon imzaları kullanır.

Stil/Yapı Kuralları

Bu sıralamayı tercih edin:

1. Tek paragraflık özet
2. ## Quick Start
3. ## İlgili Dosyalar
4. ## Bağımlılar (Çağrı Siteleri)
5. ## Nasıl Çalışılır / Geliştirilebilir / Test Edilir
6. ## En İyi Uygulamalar / ## Değişmezler (uygulanabilir olduğunda)

Dokü özlü ve "repo-yerel" tutun: kararlı standart dokümanlar olmadığı sürece harici bağlantılardan kaçının.