Superpowers Claude Code'u Düzeltiyor, Ama Bir Bedeli Var

Superpowers, 1990'lardan beri açık kaynak geliştirici araçları yayınlayan Jesse Vincent tarafından yazılmış bir Claude Code plugin'i. Vincent plugin'i ekim ayında yayınladı ve bir yıl geçmeden repo 280.000 yıldıza ve 25.000 fork'a ulaştı; son push ise kayıttan iki gün önce geldi. Proje şimdiden altıncı büyük sürümünde ve main branch'te 681 commit var, yani bu, lansman coşkusundan sonra terk edilmiş bir prompt koleksiyonu değil.

Gösterge	Değer
GitHub yıldızı	280.000
Fork	25.000
Büyük sürüm	6
main branch'teki commit	681
Açık issue	125

Vincent'ın iddiası tek cümleye sığıyor: kodlama agent'larında eksik olan yetenek değil, disiplin. Bu disiplin, herkesin okuyabileceği, fork'layıp uyarlayabileceği sade markdown dosyaları olarak geliyor. Plugin'i kurduk, on dört skill'in hepsini satır satır okuduk ve dört cephede neyi değiştirdiğine baktık: üretkenlik, kod güvenilirliği, token harcaması ve dokümantasyon.

Superpowers, Claude Code için ücretsiz ve açık kaynak bir plugin. Anthropic'in resmi plugin marketplace'inde yer alıyor ve tek bir komutla kuruluyor. Aynı metodoloji, Cursor, Codex ve Gemini dahil bir düzineden fazla başka harness için de mevcut; her birinin kendi kurulum yolu var.

İşin özü on dört skill: agent'ın, uygun bir durumla karşılaştığında yüklediği markdown talimat dosyaları. Brainstorming, plan yazımı, subagent odaklı geliştirme, test odaklı geliştirme ve sistematik debugging skill'lerinin her biri, kendi kontrol listeleri ve korkuluklarıyla eksiksiz bir çalışma biçimini kodluyor. Debugging skill'i, kök neden izole edilmeden çözüm önermeyi yasaklıyor. Bir doğrulama skill'i, agent'ın işin bittiğini iddia etmek yerine kanıtlamasını zorunlu kılıyor. Her skill yüklendiğinde kendini duyuruyor, böylece agent'ın hangi modda çalıştığını her zaman biliyorsunuz.

Oturum başındaki bir hook, Claude'u her görevden önce bu skill'lerden birinin geçerli olup olmadığını kontrol etmeye zorluyor. Kural giriş skill'inde yazılı: bir skill'in ilgili olma ihtimali yüzde bir bile olsa agent onu yüklemek zorunda. Sonuç, bir alet çantasından çok agent'a enjekte edilmiş bir geliştirme metodolojisi gibi davranıyor.

Vincent çıkış hikâyesini blogunda anlatıyor. Skill'leri, kendi agent'larının öğrendiği derslerden oluşan 2.249 markdown dosyasını tarayarak oluşturdu, sonra taslakları aynı arşivlere karşı zorlu testlerden geçirdi. Metodoloji teoriden yazılmadı, gerçek agent hatalarından çıkarıldı.

Brainstorming, her şeyin içinden geçtiği skill. Bir özellik istediğiniz anda Claude onu yüklüyor ve çerçeveleme sohbeti boyunca bir gereksinim uzmanı gibi davranıyor. Yöntemin tamamı okunabilir tek bir dosyaya sığıyor.

Dosya sert bir kapıyla açılıyor: açık bir niyeti onaylamadan kod yok, scaffolding yok, hiçbir türden uygulama skill'i yok. Hiçbir şey tahmin üzerine inşa edilmiyor ve kapı, ne kadar küçük görünse de her göreve uygulanıyor. Skill daha sonra her isteği üç yoldan birine ayırıyor.

Yol	Tanım	Çıktı
Spike	Bir fizibilite sorusu	Sakladığınız kod değil, bir cevap
Bounded	Repoda zaten var olan bir akışta yapılan küçük bir değişiklik	Kapsamı belirlenmiş bir değişiklik
Architectural	Projenin bir araya geliş biçimini yeniden yapılandıran her şey	Onayladığınız bir spec, ardından bir uygulama planı

Agent sınıflandırmasını açıkça söylüyor, böylece geçersiz kılabiliyorsunuz; çark ise tek yöne dönüyor: görev ortasında keşfedilen gizli karmaşıklık yolu yukarı taşıyor, asla tersine değil. Dosya bir de kırmızı bayrak tablosu içeriyor. "Bu, tasarım gerektirmeyecek kadar basit" gibi düşünceler, hemen yanlarında karşı argümanlarıyla duruyor: sorgulanmamış varsayımlar en çok basit görevlerde pahalıya patlar. Spike bile korkuluğunu koruyor. Agent'ın soruyu cevaplamak için yaptığı her şey "atılacak" etiketiyle kalıyor ve o kodu saklamak, sınıflandırılacak yeni bir istek oluyor.

Diyalog sırasında agent, bir lead mühendisin soracağı soruları soruyor ve tasarımını sindirilebilir bölümlerde sunuyor. Kendi pipeline'ımızda bu aşama, boşuna geliştireceğimiz özellikleri şimdiden öldürdü.

Plan yazma skill'i, tonunu belirleyen bir talimatla açılıyor: planı, kod tabanınız hakkında sıfır bağlamı olan ve dosyanın kendi sözleriyle "şüpheli zevkli" yetenekli bir geliştirici için yazın.

Somut olarak, iş her adımı iki ila beş dakika süren görevlere bölünüyor: başarısız testi yaz, başarısız olduğundan emin olmak için çalıştır, testi geçiren minimum kodu yaz, testleri tekrar çalıştır, commit'le. Tek eylem, tek doğrulama; iş sık commit'lerle ilerliyor. Bu, plugin'deki başka bir skill'in zorunlu kıldığı test odaklı geliştirme döngüsü, yani her görev kendi test döngüsünü taşıyor.

Her görev, oluşturulacak ya da dokunulacak dosyaları satır numarasına kadar listeliyor. Plan zorunlu bir başlıkla açılıyor: tek cümlede hedef, iki üç cümlede mimari, tech stack, spec'e bir link ve projenin genel kısıtları kelimesi kelimesine kopyalanmış halde. Spec birkaç bağımsız alt sistemi kapsıyorsa skill ayrı planlar talep ediyor: alt sistem başına bir plan ve her biri tek başına test edilebilir yazılım üretiyor.

Görev boyutlandırması, güvenilirlik argümanının kalbi. Kısa görev, işini context window'u hâlâ çoğunlukla boşken bitiren bir agent demek. Oturumun taştığı, agent'ın ipin ucunu kaçırdığı ve var olmayan fonksiyonlar uydurmaya başladığı o ana hiç ulaşmıyor. Beş dakikalık hiçbir demo bu sorunu göstermez, ama gerçek bir projede her şeyi belirler: bir agent'ın oturum sonundaki kalitesinin ilk prompt'taki kalitesiyle hiçbir ilgisi yok. Daha az dolu bağlam, mekanik olarak daha az halüsinasyon ve planın dediğini yapan kod demek.

Yürütme anında özel bir skill, işi bir git worktree'de, yani reponun ayrı bir çalışma kopyasında izole ediyor; böylece plan, yanında yaptığınız işe basmadan çalışıyor.

Yürütme skill'i geliştirmeyi subagent'lar üzerinden sürdürüyor. İlkesi dosyanın tek satırına sığıyor: görev başına taze bir subagent, her görevden sonra bir inceleme ve sonunda tüm branch'in geniş bir incelemesi. Ana oturumunuz bir orkestratöre dönüşüyor. Artık kod yazmıyor, görev dağıtıyor. Her subagent tam olarak görevinin ihtiyaç duyduğu bağlamı alıyor, oturum geçmişinizi asla; bu, bağlam kirliliğini önlüyor ve kendi pencerenizi koordinasyon için boş tutuyor.

Subagent başlamadan önce soru sorabiliyor, sonra uyguluyor, test ediyor, commit'liyor ve kendi işini inceliyor. Bitirdiğinde orkestratör iki parçalı bir inceleme yapıyor: önce spec uyumu, sonra kod kalitesi, her görev için özel bir reviewer koltuğuyla. Hiçbir şey doğaçlama değil: skill her rol için (implementer, görev reviewer'ı ve düzeltmeleri yeniden kontrol eden reviewer) orkestratörün görevin bağlamıyla doldurduğu bir şablon prompt sunuyor.

İnceleme sonucu	Ne oluyor
Geçti	Orkestratör tamamlanmayı bir deftere kaydediyor ve planda ilerliyor
Kaldı, 1 ila 3. tur	Orijinal implementer devam ediyor, çünkü kodu ve kendi seçimlerini zaten biliyor
Kaldı, 4. tur	Daha yetenekli bir modelde taze bir implementer görevlendiriliyor
Kaldı, 5. tur	Sigorta atıyor ve orkestratör her açık bulguya kendisi karar veriyor

Skill ters aşırılıktan da kaçınıyor: bir dizi küçük mekanik görev tek bir grup dağıtım olarak gidiyor ve tek birim olarak inceleniyor. Hiçbir şey bir reviewer'dan geçmeden merge edilmiyor. Sonuç, insan ekiplerin code review süreci dediği şey, tek farkı kendi kendine, görev görev çalışması.

Dağıtım sistemi üçüncü kazanımın kapısını açıyor: token ekonomisi. Skill'in model seçimi bölümü tek bir kuralla başlıyor: her rolü kaldırabilecek en zayıf modeli kullan. Orkestratör plandaki her görevin zorluğunu ölçüyor ve ona uygun modeli atıyor.

Görev	Model kademesi
Bir iki dosyaya dokunan iyi tanımlı mekanik görev ya da yazılacak kodu zaten içeren bir plan	En ucuz kademe (uygulama, yazıya geçirme artı test oluyor)
Birkaç dosya arasında koordinasyon, debugging	Standart bir model
Mimari, final branch incelemesi	Mevcut en yetenekli model

Dosya iki incelik ekliyor. Birincisi, dağıtırken modeli her zaman açıkça belirtin: modeli belirtilmemiş bir subagent oturumunuzun modelini miras alıyor, çoğu zaman en pahalısını, bu da tüm bölümü sessizce boşa çıkarıyor. İkincisi, tur sayısı token fiyatını yener. En ucuz modeller çok adımlı işlerde daha fazla tur harcıyor ve sonuçta daha pahalıya geliyor; bu yüzden reviewer'lar ve düzyazıdan çalışan implementer'lar en ucuz raf yerine bir kademe üstten başlıyor.

Bu kurulum sezgilere aykırı bir şeyi mümkün kılıyor: katalogdaki en pahalı modeller olan Opus ya da Fable'ı 20 dolarlık Pro planında çalıştırmak. Pahalı model yalnızca hak eden birkaç kararda çalışıyor, planın kalanı ise kotanızın küçük bir kısmını tüketen modellerde koşuyor.

Son kazanım, plugin'i kurarken kimsenin düşünmediği kazanım. Spec'ler ve planlar, oturum bitince kaybolan sohbet mesajları değil. Repo içine kaydedilen ve işle birlikte commit'lenen markdown dosyaları. Skill konumu da sabitliyor: tarihli bir plans klasörü, özellik başına bir dosya; hedef, mimari ve spec linki başlıkta yer alıyor.

Spec planla birlikte seyahat ediyor ve ikisi arasındaki çatışmalar spec lehine çözülüyor: otorite belge, agent'ın hafızası değil. Git geçmişi artık yalnızca neyin değiştiğini söylemiyor. Nedenini ve agent'ın o an neye karar verdiğini de söylüyor. Altı ay sonra plan dosyasını bir prompt'ta anmak, agent'ın orijinal özelliğin bağlamını hemen geri almasını sağlıyor; aynı alt sisteme dokunan yeni bir özellik ise araziyi yeniden keşfetmek yerine mevcut spec'in üzerine inşa ediliyor.

Artık izlenmeyen görev diye bir şey yok: bir agent'ın kod tabanında yaptığı her şey, ilk brainstorm'dan son commit'e, arkasında bir belge bıraktı. Proje felsefesini iki ilkede özetliyor: geçici yerine sistematik, iddia yerine kanıt. Dokümantasyon süreçten kendiliğinden çıkıyor.

Sınır gerçek ve repo bunun reklamını yapmıyor: tüm bu disiplinin sabit bir maliyeti var ve o maliyet hiç kapanmıyor. Giriş skill'i açık sözlü. En ufak şüphede agent skill'i yüklemek zorunda ve brainstorming dosyası, törenin görevle ölçeklendiğini ama insan onayının asla ölçeklenmediğini belirtiyor.

İki satırlık bir düzeltmede bu, çerçeveleme sorularını yanıtlamak, iki cümlelik bir tasarımı onaylamak, sonra düzeltmeyi görmeden önce tam döngüyü beklemek demek. Bir config dosyasındaki yazım hatası için tam süreç, kendiniz düzeltmekten düpedüz daha yavaş. Orkestrasyonun kendisi de token tüketiyor: dağıtım brief'leri, görev başına iki inceleme ve defter her seferinde ödeniyor ve bunu en çok en küçük görevlerde hissediyorsunuz.

Ters bir belirti de var ve Reddit'teki soruya doğrudan cevap veriyor. Kullanım istatistikleriniz plugin'i yüzde birkaçta gösteriyorsa, istekleriniz skill'leri neredeyse hiç tetiklemiyor; yani kazanımlara hiç dokunmadan her oturumda giriş kontrolünü ödüyorsunuz. Beş turun tamamına giden bir düzeltme döngüsü, dakikalar sürmesi gereken bir görev için beş diff, beş inceleme daha ve bir hakemlik demek. Proje de hiç yerinde durmuyor: bir yıldan kısa sürede birinci sürümden altıncıya geçti ve hâlâ 125 açık issue'su var, yani bugün okuduğunuz skill'ler bir sonraki güncellemede değişmiş olacak.

Plugin kendi çıkışını planlıyor. Talimatları sizin yönergelerinizi skill'lerin üstüne koyuyor, yani agent'a süreci atlamasını açıkça söyleyebiliyorsunuz. Bizim kuralımız: her özellik işi için Superpowers varsayılan olarak açık, küçük düzeltmeler için bilinçli bir atlama.

Claude Code kullanımınız	Karar
Saatler süren özellikler	Kurun: çerçeveleme yanlış şeyi uygulamanızı engelliyor, kısa görevler agent'ı bağlam doygunluğundan uzak tutuyor, model seçimi kotanızı esnetiyor ve asla kendiniz yazmayacağınız bir dokümantasyon miras alıyorsunuz
Tek seferlik script'ler ve küçük düzeltmeler	Geçin: sürecin sabit maliyetini, buna ihtiyacı olmayan görevlerde ödersiniz
Arada kalanlar	Kurun ve "atla" demeyi öğrenin: prompt'unuzdaki tek bir cümle kontrolü size geri veriyor

Her şeyi benimsemeden denemek istiyorsanız, birkaç gün yalnızca brainstorming skill'ini çalıştırın. Kazanımın çoğu onda ve diğer skill'ler ardından doğal olarak ekleniyor. Plugin, ona törenine layık özellikler verdiğiniz sürece dört sözünü de tutuyor. Artık kendi projelerimizde çalışıyor ve brainstorming aşaması, artık kapatmayacağımız aşama. Repo ücretsiz ve açık kaynak, önünüzde sırada 280.000 kişi var.