AIDive

Video paketi

Claude Code için Superpowers: karar tablosu, kaynaklar, kontrol listesi, rehber

9 dk okuma

TL;DR

  • Superpowers bir alet çantası değil, bir süreçtir: her özelliği bir brainstorming oturumunun, yazılı bir planın ve her biri gözden geçirilen taze subagent zincirinin arkasına kilitleyen on dört markdown skill.
  • Claude Code oturumlarınız saatler süren özellikler geliştiriyorsa kurun. Kullanımınız tek seferlik scriptler ve iki satırlık düzeltmelerden ibaretse atlayın: giriş kontrolü her görevde çalışır ve asla kapanmaz.
  • Token argümanı gerçek, ama tek bir skill'in tek bir bölümünden geliyor: Model Selection. Orkestratör, rolü taşıyabilecek en ucuz modeli atar; pahalı model yalnızca mimariye ve son branch review'una dokunur.
  • Repo sağlıklı: 280,597 yıldız, 25,138 fork, main üzerinde 681 commit, 2026-08-12 tarihli v6.3.0 sürümü, 2025-10-09'da oluşturulmuş.
  • Videoyu başlatan şikayet, yüzde 1 ila 3 kullanım istatistiği, bir hata değil: skill'lerin işinizde hiç tetiklenmediği anlamına gelir; yani kapının bedelini ödersiniz ama karşılığını almazsınız.
  • Orta yol, prompt'unuzda tek bir cümledir: ajana küçük düzeltmelerde süreci atlamasını söyleyin ve gerisini benimsemeden önce birkaç gün yalnızca brainstorming'i çalıştırın.

Kaynaklar ne söylüyor

Repo rakamları 2026-09-02 tarihinde okundu: main dalında 280,597 yıldız, 25,138 fork ve 681 commit; main üzerindeki son commit 2026-08-12 tarihli (v6.3.0), main dışı bir dala ise 2026-08-31'de daha yeni bir push yapılmış s1. Issues sekmesi o gün 125 açık issue gösteriyordu; API'deki 350 rakamı 225 açık pull request'i de içerir, bu yüzden başka eklentilerle karşılaştırırken API'yi değil sekmeyi alıntılayın s6. Proje 2025-10-09'da oluşturuldu ve on dört skill içeriyor s2. Yazarın lansman yazısı iddiayı tek satırda anlatır: kodlama ajanlarının yeteneği eksik değil, disiplini eksik; ve bu disiplin, herkesin okuyabileceği, fork'layabileceği ve düzenleyebileceği düz markdown dosyaları olarak dağıtılabilir s5. Eklenti resmi marketplace'te listeli, dolayısıyla kurulum tek bir komuttur ve güncellemeler marketplace üzerinden gelir s4.

Giriş noktası, oturum başlangıç hook'unun her şeyden önce yüklediği bir skill'dir. Ajana, bir skill'in uygulanıp uygulanmadığından en ufak bir şüphe varsa, cevap vermeden ya da kod yazmadan önce onu yükleyip kontrol etmesi gerektiğini söyler. Bu kural hem faydanın hem de sabit maliyetin kaynağıdır s14.

Brainstorming bir HARD-GATE ile açılır: açık bir niyeti onaylayana kadar kod yok, iskele yok, uygulama skill'i yok. Ardından isteği üç yoldan birine ayırır: çıktı kod değil de bir cevapsa spike; repo'da zaten var olan bir akışın içindeki küçük bir değişiklik için bounded; projeyi yeniden yapılandıran her şey için architectural. Ajan sınıflandırmayı duyurur, böylece itiraz edebilirsiniz; mandal tek yönlüdür: görev ortasında bulunan gizli karmaşıklık yolu yukarı taşır, asla aşağı indirmez s9.

Plan yazma skill'i, kod tabanınız hakkında hiçbir bağlamı olmayan ve dosyanın kendi ifadesiyle "tartışmalı zevke" sahip yetkin bir geliştirici için yazılmış bir plan ister. İş, her adımı iki ila beş dakika süren görevlere bölünür: başarısız olan testi yaz, başarısız olduğunu görmek için çalıştır, minimal kodu yaz, testleri tekrar çalıştır, commit'le. Her görev oluşturulacak ya da değiştirilecek dosyaları satır numarasına kadar listeler ve plan zorunlu bir başlıkla açılır s10.

Yürütme, subagent-driven development skill'idir: görev başına bir taze subagent, her görevden sonra bir review, sonunda tüm branch için bir review. Ana oturum kod yazmayı bırakır ve görev dağıtır. Her subagent yalnızca kendi görevinin bağlamını alır, oturum geçmişinizi asla; bu da kendi pencerenizi koordinasyon için boş tutar. Subagent uygular, test eder, commit'ler ve kendini gözden geçirdikten sonra orkestratör iki parçalı bir review çalıştırır: önce spec uyumu, sonra kod kalitesi; her görev için bir reviewer koltuğu ayrılmıştır. Dosya döngüyü görev başına en fazla beş turla sınırlar s11. İşin kendi izolasyonu bir worktree skill'ine devredilir, böylece plan asla mevcut checkout'unuzda çalışmaz s13.

Model Selection bölümü tek bir kuralla başlar: rolü taşıyabilen en az yetenekli modeli kullanın. Bir ya da iki dosyaya dokunan, iyi tanımlanmış mekanik bir görev küçük bir modele gider; plan yazılacak kodu zaten içeriyorsa uygulama, aktarma artı testlerden ibarettir ve en ucuz kademe yeter. Çok dosyalı koordinasyon ve debugging standart bir modele gider. Mimari ve son branch review'u mevcut en yetenekli modeli ister. Pratikte iki ayrıntı önemlidir: dağıtım sırasında modeli her zaman açıkça adlandırın ve orkestratör modeli seçmeden önce her görevin zorluğunu derecelendirsin s12. Pahalı modeli yirmi dolarlık Pro planında karşılanabilir kılan mekanizma budur: yalnızca bunu hak eden kararlar üzerinde çalışır.

Dokümantasyon kazancı sürecin yan etkisidir. Spec'ler ve planlar kaybolup giden sohbet mesajları değildir; repo'ya kaydedilen ve işle birlikte commit'lenen markdown dosyalarıdır, böylece bir reviewer sonradan yalnızca neyin değiştiğini değil, değişikliğin neden yapıldığını da okur s3.

Maliyet, reponun reklamını yapmadığı olandır. Videoyu başlatan thread, yüzde 1 ila 3 kullanım istatistiği bildiriyor ve kullanmamanın ötesinde dezavantajın ne olduğunu soruyor s7. Dosyalardaki cevap şu: brainstorming törenini göreve göre ölçeklendirir ama insan onayını asla atlamaz s9. İki satırlık bir düzeltmede bile çerçeveleme sorularını cevaplar, iki cümlelik bir tasarımı onaylar ve tam döngüyü beklersiniz. Dağıtım brief'leri, görev başına iki review ve takip defteri her seferinde ödediğiniz tokenlardır ve en küçük görevlerde bu kendini gösterir. Düşük kullanım istatistiği skill'lerin işinizle eşleşmediği anlamına gelir; okunması gereken gerçek sinyal budur.

Kullanıma göre karar

Claude Code kullanımınız Kurulsun mu? Neden
Saatler süren özellikler, birkaç dosya, bir branch Evet Çerçeveleme yanlış şeyi inşa etmeyi önler, kısa görevler ajanı bağlam doygunluğundan uzak tutar, model seçimi kotayı uzatır, dokümantasyon süreçten kendiliğinden çıkar
Karışık: bazı günler özellik, çoğu gün düzeltme Evet, atlama kuralıyla Kapıyı özellikler için tutun, prompt'ta ajana küçük düzeltmelerde süreci atlamasını söyleyin
Tek seferlik scriptler, config yazım hataları, iki satırlık düzeltmeler Hayır Kapının sabit maliyeti, ona ihtiyacı olmayan görevlerde de işler
Meraklı ama yöntemin tamamını benimsemeye hazır değil Yalnızca brainstorming Kazancın çoğunu taşır; diğer skill'ler sonradan doğal olarak eklenir

Pazartesi yapın

  • Resmi marketplace'ten kurun ve eklenti önbelleğini açın: on dört SKILL.md dosyasını bir kez okuyun, kısalar ve ürünün tamamı onlardır.
  • Gerçek bir özelliği kapıdan uçtan uca geçirin: brainstorming, plan, subagent dağıtımı, branch review. Süreci bir düzeltmeye göre değil, buna göre değerlendirin.
  • Bir hafta sonra kullanım istatistiklerinizi kontrol edin. Birkaç yüzdenin altındaysa skill'ler işinizle eşleşmiyordur: ya görevleriniz çok küçüktür ya da istekleri özellik olarak ifade etmeniz gerekir.
  • Proje talimatlarınıza bir atlama kuralı ekleyin: birkaç satırlık tek dosya düzeltmelerinde brainstorming olmadan doğrudan değişikliğe geç.
  • Eklentiyi bıraksanız bile Model Selection merdivenini kendi subagent prompt'larınıza kopyalayın: her dağıtımda modeli açıkça adlandırın.
  • Eklentinin yazdığı spec'leri ve planları silmek yerine commit'leyin; bunlar tasarım kaydınızdır.
  • Projeyi başka bir eklentiyle karşılaştırmadan önce açık issue'ları API rakamından değil, Issues sekmesinden sayın.

Daha ileri

  • Skill dosyalarından önce tasarım niyeti için lansman yazısını okuyun: disiplinin neden kod olarak değil markdown olarak dağıtıldığını açıklar s5.
  • README'deki philosophy bölümü yöntemin kısa halidir ve zaten çalışma biçiminize uyup uymadığını kontrol edeceğiniz yerdir s3.
  • Skills library bölümü on dört skill'i birer satırlık amaçla listeler; dizine göz atmaktan daha hızlıdır s16.
  • Subagent skill'indeki görev başına en fazla beş tur, elle yazdığınız her orkestrasyona kopyalamaya değer sert bir durdurma sınırıdır s11.
  • Bir thread, bu tür bir eklentinin daha güçlü modellerden sonra da hayatta kalıp kalmayacağını soruyor; hayatta kalan kısımlar çerçeveleme kapısı ve commit'lenmiş planlar, modellerin özümsediği kısımlar ise mekaniklerdir s19.
  • Orkestrasyon törenleri yüzünden tükenen bir haftalık kullanım limiti raporu, küçük işlerde benimsemeden önce okunması gereken karşı örnektir s20.
  • Rakip bir talimat setiyle karşılaştırma ödünleşimi gösterir: daha az ama daha katı skill'ler ile geniş bir kural kataloğu s18.
  • Açık issue listesi, bugün diğer kullanıcılarda neyin bozulduğunu görmenin en hızlı yoludur s6.

Kaynaklar

FAQ

Superpowers token tasarrufu mu sağlar, yoksa yakar mı?

İkisi de. Özelliklerde model seçimi mekanik görevleri küçük modellere yollar ve pahalı modeli mimari ile branch review'u için saklar, böylece kota uzar. Küçük düzeltmelerde brief'ler, görev başına iki review ve defter salt ek yüktür.

Yüzde 1 ila 3 kullanım istatistiği ne anlama geliyor?

Skill'ler yalnızca durum onlarla eşleştiğinde tetiklenir. Düşük bir rakam, görevlerinizin eklentinin anlamında özellik olmadığını gösterir; yani giriş kontrolünü ödersiniz ama karşılığını veren kısma hiç ulaşmazsınız.

Bir kısmını tutabilir miyim?

Evet. Brainstorming tek başına kazancın çoğunu taşır ve Model Selection merdiveni elle yazılmış her subagent prompt'unda çalışır. Ajana küçük düzeltmelerde süreci atlamasını söyleyin, kontrol sizde kalır.