Get Shit Done - Meta prompt ve spesifikasyon tabanlı geliştirme sistemi

 (github.com/gsd-build)
12 puan yazan GN⁺ 2026-03-19 | 1 yorum | WhatsApp'ta paylaş
  • Claude Code gibi ortamlarda spesifikasyon tabanlı geliştirmeyi (SDD) otomatikleştiren hafif bir sistemdir; karmaşık iş akışları olmadan projelerin tamamlanmasını destekler
  • Bağlam mühendisliği, XML tabanlı prompt yapılandırması ve çoklu ajan orkestrasyonu ile yapay zeka kod kalitesindeki bozulmayı (context rot) önler
  • /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase gibi komutlarla fikir tanımı → planlama → yürütme → doğrulama şeklindeki tüm geliştirme döngüsünü otomatikleştirir
  • Her iş birimi için atomik Git commit ve paralel yürütme (wave execution) ile izlenebilirlik ve verimlilik sağlar
  • Amazon, Google, Shopify, Webflow mühendislerinin kullandığı; yapay zeka destekli geliştirmenin güvenilirliğini ve üretkenliğini artıran bir araçtır

Genel bakış

  • Get Shit Done(GSD), Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity gibi çeşitli yapay zeka geliştirme ortamlarında çalışan hafif bir meta prompt ve bağlam yönetim sistemidir
  • Yapay zekanın kod yazarken yaşadığı, bağlam kalitesinin düşmesi anlamına gelen context rot sorununu çözer ve spesifikasyon tabanlı olarak tutarlı sonuçlar üretir
  • Mac, Windows ve Linux'ta çalışır; npx get-shit-done-cc@latest komutuyla kurulabilir

Geliştirilme nedeni (Why I Built This)

  • Büyük ölçekli organizasyonlara yönelik araçların gereksiz derecede karmaşık süreçler dayatması sorununu çözmek için geliştirildi
  • GSD, karmaşıklığı sistemin içine alan, iş akışını ise sade tutan bir tasarıma sahiptir
  • Arka planda bağlam mühendisliği, XML prompt biçimlendirme, alt ajan orkestrasyonu ve durum yönetimi yürütür
  • Kullanıcılar yalnızca basit komutlarla projeyi tamamlayabilir

Başlıca özellikler ve iş akışı (How It Works)

  • Tüm geliştirme süreci 6 adımdan oluşur

    1. Proje başlatma: Fikir, kısıtlar, teknoloji yığını gibi bilgileri sorar; ardından PROJECT.md, ROADMAP.md gibi dosyaları oluşturur
    2. Discuss aşaması: Uygulama ayrıntılarını tanımlar ve CONTEXT.md oluşturur
    3. Plan aşaması: Paralel araştırma ve planlama yapar, XML yapısında iş birimleri üretir
    4. Yürütme aşaması: Bağımlılıklara dayalı wave paralel yürütme, her iş için commit ve doğrulama gerçekleştirir
    5. Doğrulama aşaması: Otomatik test ve kullanıcı onayı yapar; başarısızlık durumunda otomatik düzeltme planı oluşturur
    6. Yineleme ve kilometre taşı tamamlama: Her aşama tekrarlandıktan sonra release tagging yapılır

  • Quick Mode, tek bir işi hızlıca işler; --discuss, --research, --full bayraklarıyla ayrıntılı kontrol sağlanabilir

Temel teknoloji (Why It Works)

  • Bağlam mühendisliği: Proje genelindeki bağlamı dosya bazında yönetir (PROJECT.md, REQUIREMENTS.md, STATE.md vb.)
  • XML prompt biçimlendirme: Her işi net biçimde tanımlar ve doğrulama adımlarını içerir
  • Çoklu ajan orkestrasyonu: Araştırma, planlama, yürütme ve doğrulama aşamalarında uzman ajanları paralel çalıştırır
  • Atomik Git commit: Her iş birimi için commit oluşturarak izlenebilirlik ve geri dönüş kolaylığı sağlar
  • Modüler tasarım: Aşama ekleme, araya aşama sokma ve değiştirme işlemlerine esneklik tanır; böylece esnek proje yönetimi mümkün olur

Komut sistemi (Commands)

  • Temel iş akışı: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • UI tasarım desteği: /gsd:ui-phase, /gsd:ui-review
  • Kod tabanı analizi: /gsd:map-codebase
  • Proje yönetimi: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • Yardımcı araçlar: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note vb.

Ayarlar ve yapılandırma (Configuration)

  • .planning/config.json yapılandırma dosyasında mod, aşama ayrıntı düzeyi, model profili, iş akışı ajanları, paralelleştirme ve Git branch stratejisi gibi ayarlar kontrol edilebilir
  • Model profili olarak quality, balanced, budget, inherit seçenekleri kullanılabilir
  • workflow.research, workflow.plan_check, workflow.verifier gibi geçişlerle kalite ve hız ayarlanabilir

Güvenlik ve sorun giderme (Security & Troubleshooting)

  • .env, secrets/, *.pem, *.key gibi hassas dosyalar Claude Code'un deny list'ine eklenerek erişim engellenebilir
  • Kurulumdan sonra komut algılama hatası olursa çalışma zamanını yeniden başlatmak veya yeniden kurmak önerilir
  • Docker ortamında CLAUDE_CONFIG_DIR ayarıyla yol sorunları çözülebilir
  • --uninstall seçeneğiyle tüm bileşenler kaldırılabilir

Topluluk ve lisans

  • OpenCode, Gemini CLI ve Codex için topluluk portları desteklenir
  • MIT lisansı ile yayımlanmıştır
  • “Claude Code is powerful. GSD makes it reliable.” — Claude Code'un güvenilirliğini artıran bir araç

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-19
Hacker News yorumları

  • Eskiden Plan mode ile Superpowers'ı birlikte kullanıyordum ama sonunda sadece Plan mode'un yeterli olduğunu düşündüm
    Bu tür framework'ler araştırma gerektiren fire-and-forget işleri için iyi, ancak sanki 10 kattan fazla token tüketiyormuş gibi hissettiriyordu
    Çıktı kalitesindeki fark da büyük değildi, bu yüzden sık sık Max plan sınırına takılıyordum

    • Ben de Superpowers'ın brainstorm·design·implementation planning özelliklerini alıp Ralph tabanlı uygulama katmanına bağladım
      Uygulama planı bittiğinde benden girdi istemeden otomatik olarak devam ediyor ama bunu Docker sandbox içinde çalıştırmak gerekiyor
      Bunun nedeni riskli izin ayarları, ama zaten bunun daha güvenli olduğunu düşünüyorum
      Şu anda iyi çalışıyor ve üretkenliği artırıyor ama bu bana yolculuğun orta aşaması gibi geliyor
    • Ben ise tam tersine Plan mode'dan Superpowers'a geçtim
      Son sürüm duyurusunu görüp tekrar denedim; cross-check ve self-review birkaç katman halinde olduğu için sonuçlar daha istikrarlıydı
      Bunu elle de yapabilirdim ama Superpowers bu süreci otomatikleştirdiği için çok daha rahattı
    • Aynı işi GSD ve Plan Mode ile test ettim; Plan Mode 20 dakikada temel implementasyonu bitirdi, GSD ise saatler sürdü
      GSD proje genelindeki bağlamı dikkate alan kod üretti, Plan Mode ise MVP seviyesinde tam gereken kadarını implement etti
      Workflow'a ve işin ölçeğine göre artıları ve eksileri belirgin
    • GitHub Copilot'ın Plan mode'u, yakın zamanda eklenen plan memory sonrası garipleşti
      Çıktılar daha uzun oldu ama ayrıntılar aksine daha belirsiz hale geldi
      “design”, “figure out” gibi adımlar çoğaldı ve takip soruları sormadan doğrudan implementasyona geçiyor
    • Ben de benzer bir deneyim yaşadım. Bir haftalık Claude abonelik ücreti ve API kredisi yakıp sadece yaklaşık 500 satır kod elde ettim
      Testleri manipüle ettiği ya da alakasız sonuçlar verdiği de oldu
      Sonunda elle yönlendirerek MVP'yi tamamladım ve bu çok daha verimliydi

  • Bu aralar böyle meta framework çok fazla ama gerçekten üretkenliği kanıtlanmış olanını neredeyse hiç görmedim
    Çoğu sadece token israfı ve context window kirliliği yaratıyor
    Sonuçta en iyisi sade kalmak, sadece gerekli bilgiyi verip Plan → Code → Verify sırasını tekrarlamak oldu

    • Apenwarr'ın “The AI Developer’s Descent Into Madness” yazısında, “ajanın kendi framework'ünü yapması” durumu hicivli biçimde anlatılıyor
    • Ben Claude ile Codex'i birleştiren küçük bir mini framework yaptım
      Claude'un tek başına ürettiği hataları Codex'in yakaladığını görünce, her şeyi tek bir ajana tamamen bırakmanın mümkün olmadığını düşündüm
    • Ben görsel spec tasarımı yaklaşımını kullanıyorum
      Uygulamanın ekran akışını görsellerle tasarlayıp bunu yapılandırılmış markdown olarak dışa aktardığımda, LLM ekran bazında bağlamı anlayabiliyor
      Metin tabanlı spec'lere kıyasla eksik durumları veya hata akışlarını daha erken yakalayabiliyorsunuz
    • Bu meta framework'ler sonuçta .vimrc ya da .emacs.d gibi kişiselleştirme araçlarından ibaret
      Yapan kişi için faydalı ama başkalarına anlamsız gelebiliyor

  • Bence Spec-Driven sistemler başarısız olmaya mahkûm
    İngilizce yazılmış spec'ler gerçek kod ile davranışı birbirine bağlayamıyor
    Bu sorun zaten otomatik testlerle çözülmüş durumda
    Sistemin davranışını çalıştırılabilir testler olarak encode etmek gerekiyor
    LLM implementasyon üretirken de testleri önce yazmalı ve mutation testing ile tutarlılığı doğrulamalı
    İlgili içeriği bu yazıda ve GitHub örneğinde topladım

    • Doğal dildeki spec'ler ölçeklenebilir değil ama buna dayalı formal spec üretilebilirse bir potansiyel olabilir
      Sonuçta bunun da kod biçiminde ifade edilmesi gerekir
    • “A sufficiently detailed spec is code” diye bir yazı da vardı ama OpenAI'ın sonucunu yeniden üretemedim
      Bağlantı burada
    • Spec Driven Development, isim olarak TDD'ye benziyor ama yönü tamamen ters
    • Testleri sadece spec'in çıktısı olarak görmek hatalı bir mantık
      Spec'ler testlerden çok daha geniş bir alanı kapsar
      LLM'lerin testleri görmezden gelmesi ya da keyfine göre değiştirmesi de çok sık görülüyor

  • Kişisel bir AI sistemi kullanıyorum ve bunu paylaşmalı mıyım diye düşünüyorum
    Kendi çalışma şeklime göre özelleştirildiği için, herkese açık bir sürümü ayrıca bakımını yapmak bana yük gibi geliyor
    İnsanların bunu doğrudan kullanmasındansa, sistemimden yola çıkan kalıpları paylaşmayı tercih ederim

    • Bakım yapmak zorunda değilsiniz
      Yapay zeka çağında sadece ilham ve fikir paylaşmak bile yeterince değerli olabilir

  • Ekip hackathon'unda GSD kullandım; kod tabanını anlaması çok uzun sürdü ve token tüketimi de çok yüksekti
    Ajan transkriptlerini üretirken de sık sık hata veriyordu
    Birkaç küçük özellik yapmak için fazlasıyla ağır bir araçtı
    Çıkardığım ders basit: iyi spec yazmak + Plan mode'u tekrarlamak çok daha verimliydi

  • Beads'in tasarım kısıtları beni bunaltınca benzer bir aracı kendim yaptım
    Benim sürümüm SQLite tabanlı ve GitHub ile çift yönlü senkronizasyon özelliği ekledim
    Esas nokta, önce modelle konuşup net bir spec dosyası oluşturmak
    Bu dosya varsa model unutmuyor ve ayrıntı ne kadar çoksa çıktı kalitesi de o kadar yüksek oluyor
    Claude ile uzun süredir aklımda olan bir fikri prototipe dönüştürdüm ve beklediğimden daha iyi çıktı

    • Buna “gizli sos” demek biraz abartı; RPI(research-plan-implement) zaten resmî dokümanlarda geçen bir kavram
      Modeller hâlâ olasılıksal sistemler, bu yüzden kusursuz hafıza mümkün değil
      Sanki yepyeni bir sır keşfetmiş gibi sunmak abartılı kaçıyor

  • Superpowers'ı kullandım; bu GSD de benzer göründüğü için karşılaştırmayı merak ettim

    • İkisini de kullandım; GSD gereğinden fazla karmaşık ve yavaş
      Quick mode asıl amacını kaybettiriyor, Superpowers ise bu ikisinin arasında makul bir dengeydi
    • Yapılandırılmış prompt'lar kesinlikle yardımcı oluyor
      Böyle framework'leri repoya koyup AI'a framework'ün kendisini iyileştirtmek, yaratıcı işlerde de faydalı olabiliyor
      Yine de bu tür yapıların geçici hack'ler olduğunu, modeller yeterince eğitildiğinde doğal olarak ortadan kalkacağını düşünüyorum
    • Superpowers planlama aşamasında tüm kodu yazıyor, alt ajanlar da bunu olduğu gibi kopyalıyor; bu yüzden verimsizdi
      GSD bu sorunu çözmüş ama aşama sayısı çok fazla olduğu için yavaş kalıyor
    • Blogumu Hugo'dan Astro'ya taşırken Superpowers'ı test ettim
      Superpowers'ın ürettiği spec çok ayrıntılıydı ama bazı özellikler eksikti (ör. RSS, analizler); paralel migration öneren işbirlikçi spec ise daha esnekti
      Sonunda Claude'dan iki spec'i karşılaştırıp birleştirerek nihai sürümü oluşturmasını istedim
      Ayrıntılı karşılaştırma burada
    • Gerçekten bir CLI wrapper'a ihtiyaç olup olmadığını bilmiyorum
      Sadece Claude skills ile de gayet yapılabilir gibi görünüyor

  • GSD'yi 3 ay boyunca yoğun şekilde kullandım; daha önce kullandığım speckit'ten çok daha olgun
    Karmaşık işleri bile %95 oranında otomatik hallediyor
    Kalan %5'i elle test ederek tamamlıyorum
    Bununla SaaS ürünü (whiteboar.it) bile çıkardım
    Modelin kendisi de gelişti ama üretkenlik artışı kesinlikle hissedildi

    • Ben de benzer bir deneyim yaşadım
      FreshBooks aboneliğine para vermek istemediğim için GSD ile kendi macOS Swift uygulamamı yaptım
      Fişlerden otomatik veri çıkarma ve kategori sınıflandırmasını Anthropic API ile kurdum
      Web uygulaması olarak başladı ama kamera entegrasyonu gibi özellikler eklenince tam teşekküllü bir masaüstü uygulamasına dönüştü
      GSD sayesinde kişisel muhasebe uygulamamı tamamladım

  • Sonuçta gerçekten ihtiyaç duyulan araç, token tasarrufu sağlayan araç
    Ama henüz öyle bir şey yok
    Claude Code da büyük projelerde çok fazla token harcıyor

  • “Bu Markdown dosya paketi” için seçilen isim fazla cringe

    • “Languages” klasörünün altına konsa belki daha iyi olurdu
    • Yine de “gstack” kadar kötü değil, değil mi?