Claude Code ile Şarta Dayalı (Spec-Driven) Geliştirme: Kılavuzlu Bir Eğitim

Claude Code ile "vibe-coding" yaklaşımı küçük işlerde gayet iyi çalışır. Bir değişikliği tarif edersiniz, ajan yazar ve sonucu kontrol edersiniz. Sorun, bir özelliğin aynı anda birden çok dosyaya dokunduğunda başlar. O noktada zor olan kısım uygulama değil, tasarım kararının kendisidir.

Spec-driven (şarta dayalı) geliştirme, herhangi bir kod çalışmadan önce bu tasarım kararını yazılı olarak ele alır. Değişikliğin ne yapması gerektiğini söyleyen kısa bir şartname (spec) yazarsınız. Şartnameyi numaralı görevlerden oluşan bir plana dönüştürürsünüz. Ardından Claude Code, her adım arasında insan incelemesi olacak şekilde, plana göre kodu görev görev yazar.

Bu eğitim, iş akışını uçtan uca öğretir. Claude Code içinde çalışan üç açık kaynak kurulumu adım adım gösterir: Superpowers, GitHub Spec Kit ve BMAD-METHOD.

Claude Code’a yeniyseniz, Claude Code 101 kursuyla başlamanızı öneririm. Farklı yapay zekâ kodlama araçlarıyla pratik yapmak için AI for Software Engineering yetenek yolumuza göz atın.

Spec-Driven Development Nedir?

Spec-driven geliştirme, sırayla üç belgeden oluşan bir iş akışıdır: Değişikliğin ne yapması gerektiğini söyleyen bir belge, adımları belirleyen bir plan ve plan doğrultusunda yazılmış kod; her ikili arasında bir insan incelemesiyle.

Spec-driven geliştirmede bir özelliğin geçtiği üç inceleme noktası.

Şartname (spec), herhangi bir koddan önce düz dilde yazılan, değişikliğin ne yapması gerektiğini söyleyen kısa bir belgedir. “Kullanıcıların verilerini dışa aktarmasına izin ver” gibi bir özelliği düşünün. Bunun için hazırlanacak bir şartname, ajanın aksi halde tahmin edeceği cevapları netleştirir. Şunları listeler: 

• Desteklenen dosya formatları
• Dağıtım/teslim yöntemi
• Yarıda kalmış bir dışa aktarma sırasında davranış
• Kasıtlı olarak kapsam dışı bırakılan kısımlar

Aşağıda, Telegram tabanlı bir sorumluluk uygulamamda workout-shape-verification değişikliği için Claude Code’un yazdığı gerçek bir şartnamenin açılışı var. Bu değişiklik, kırılgan bir nabız eşiğini, zaman içindeki nabız eğrisinin şekline yönelik bir kontrolle değiştiriyor:

# Workout Shape-Based Verification — Design Spec
 
**Created:** 2026-05-05
**Status:** Draft
**Supersedes (partially):** [2026-03-17-calisthenics-verification-design.md]
  — replaces the absolute-HR thresholds for the Workout activity type.
  Run / Ride / Walk verification is unchanged.
 
## Problem
 
The current Workout verifier accepts an activity only if absolute heart-rate
levels clear fixed cutoffs: avg ≥ 120, max ≥ 140, range ≥ 30, suffer_score ≥ 3.
Two failures in production:
 
1. **False-negative risk.** As cardiovascular fitness improved
   (resting HR ~80), real calisthenics sessions with disciplined rest now
   average 115–125 bpm. Recent sessions have come within 4 bpm of the 120 floor.
 
<!-- ... continues for hundreds of lines through Solution, Risks,
 	Out of scope, and What is removed / added / changed / unchanged -->

Plan bir sonraki belgedir. Yukarıdaki şartnameyi, ajanın tek tek üzerinde çalışabileceği şekilde, her görevde dosyayı, değişikliği, sıralamayı ve testi adlandıran numaralı görevlere böler. Şartname “ne”yi yanıtlarken, plan “hangi adımlarda”yı yanıtlar. 

Kod en sonda gelir; plana göre, görev görev yazılır.

Üç belge. Her ikili arasında bir insan incelemesi vardır. Şartname, plana dönüşmeden önce incelenir. Plan, koda dönüşmeden önce incelenir. Kod, birleştirilmeden önce incelenir.

Spec-driven geliştirme, plan modundan nasıl farklıdır?

Claude Code’un yerleşik plan modunu (girmek için Shift+Tab’e iki kez basın) kullanmış ve bunun neden farklı olduğunu merak etmiş olabilirsiniz. Plan modu, tek bir sohbet turu içinde bir plan üretir. Plan bellekte yaşar; kalıcı bir şartname yoktur ve aşamalar arasında bir inceleme adımı bulunmaz.

Spec-driven geliştirme ise şartnameyi ve planı disk üzerinde dosya olarak kalıcı hale getirir. Her biri bir sonraki aşama başlamadan önce insan incelemesinden geçer ve bu çıktılar oturumlar boyunca yaşar. Plan modu, yazılım geliştirmesinin iki aşamasını tek bir sohbet turuna sıkıştırır. Bu, küçük işlerde çalışır; kod tabanı büyüyüp gerçek kullanıcılara hizmet vermeye başladığında ise başarısız olur.

Neden Vibe-Coding Duvara Toslar

Vibe-coding prototiplerde, tek dosyalarda ve atılacak betiklerde işe yarar. Gerçek kullanıcılara yanıt vermeniz gereken uygulamalarda ve mevcut büyük kod tabanlarında kötüleşir. Çizilmesi gereken sınır yaklaşık 4 dosyadır. Bu kadar dosyaya dokunan her değişikliğin bir şartnameye ihtiyacı vardır; ayrıca tutarlı bir nihai duruma sahip her yeniden düzenleme (refactor) ve “bu tam olarak ne yapmalı?” sorusunun zor olduğu her görev için de geçerlidir.

Başarısızlığın nedeni nettir. “Uygulamama fotoğraf paylaşımı ekle” gibi muğlak bir istem, modelin binlerce ifade edilmemiş gereksinimi tahmin etmesine yol açar.

Bu gereksinimlerden yalnızca birini ele alalım: bildirim tercihleri. Ürün yöneticisi kanal başına anahtarlar varsayar. Arka uç bir aç/kapa anahtarı kurar. Ön uç, işletim sistemi seviyesinde entegrasyon varsayar. Üç kelimenin dört makul okuması, dört farklı ürün.

Spec-driven geliştirmedeki her inceleme adımı, pahalı hale gelmeden farklı bir hata sınıfını yakalar. Şartname incelemesi, kapsam şişmesini ve yanlış kök-neden kurgularını yakalar. Plan incelemesi, yarıda kalmış uygulamaları ve çakışan kalıpları yakalar. Kod incelemesi ise kağıt üzerinde iyi görünen ama ilk başarısız testte dağılan planları yakalar.

Getirisi gerçektir ve yavaş yavaş birikir. Şartname aşaması, herhangi bir kod çalışmadan önce saatlerce yazım maliyeti getirir ve ilk birkaç özellik vibe-coding’den daha yavaş hissettirir. Benim başa baş noktam dördüncü ya da beşinci özellik civarında geldi. O zamana kadar şartnameler, aksi halde yayına alıp bir hafta sonra yeniden yazacağım tasarım hatalarını yakalıyordu.

Sıradaki üç bölüm, bu iş akışını Claude Code içinde çalıştıran üç açık kaynak yaklaşımı anlatıyor. Zorladıkları yapı bakımından en hafiften en ağıra doğru sıralıdır.

Superpowers

Superpowers üçlü arasındaki en hafif olanıdır. Günlükte benim de kullandığım araçtır ve en ayrıntılı anlatacağımız da bu olacak.

Superpowers nedir?

Superpowers, Jesse Vincent’ın (obra/superpowers, MIT lisans) geliştirdiği bir Claude Code eklentisidir; GitHub’da yaklaşık 194 bin yıldızı vardır. 

Bir dizi beceriyle birlikte gelir. Claude becerisi, Claude Code’da, ajanının belirli bir iş akışını takip etmek için talep üzerine yüklediği adlandırılmış bir talimat dosyasıdır. Superpowers, Claude Code’un doğrudan koda atlamak yerine spec-driven döngüde kalmasını sağlayan beceriler sunar.

GitHub’daki Superpowers proje sayfası.

Superpowers nasıl kurulur

Claude Code’un resmi eklenti pazar yeri üzerinden kurun:

/plugin install superpowers@claude-plugins-official

SessionStart kancası using-superpowers becerisini otomatik yükler; böylece siz yazmaya başlar başlamaz iş akışı devrededir. (Claude code hooks, ajanın belirli bir yaşam döngüsü olayında çalıştırdığı betiklerdir.) Proje başına ayrıca kurulum yapmanız gerekmez.

Superpowers iş akışı

Sonrasında, dört beceri günlük işinizi yönetir:

Bir alt-ajan, ebeveynin kendi bağlam penceresinde odaklı iş yaptırmak için görevlendirdiği ayrı bir Claude Code örneğidir. Yukarıdaki tabloda yer alan inceleme alt-ajanları, alt-ajan olarak çalışır; böylece kodu ebeveynin çerçevesi olmadan, “soğuk” okurlar.

Superpowers nasıl kullanılır

Bu dört beceriyi, ne istediğinizi düz dilde anlatarak çağırırsınız. Beyin fırtınası (brainstorming) becerisi “yeni özelliği tartışalım” ifadesini duyunca, şartname konuşmasını kendiliğinden başlatır. Diğerleri de benzer şekilde tetiklenir.

Dört Superpowers becerisi sırasıyla; iki insan inceleme noktası brainstorming ile writing-plans arasında yer alır.

Aşağıdaki yürüyüş, yukarıdaki şartname alıntısında geçen aynı workout-shape-verification özelliğini kullanır.

Aşama 1: beyin fırtınasından şartnameye

Claude Code’u açıp şunu yazıyorum:

Let's discuss a new feature. The Workout verifier in make-me-work uses absolute heart-rate cutoffs and is now misfiring as my resting HR drops. I want to replace the absolute cutoffs with a check on the shape of the HR curve over the session.

brainstorming becerisi devralır ve aralarında şunların da bulunduğu on kadar soru sorar:

• Doğru “şekil” ne olarak sayılır
• Hangi veri akışlarının birleştirileceği
• Şekil bakımından doğru görünüp eski bir eşiği geçemeyen oturumlarla ne yapılacağı
• Değişikliğin Run ve Ride için de geçerli olup olmayacağı

Burada iki insan inceleme noktası bulunur. İlki, verdiğim yanıtların istediğimle örtüştüğünü doğruladığım tasarım incelemesidir. İkincisi şartname incelemesidir. Claude’un yazdığı dosyayı okur ve herhangi bir plan çalışması başlamadan önce onaylarım.

Aşama 2: şartnameden plana

writing-plans becerisini çalıştırırım. Onaylanmış şartnameyi okur ve dört bölümden oluşan bir plan dosyası yazar:

• “Bitti”nin tanımı
• Dokunulan dosyaların dosya haritası
• Demo yolculuğundan geçen bir kullanıcı yolculuğu
• Numaralı görev listesi şeklinde onay kutulu alt adımlar 

Planı gözden geçiririm, sırası bozuk ya da fazla kaba görünen görevlere itiraz ederim ve onaylarım.

Aşama 3: plandan koda

subagent-driven-development çalıştırırım. Bu noktadan sonra döngü bensiz ilerler. Plandaki her görev için beceri:

1. Başarısız bir test yazar
2. Onu geçecek kodu yazar
3. Refaktör eder
4. Farkı (diff) soğuk okuyan bir kod inceleme alt-ajanı görevlendirir

İnceleyici bir sorun işaretlerse, döngü sonraki göreve geçmeden önce onu düzeltir. Bu aşamanın içinde bir insan inceleme noktası yoktur. Bu aşama için önemli olan, önceki iki incelemedir.

Aşama 4: tam diff incelemesi

Plan bittiğinde requesting-code-review çalıştırırım. Taze bir alt-ajan, tüm farkı şartname ve planla karşılaştırarak okur ve bir inceleme paylaşır. Birleştirmeden önce önerileri alırım.

Plândaki bir görev şartnameyle çeliştiğini ortaya koyduğunda, döngü durur ve sorar. Şartnameyi düzenleyebilirim (ya da Claude’a düzenletebilirim) ve etkilenen görevleri yeniden üretebilirim. Diğer seçenek, görevin içinde tek seferlik bir düzeltmedir. Superpowers, şartname hatalarını sessizce es geçmez.

Diskte gerçek şartnameler ve planlar

İşte editörde açık olan workout-shape-verification özelliğinin şartnamesi:

Beyin fırtınası becerisinin yazdığı şartname dosyası, diske bu şekilde düşer.

Başlıkta, beyin fırtınası becerisinin varsayılan olarak yazdığı Created, Status ve Supersedes alanları yer alır. Ardından Problem bölümü gelir. Hiçbiri kod değildir. Dosya, ekran görüntüsünün ötesinde önerilen çözüm ve değişikliğin dokunması gereken/olmaması gereken alanlara dair kısımlar ile devam eder.

Eşleşen plan, User Journey bölümüyle açılır:

Onaylı şartnameden writing-plans becerisinin ürettiği plan dosyası.

Yolculuk, demo yolunu beşer adımda yürütür; her adımda tam komutları, dosyaları ve argümanları adlandırır. Ardından gelen numaralı görevler, her adımı subagent-driven-development becerisinin çalışabileceği onay kutulu alt adımlara çevirir.

İki belge şöyle eşleşir:

Şartname ve plan yan yana. Şartname neyin ve neden değiştiğini yanıtlar. Plan ise hangi adımlarla yanıtlar.

Daha büyük şartname ve planlarda, resmi döngüde olmayan bir adım ekliyorum: kırmızı takım (red-team) geçişi. Onaylamadan önce, bir veya birkaç Opus alt-ajanına şartnameyi soğuk okutup farklı açılardan açıklar aratıyorum. Bu bir Superpowers özelliği değil, kişisel bir alışkanlık. Yeterince kötü varsayımı yakaladığı için sürdürüyorum.

Superpowers’ın yanlış tercih olduğu durumlar

Superpowers, tek bir depoda solo çalışmaya uyar. Tüm kod tabanı tek bir Claude Code oturumuna sığıyorsa ve iki sayfalık bir şartnameyi gerçekten okuyacaksanız en iyi sonucu verir. Ayrıntılı karşılaştırma aşağıda Aralarından nasıl seçim yapmalı bölümünde. Kısa versiyon: Superpowers, çok depolu özelliklerde ve net rol ayrımı gerektiren işlerde zorlanır.

Bir geliştirici, eklenti hakkında yaptığı kamuya açık bir şikâyette dördüncü bir hata modunu yakaladı: “En küçük görev bile sonsuza kadar sürüyor; Claude alt-ajanlar başlatıp tamamen lüzumsuz planlar yazıyor. Biraz CSS değiştirmek bile artık sonsuza kadar sürüyor.”

Çözüm, minicik değişikliklerde Superpowers’ı atlamaktır. Beceriler yalnızca beyin fırtınası tetikleyicisiyle etkinleşir. Tek satırlık bir CSS düzenlemesi, şartname döngüsünü hiç çağırmadan Claude Code’dan geçirilebilir. Buradaki gerçek hata modu, şartname gerektirmeyen işe iş akışını aşırı uygulamaktır.

GitHub Spec Kit

Spec Kit, şartnamenin tek bir Claude Code oturumundan daha uzun ömürlü olması gerektiğinde tercih edilir. Ayrıca Claude Code’u hiç açmayan kişilerin şartnameyi okuması gerektiğinde de doğru seçimdir.

GitHub spec-kit nedir?

Spec Kit, GitHub’ın ( github/spec-kit, MIT lisans) bizzat bakımını yaptığı, 100 binden fazla yıldıza sahip bir GitHub projesidir. Tüm büyük yapay zekâ kodlama ajanlarında aynı şekilde çalışan bir CLI ve iş akışı sunar. Claude Code, Cursor, Aider, Cline ve Roo Code desteklenir. Ajan-nötr tasarım, şartnamenin Claude Code dışında yaşamasını sağlar.

GitHub’daki Spec Kit proje sayfası.

GitHub spec-kit nasıl kurulur

Henüz resmi bir PyPI paketi yok; bu yüzden CLI’ı etiketten uv ile kurun:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

vX.Y.Z’yi güncel sürüm etiketiyle değiştirin. Paketin adı specify-cli’dır ve kaydettiği komut specify’dır.

GitHub spec-kit iş akışı

İş akışı, CLI’ın ajanın eğik çizgi (slash) komut listesine eklediği dokuz komutla çalışır. Altısı döngünün çekirdeğidir; üçüyse, çekirdek döngünün kapsamadığı durumlar için isteğe bağlıdır.

Komut grubu ile fiil arasındaki ayırıcı iki nokta değil, noktadır: /speckit.specify, /speckit:specify değil. 

Dokuz Spec Kit eğik çizgi komutu: boru hattında altı çekirdek komut, ona bağlı üç isteğe bağlı komut.

Bu komutların ürettiği çıktılar, Superpowers bölümünde gördüğünüzle aynı şartname ve plandır; bunlar da diske yazılır ve Git ile izlenir. Fark, taşınabilirliktir: Spec Kit’in çıktıları yalnızca Claude Code ile değil herhangi bir yapay zekâ kodlama ajanıyla çalışacak şekilde tasarlanmıştır; ayrıca iş akışı, tek bir aracın döngüsünün yan ürünü olmak yerine, GitHub pull request’leri üzerinden paydaş incelemesi için inşa edilmiştir.

GitHub spec-kit ne zaman kullanılmalı

Solo bir projede muhtemelen Spec Kit’e ihtiyaç duymazsınız. Şu durumlarda ona başvurun:

• Proje bir kişiyi aşıyorsa
• Şartnamenin, Claude Code’u hiç açmayan kişilerce incelenmesi gerekiyorsa
• İşin bir kısmında Claude Code dışındaki bir ajan çalıştırıyorsanız
• Herhangi bir araca bağlı olmadan yaşayacak ve aylar sonra da okunacak bir şartname formatı istiyorsanız

BMAD Yöntemi

Spec Kit çıktıları düzenlerken, BMAD insanları düzenler. Spec’ten koda iş akışını, her biri isimli bir rol-ajan tarafından yürütülen dört aşamaya böler.

BMAD nedir?

BMAD-METHOD (bmad-code-org/BMAD-METHOD, MIT lisans, yaklaşık 47 bin yıldız) sürüm 6’dadır. Projenin kendi dokümanlarında akronim, “Breakthrough Method for Agile AI-Driven Development” olarak açılır. Claude Code ve diğer ajanların üzerinde çalışır ve bir modül ekosistemi olarak kurulur. Varsayılan kurulum, altı rol-ajanı, dört iş akışı aşaması ve 34+ adlandırılmış iş akışı barındıran bir çekirdek modül sunar.

GitHub’daki BMAD-METHOD proje sayfası.

BMAD nasıl kurulur

BMAD’i Node ile kurun:

npx bmad-method install

Altı rol-ajan, kullanıcı tarafından ajan barındırıcısı içinden adlarıyla etkinleştirilen komut istemi personalarıdır. Claude Code’da bu, BMAD’in kurduğu etkinleştirme komutunu yazmak anlamına gelir. Sürümden sürüme değişebildiği için tam sözdizimi için README’ye bakın. 

BMAD çalışma arkadaşı ajanları ve çıktılarıyla tanışın

Bir kez etkinleşince, ajan o rolün talimatlarını, sesini ve çıktılarını siz kişilik değiştirene kadar üstlenir. Altısı şunlardır:

• Mary, Analist
• Paige, Teknik Yazar
• John, Ürün Yöneticisi
• Sally, UX Tasarımcısı
• Winston, Mimar
• Amelia, Geliştirici

v6’da bekleyebileceğiniz iki rol eksiktir: Scrum Master ajanı ve bağımsız bir QA ajanı yoktur. Sprint planlama ve hikâye hazırlığı Geliştirici ajanına düşer; QA test üretimi ise Geliştiricinin tetiklediği bir iş akışıdır.

Çıktı seti tek bir şartnameden daha ağırdır. Şunları elde edersiniz:

• bir ürün özeti
• bir PRD (Ürün Gereksinimleri Dokümanı)
• bir UX şartnamesi
• bir mimari belge
• epiklerin kullanıcı hikâyelerine (iş sevk edildiğinde kullanıcıların yapabilecekleri) bölünmüş hâli

PRD ve mimari belge, birlikte Superpowers şartnamesiyle aynı rolü oynar. Ayrım, bunları iki rol-ajan arasında ve daha resmî bir biçime yayar. Çıktı seti bir bütün olarak, her özelliğin bir üst katmandan bağlam devraldığı tam bir yazılım geliştirme yaşam döngüsünü kapsar.

BMAD iş akışı

v6 iş akışı dört aşamada çalışır.

Dört BMAD aşaması ve her birini yürüten rol-ajan. Quick Flow hattı, küçük işler için ilk üç aşamayı atlar.

Aşama 1, analiz, isteğe bağlıdır. Mary (Analist) ve Paige (Teknik Yazar) araştırma yapar ve bir ürün özeti üretir. Ne inşa edeceğinizi zaten biliyorsanız bu aşamayı atlayın.

Aşama 2, planlama, zorunludur. John (ÜY) PRD’yi yazar. Özelliğin bir arayüzü varsa Sally (UX Tasarımcısı) bir UX şartnamesi ekler.

Aşama 3, çözümleme, Winston’ın aşamasıdır. Mimar önce mimari taslağı çıkarır, ardından John gereksinimleri epiklere ve hikâyelere böler. Hikâyeleri mimarinin arkasından yerleştirmek, onları gerçek uygulama sınırlarına göre boyutlandıran bir v6 tercihidir. Winston daha sonra UYGUN (PASS), ENDİŞELER (CONCERNS) veya BAŞARISIZ (FAIL) hükmüyle sonuçlanan bir uygulama-hazırlığı kontrolü yürütür.

Aşama 4, uygulama, Amelia’nın (Geliştirici) hikâye hikâye çalıştığı yerdir: hikâyeyi oluştur, inşa et ve kod incelemesini yap. Tam bir epik bittiğinde, tüm epik için QA test üretimi iş akışını tetikler. Claude Code’un gerçek kodlamayı yaptığı aşama, Amelia olarak çalıştığı bu aşamadır.

Küçük ve iyi kapsamlanmış işler için BMAD, Amelia’yı doğrudan etkinleştirip ilk üç aşamayı atlayan bir “Quick Flow” hattı sunar. Etkinleştirme komutu BMAD README’sindedir (tam sözdizimi sürümler arasında değişebilir). Quick Flow, PRD ve mimari belge üretmez; yalnızca kısa bir hikâye ve onu karşılayan kodu üretir. “Bir düğme değişikliği için bu fazla” itirazına cevaptır.

Şartname, uygulama ortasında hatalı çıkarsa BMAD, Winston’ın Aşama 3 hükmüne geri döner. BAŞARISIZ (FAIL), PRD’yi yeniden yazmak üzere sizi Aşama 2’ye gönderir. ENDİŞELER (CONCERNS), Winston’ın belirttiği riskler hikâyeye eklenmiş şekilde devam eder. Bu ayrım, küçük tutarsızlıklarda ilerlemeyi sürdürmenize, büyüklerinde ise sert fren yapmanıza imkân verir.

Karmaşıklığın ne zaman karşılığını verir

BMAD, gerçek kullanıcılara yanıt verilen, uzun soluklu projelerde karşılığını verir. Ayrıca çok geliştiricili ekiplerde işi kişiler arasında devretmeye uygundur. Aşama ve rol ayrımının, maliyetinden daha çok zaman kazandırması gerekir.

Tek kişilik yan projeler için doğru uyum değildir. Solo çalışmada, dört aşama ve altı ajan bölünmesi çoğunlukla ek yüktür. Rol ayrımının anlam taşıyacağı ikinci bir kişi ekipte yoktur.

Çerçeveler Arasında Nasıl Seçim Yapılır

Seçimi belirleyen üç kural vardır.

• Şartname, Claude Code’u hiç açmayan kişilerce okunmalıysa veya Git’te uzun vadeli bir çıktı olarak yaşamalıysa Spec Kit’i kullanın.
• Birden fazla kişi belirgin rollerde çalışıyorsa veya gerçek bir ÜY tarzı paydaş döngüdeyse BMAD’i kullanın.
• Aksi halde Superpowers’ı kullanın.

Projenize dair üç soru, diğer tarafta dört çerçeve seçeneği.

Karar ağacının adlandırdığı dördüncü bir seçenek daha var: Spec Kit ile Superpowers’ı birleştirmek. Çıktılar Git’te takımlar arası inceleme için yaşasın diye şartname aşamasında Spec Kit’i kullanın. Sonra tek satırlık bir yapılandırmayla Superpowers’ın subagent-driven-development becerisini Spec Kit plan dosyasına yönlendirin. Böylece Spec Kit’ten kalıcı şartnameyi, Superpowers’tan ise sıkı uygulama döngüsünü elde edersiniz.

Sonuç

Spec-driven geliştirme, sırayla üç belgedir. Şartname neyin inşa edileceğini söyler, plan hangi adımlarla yapılacağını söyler, kod ise planı izler. Her ikili arasında bir insan incelemesi vardır.

Yukarıdaki karar ağacını kullanarak bir çerçeve seçin; çoğu okur için bu Superpowers olacaktır. Onu kurun ve normalde vibe-coding ile yapacağınız, 3 ila 5 dosyaya dokunan bir özelliği seçin. Beyin fırtınası, şartname, plan ve uygulama aşamalarından uçtan uca geçirin. Gerçek bir koşum, bu iş akışını herhangi bir açıklamadan daha iyi öğretir.

Claude Code temel bilgilerini önce tazelemek isterseniz, DataCamp’te uygulamalı bir Claude Code eğitimi, plan modu, CLAUDE.md ve TDD’yi kapsayan en iyi uygulamalar rehberi ve plan modunun kendisine dair derinlemesine bir inceleme bulunur.