Get Shit Done - Sistem Pengembangan Berbasis Meta Prompt dan Spesifikasi

 (github.com/gsd-build)
12 poin oleh GN⁺ 2026-03-19 | 1 komentar | Bagikan ke WhatsApp
  • Sistem ringan yang mengotomatisasi spec-driven development (SDD) di Claude Code dan lainnya, membantu menyelesaikan proyek tanpa workflow yang rumit
  • Mencegah penurunan kualitas kode AI akibat context rot melalui context engineering, penataan prompt berbasis XML, dan orkestrasi multi-agent
  • Mengotomatisasi seluruh siklus pengembangan definisi ide → perencanaan → eksekusi → verifikasi dengan perintah seperti /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase
  • Menjamin keterlacakan dan efisiensi melalui Git commit atomik per unit kerja dan eksekusi paralel (wave execution)
  • Alat yang digunakan oleh engineer di Amazon, Google, Shopify, Webflow untuk meningkatkan keandalan dan produktivitas pengembangan berbasis AI

Ikhtisar

  • Get Shit Done(GSD) adalah sistem meta prompt dan manajemen konteks ringan yang berjalan di berbagai lingkungan pengembangan AI seperti Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity
  • Menangani masalah context rot, yaitu turunnya kualitas konteks saat AI menulis kode, dan menghasilkan output yang konsisten berdasarkan spesifikasi
  • Berjalan di Mac, Windows, dan Linux, serta dapat diinstal dengan perintah npx get-shit-done-cc@latest

Latar Belakang Pembuatan (Why I Built This)

  • Dibuat untuk mengatasi masalah alat bagi organisasi besar yang menuntut prosedur rumit secara tidak perlu
  • GSD dirancang dengan prinsip kompleksitas disimpan di dalam sistem, workflow tetap sederhana
  • Secara internal menjalankan context engineering, formatting prompt XML, orkestrasi sub-agent, dan manajemen status
  • Pengguna dapat menyelesaikan proyek hanya dengan perintah sederhana

Fitur Utama dan Workflow (How It Works)

  • Seluruh proses pengembangan terdiri dari 6 tahap

    1. Inisialisasi proyek: menanyakan ide, batasan, tech stack, lalu membuat PROJECT.md, ROADMAP.md, dan lainnya
    2. Tahap diskusi: mendefinisikan detail implementasi dan membuat CONTEXT.md
    3. Tahap perencanaan: riset paralel dan penyusunan rencana, lalu membuat unit kerja berstruktur XML
    4. Tahap eksekusi: eksekusi paralel berbasis wave sesuai dependensi, commit dan verifikasi untuk tiap tugas
    5. Tahap verifikasi: pengujian otomatis dan konfirmasi pengguna, serta pembuatan rencana perbaikan otomatis saat gagal
    6. Iterasi dan penyelesaian milestone: mengulang tiap tahap lalu memberi release tag

  • Quick Mode menangani satu tugas dengan cepat, dan dapat dikontrol lebih rinci dengan flag --discuss, --research, --full

Teknologi Inti (Why It Works)

  • Context engineering: mengelola konteks proyek secara menyeluruh per file (PROJECT.md, REQUIREMENTS.md, STATE.md, dll.)
  • Formatting prompt XML: mendefinisikan tiap tugas dengan jelas dan menyertakan prosedur verifikasi
  • Orkestrasi multi-agent: menjalankan agent khusus secara paralel untuk tahap riset, perencanaan, eksekusi, dan verifikasi
  • Git commit atomik: memastikan keterlacakan dan kemudahan pemulihan melalui commit per unit kerja
  • Desain modular: memungkinkan penambahan, penyisipan, dan perubahan tahap dengan bebas untuk manajemen proyek yang fleksibel

Sistem Perintah (Commands)

  • Workflow inti: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • Dukungan desain UI: /gsd:ui-phase, /gsd:ui-review
  • Analisis codebase: /gsd:map-codebase
  • Manajemen proyek: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • Utilitas: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note, dll.

Pengaturan dan Konfigurasi (Configuration)

  • File konfigurasi .planning/config.json mengontrol mode, perincian tahap, profil model, workflow agent, paralelisasi, dan strategi branching Git
  • Profil model dapat dipilih dari quality, balanced, budget, inherit
  • Kualitas dan kecepatan dapat disesuaikan melalui toggle seperti workflow.research, workflow.plan_check, workflow.verifier

Keamanan dan Pemecahan Masalah (Security & Troubleshooting)

  • File sensitif seperti .env, secrets/, *.pem, *.key harus ditambahkan ke deny list Claude Code untuk memblokir akses
  • Jika perintah tidak dikenali setelah instalasi, disarankan me-restart runtime atau melakukan instal ulang
  • Di lingkungan Docker, masalah path dapat diatasi dengan mengatur CLAUDE_CONFIG_DIR
  • Semua komponen dapat dihapus dengan opsi --uninstall

Komunitas dan Lisensi

  • Mendukung port komunitas untuk OpenCode, Gemini CLI, dan Codex
  • Dirilis dengan lisensi MIT
  • “Claude Code is powerful. GSD makes it reliable.” — alat untuk meningkatkan keandalan Claude Code

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-19
Komentar Hacker News

  • Dulu saya pernah memakai Plan mode dan Superpowers bersama-sama, tetapi pada akhirnya merasa Plan mode saja sudah cukup.
    Framework seperti ini bagus untuk tugas fire-and-forget yang butuh riset, tetapi rasanya menghabiskan token lebih dari 10 kali lipat.
    Perbedaan kualitas hasilnya juga tidak terlalu besar, jadi saya sering mentok di batas Max plan.

    • Saya mengambil fitur brainstorm·design·implementation planning dari Superpowers lalu menempelkannya ke lapisan implementasi berbasis Ralph.
      Setelah rencana implementasi selesai, prosesnya lanjut otomatis tanpa menanyakan input saya lagi, tetapi harus dijalankan di dalam Docker sandbox.
      Itu karena pengaturan izin yang berisiko, tetapi menurut saya justru lebih aman begitu.
      Sekarang berjalan dengan baik dan produktivitasnya tinggi, tetapi rasanya ini masih tahap pertengahan perjalanan.
    • Saya justru pindah dari Plan mode ke Superpowers.
      Setelah melihat pengumuman versi terbarunya, saya mencobanya lagi, dan hasilnya terasa lebih stabil karena ada beberapa lapis cross-check dan self-review.
      Sebenarnya bisa dilakukan manual, tetapi Superpowers mengotomatiskan proses itu sehingga jauh lebih nyaman.
    • Saya menguji pekerjaan yang sama dengan GSD dan Plan Mode; Plan Mode menyelesaikan implementasi dasar hanya dalam 20 menit, sedangkan GSD butuh beberapa jam.
      GSD menghasilkan kode yang mempertimbangkan konteks seluruh proyek, sementara Plan Mode hanya mengimplementasikan seperlunya pada tingkat MVP.
      Kelebihan dan kekurangannya sangat jelas tergantung alur kerja dan skala pekerjaannya.
    • Plan mode milik GitHub Copilot belakangan berubah aneh setelah penambahan plan memory.
      Output-nya jadi bertele-tele, sementara detailnya justru makin kabur.
      Tahap seperti “design” dan “figure out” malah bertambah banyak, lalu langsung lanjut ke implementasi tanpa pertanyaan lanjutan.
    • Saya juga mengalami hal serupa. Saya menghabiskan biaya langganan Claude dan kredit API selama seminggu penuh, tetapi cuma mendapat sekitar 500 baris kode.
      Kadang ia memanipulasi tes atau menghasilkan output yang ngawur.
      Pada akhirnya saya menyelesaikan MVP dengan mengarahkan secara manual, dan itu jauh lebih efisien.

  • Akhir-akhir ini ada terlalu banyak meta framework seperti ini, tetapi saya hampir tidak pernah melihat yang benar-benar terbukti meningkatkan produktivitas.
    Kebanyakan hanya membuang token dan mencemari context window.
    Pada akhirnya, yang paling baik justru tetap sederhana: berikan hanya informasi yang diperlukan lalu ulangi urutan Plan → Code → Verify.

    • Tulisan Apenwarr “The AI Developer’s Descent Into Madness” menggambarkan secara satir situasi ketika “agen membuat framework-nya sendiri.”
    • Saya membuat sendiri mini framework yang menggabungkan Claude dan Codex.
      Saat melihat Codex menangkap kesalahan yang dihasilkan Claude sendirian, saya jadi merasa satu agen saja tidak bisa dipercaya sepenuhnya.
    • Saya memakai pendekatan desain spesifikasi visual.
      Alur layar aplikasi saya rancang dalam bentuk gambar, lalu diekspor ke markdown terstruktur sehingga LLM bisa memahami konteks per layar.
      Dibanding spesifikasi berbasis teks, pendekatan ini bisa lebih dini menangkap state yang hilang atau alur error.
    • Meta framework seperti ini pada akhirnya cuma alat personalisasi seperti .vimrc atau .emacs.d.
      Bagi pembuatnya berguna, tetapi bagi orang lain sering terasa tidak berguna.

  • Menurut saya, sistem Spec-Driven memang ditakdirkan gagal.
    Spesifikasi yang ditulis dalam bahasa Inggris tidak mampu menghubungkan kode nyata dengan perilaku sesungguhnya.
    Masalah ini sebenarnya sudah diselesaikan lewat pengujian otomatis.
    Perilaku sistem harus dienkode ke dalam tes yang dapat dijalankan.
    Saat LLM menghasilkan implementasi pun, tes harus ditulis lebih dulu, lalu konsistensinya diverifikasi dengan mutation testing.
    Saya merangkum hal terkait di artikel ini dan contoh GitHub.

    • Spesifikasi bahasa alami memang tidak skalabel, tetapi jika darinya dibuat spesifikasi formal (formal spec), masih ada kemungkinan.
      Pada akhirnya itu tetap harus diekspresikan dalam bentuk kode.
    • Dulu juga ada tulisan “A sufficiently detailed spec is code”, tetapi saya tidak bisa mereproduksi hasil OpenAI.
      Lihat tautan ini.
    • Spec Driven Development namanya memang mirip TDD, tetapi arahnya justru kebalikan.
    • Melihat tes hanya sebagai hasil turunan dari spesifikasi adalah logika yang keliru.
      Spesifikasi mencakup wilayah yang jauh lebih luas daripada tes.
      LLM juga sering mengabaikan tes atau mengubahnya sesuka hati.

  • Saya memakai sistem AI pribadi, tetapi masih ragu apakah akan dibuka ke publik.
    Sistem itu sangat dikustomisasi untuk pekerjaan saya, jadi terasa berat kalau harus memelihara versi publik terpisah.
    Daripada membiarkan orang lain langsung memakainya, saya lebih ingin membagikan polanya saja dengan merujuk pada sistem saya.

    • Sebenarnya tidak harus dipelihara terus.
      Di era AI, sekadar berbagi inspirasi dan ide saja sudah cukup bernilai.

  • Saya pernah memakai GSD di hackathon tim, tetapi butuh waktu terlalu lama untuk memahami codebase, dan pemakaian token juga sangat besar.
    Error saat membuat transkrip agen juga sering terjadi.
    Untuk membuat beberapa fitur kecil saja, alat ini terasa berlebihan.
    Pelajaran yang saya dapat sederhana — menulis spesifikasi yang baik + mengulang Plan mode jauh lebih efisien.

  • Saya merasa batasan desain Beads terlalu menyesakkan, jadi saya membuat sendiri alat serupa.
    Versi saya berbasis SQLite dan saya menambahkan sinkronisasi dua arah dengan GitHub.
    Intinya adalah berbicara dulu dengan model untuk membuat file spesifikasi yang jelas.
    Kalau file itu ada, model tidak akan lupa, dan makin banyak detailnya, makin tinggi kualitas output-nya.
    Saya memakai Claude untuk membuat prototipe dari ide yang sudah lama saya pikirkan, dan hasilnya jauh lebih baik dari perkiraan.

    • Kalau dibilang “saus rahasia”, RPI(research-plan-implement) sebenarnya sudah menjadi konsep di dokumentasi resmi.
      Model tetaplah sistem probabilistik, jadi mustahil punya ingatan yang sempurna.
      Membungkusnya seolah-olah seperti menemukan resep rahasia baru adalah berlebihan.

  • Saya pernah memakai Superpowers, dan GSD kali ini terlihat mirip jadi saya penasaran dengan perbandingannya.

    • Saya sudah memakai keduanya, dan GSD terlalu kompleks sekaligus lambat.
      Quick mode membuat tujuan aslinya hilang, sementara Superpowers terasa lumayan sebagai titik tengah.
    • Prompt yang terstruktur memang jelas membantu.
      Kalau framework seperti ini dimasukkan ke repositori lalu AI diminta memperbaiki framework itu sendiri, itu juga berguna untuk pekerjaan kreatif.
      Tetapi struktur seperti ini cuma hack sementara; begitu modelnya sudah cukup terlatih, sepertinya akan hilang dengan sendirinya.
    • Superpowers menulis semua kode di tahap perencanaan, lalu subagen hanya menyalinnya begitu saja, jadi tidak efisien.
      GSD memang menyelesaikan masalah itu, tetapi karena tahapnya terlalu banyak, kecepatannya jadi lambat.
    • Saya menguji Superpowers saat memindahkan blog saya dari Hugo ke Astro.
      Spesifikasi buatan Superpowers sangat detail, tetapi beberapa fitur (misalnya RSS dan analitik) tertinggal, sementara spesifikasi kolaboratif yang mengusulkan migrasi paralel lebih fleksibel.
      Pada akhirnya saya meminta Claude membandingkan dan menggabungkan kedua spesifikasi itu untuk membuat versi final.
      Lihat perbandingan lengkapnya.
    • Saya tidak yakin apakah wrapper CLI benar-benar diperlukan.
      Dengan Claude skills saja rasanya sudah cukup bisa diimplementasikan.

  • Saya memakai GSD secara intensif selama 3 bulan, dan kualitasnya jauh lebih matang daripada speckit yang sebelumnya saya pakai.
    Bahkan pekerjaan rumit pun bisa diotomatisasi sampai 95%.
    Sisa 5%-nya saya selesaikan lewat pengujian manual.
    Dengan ini saya bahkan meluncurkan produk SaaS (whiteboar.it).
    Walaupun modelnya sendiri juga berkembang, peningkatan produktivitasnya jelas terasa.

    • Saya juga punya pengalaman serupa.
      Karena sayang dengan biaya langganan FreshBooks, saya membuat sendiri aplikasi Swift macOS dengan GSD.
      Ekstraksi kuitansi otomatis sampai pengelompokan kategori saya implementasikan memakai Anthropic API.
      Awalnya dimulai dari web app, tetapi berkembang menjadi aplikasi desktop penuh sambil menambahkan fitur seperti integrasi kamera.
      Berkat GSD, saya berhasil menyelesaikan aplikasi akuntansi pribadi.

  • Pada akhirnya, alat yang benar-benar dibutuhkan adalah alat yang menghemat token.
    Tetapi sampai sekarang belum ada yang seperti itu.
    Claude Code pun memakai token terlalu banyak di proyek besar.

  • Nama untuk “bundel file Markdown ini” terlalu memalukan.

    • Mungkin akan lebih baik kalau diletakkan di bawah folder “Languages”.
    • Tapi tetap masih lebih baik daripada “gstack”, bukan?