Spec Kit dari GitHub - Mengembangkan perangkat lunak berkualitas tinggi dengan lebih cepat

• Spec-Driven Development: pendekatan yang berupaya mengangkat spesifikasi (Spec), yang dalam pengembangan tradisional hanya menjadi sarana pendukung, menjadi spesifikasi yang dapat dieksekusi, lalu langsung menghasilkan implementasi yang berfungsi dari spesifikasi tersebut
  • Menggeser praktik yang berpusat pada kode, dengan menekankan pengembangan berbasis niat yang terlebih dahulu mendefinisikan apa dan mengapa, lalu merinci bagaimana setelahnya
  • Gagasan utamanya adalah membuat hasil yang konsisten melalui spesifikasi, serta mengotomatiskan pekerjaan berulang agar pengembang bisa fokus pada masalah produk
• Spec Kit adalah kumpulan alat yang membantu mengotomatiskan implementasi dengan mengubah spesifikasi menjadi artefak yang dapat dieksekusi dengan cara ini
• Setelah instalasi, gunakan /specify untuk menjelaskan apa/mengapa, /plan untuk mendeklarasikan stack/arsitektur, dan /tasks untuk membuat unit kerja
• Tujuannya adalah membantu organisasi lepas dari penulisan kode umum yang tidak terdiferensiasi dan fokus pada skenario produk, sebagai kerangka kerja eksperimental yang ingin meningkatkan kualitas dan kecepatan sekaligus melalui pendekatan berbasis spesifikasi

Filosofi inti: Core philosophy

• Pola pikir spec-first dengan pengembangan berbasis niat yang mendahulukan apa dan merinci bagaimana kemudian
• Menulis spesifikasi yang kaya dengan guardrail dan prinsip organisasi, serta melalui proses penyempurnaan bertahap alih-alih sekali jadi lewat pembuatan kode
• Berorientasi pada cara memanfaatkan kemampuan interpretasi model AI canggih secara aktif untuk mengubah spesifikasi menjadi hasil yang dapat dieksekusi

Proses berbasis spesifikasi dengan Spec Kit

• Spec Kit menempatkan spesifikasi sebagai pusat proses rekayasa, mendorong implementasi, checklist, dan pemecahan tugas, sementara pengembang terutama berperan sebagai pengarah
  • Agen coding menangani sebagian besar pekerjaan penulisan
• Prosesnya terdiri dari 4 tahap, masing-masing memiliki checkpoint yang jelas, dan tidak berlanjut ke tahap berikutnya sampai pekerjaan saat ini tervalidasi sepenuhnya
• Tahap Specify: jika diberikan deskripsi tingkat tinggi, agen coding akan membuat spesifikasi terperinci yang berfokus pada perjalanan pengguna, pengalaman, dan metrik keberhasilan, bukan pada stack teknis
  • Memetakan siapa penggunanya, masalah apa yang diselesaikan, bagaimana cara berinteraksi, dan hasil penting apa yang diharapkan
  • Ini berbentuk artefak hidup yang berkembang seiring pembelajaran tentang pengguna
• Tahap Plan: jika diberikan stack, arsitektur, dan batasan yang diinginkan, agen coding akan menghasilkan rencana teknis yang komprehensif
  • Mencakup teknologi standar perusahaan, integrasi sistem legacy, kepatuhan, target performa, dan lain-lain
  • Bisa meminta beberapa variasi rencana untuk dibandingkan, dan jika dokumen internal disediakan, pola arsitektur dapat diintegrasikan secara langsung
• Tahap Tasks: berdasarkan spesifikasi dan rencana, agen coding memecah pekerjaan menjadi bagian-bagian kecil yang dapat ditinjau
  • Setiap tugas dapat diimplementasikan dan diuji secara independen, serta dirancang agar AI dapat memvalidasi dan melacaknya
  • Misalnya, alih-alih "membangun autentikasi", menjadi "membuat endpoint pendaftaran pengguna dengan validasi format email" yang lebih spesifik
• Tahap Implement: agen coding mengerjakan tugas satu per satu atau secara paralel, sementara pengembang meninjau perubahan yang terfokus
  • Spesifikasi memberi tahu apa yang akan dibangun, rencana menjelaskan bagaimana membangunnya, dan tugas menunjukkan apa yang harus dikerjakan
• Di setiap tahap, pengembang melakukan peran validasi dengan merefleksikan dan menyempurnakan, memeriksa apakah spesifikasi menangkap niat dengan tepat, apakah rencana mempertimbangkan batasan nyata, serta apakah ada kekurangan atau edge case

Cara menggunakan Spec Kit dalam workflow agentic

• Spec Kit bekerja dengan agen coding seperti GitHub Copilot, Claude Code, Gemini CLI dan mengarahkan agen serta menghasilkan artefak melalui serangkaian perintah sederhana
  • Ini mengubah prompt yang ambigu menjadi niat yang jelas agar dapat dieksekusi dengan andal
• Setelah inisialisasi proyek, berikan prompt tingkat tinggi dengan perintah /specify, lalu agen coding akan membuat spesifikasi lengkap yang berfokus pada "apa" dan "mengapa" proyek
• Dengan perintah /plan, berikan arah teknis tingkat tinggi, lalu agen coding akan membuat rencana detail yang menghormati arsitektur dan batasan
• Dengan perintah /tasks, spesifikasi dan rencana dipecah menjadi daftar tugas yang dapat dijalankan, dan agen coding mengimplementasikan kebutuhan proyek berdasarkan daftar tersebut

Tahap pengembangan: Development phases

• Tahap 0-to-1 (greenfield): mendukung alur pembuatan spesifikasi → penyusunan rencana → pembuatan aplikasi tingkat produksi berdasarkan kebutuhan tingkat tinggi
• Tahap eksplorasi kreatif: menekankan proses bereksperimen dengan berbagai stack/arsitektur dan pola UX melalui implementasi paralel
• Tahap perbaikan bertahap (brownfield): pengembangan evolusioner yang berulang untuk menambah fitur, memodernisasi legacy, dan menyesuaikan proses

3 skenario di mana pendekatan ini bekerja dengan baik

• Greenfield (zero-to-one): saat memulai proyek baru, alih-alih langsung menulis kode, spesifikasi dan rencana dibuat lebih dulu untuk memastikan AI membangun hal yang dimaksud, serta menghasilkan hasil yang disesuaikan alih-alih solusi generik berbasis pola umum
• Pekerjaan fitur pada sistem yang sudah ada (N-to-N+1): saat menambahkan fitur ke codebase yang kompleks, spesifikasi memperjelas interaksi fitur baru dengan sistem yang ada, dan rencana mengenkode batasan arsitektur sehingga kode yang dihasilkan terasa native
  • Ini membuat pengembangan berkelanjutan lebih cepat dan aman, meski mungkin memerlukan teknik context engineering tingkat lanjut
• Modernisasi legacy: saat membangun ulang sistem legacy ketika niat aslinya sudah hilang, proses Spec Kit menangkap logika bisnis esensial ke dalam spesifikasi modern dan merencanakan arsitektur baru sehingga AI dapat membangunnya ulang tanpa utang teknis

Prasyarat

• Memerlukan Linux/macOS atau WSL2 di Windows
• Pilih salah satu dari Claude Code, GitHub Copilot, Gemini CLI, Cursor sebagai agen AI

[edunga1]

Ini mengingatkan saya pada Copilot Workspace.

[cocofather]

Sepertinya ini akan menjadi fondasi bagi pemrograman AI berbasis bahasa alami.

[tested]

Kelebihan Spec Kit dari GitHub juga bisa digunakan di GitHub Copilot.
Karena dibuat oleh GitHub, itu wajar saja? Tetapi banyak alat lain yang berbasis Claude.

[skageektp]

Ini mengingatkan saya pada Kiro IDE.

[kandk]

Menarik juga. Masuk akal juga.

[xguru]

Tautan penjelasan detail SDD di tengah tulisan itu bagus. Di bawah ini adalah ringkasan yang saya buat dengan AI.

Pengembangan Berbasis Spesifikasi (Specification-Driven Development, SDD)

The Power Inversion

• Membalik alur yang sebelumnya berpusat pada kode dengan PRD dan dokumen desain sebagai pendukung, sehingga spesifikasi menjadi sumber utama dan kode menjadi artefak ekspresi yang diimplementasikan dalam bahasa atau framework tertentu
  • Diajukan diagnosis bahwa kesenjangan permanen antara spesifikasi dan implementasi sulit diatasi hanya dengan penguatan dokumentasi atau prosedur
  • Jika spesifikasi yang dapat dieksekusi dan rencana implementasi menghasilkan kode, maka kesenjangan itu hilang dan yang tersisa hanya transformasi
• AI memungkinkan penafsiran spesifikasi yang kompleks dan penyusunan rencana implementasi, tetapi generasi tanpa struktur menimbulkan kekacauan, sehingga SDD menjaga kualitas dengan struktur dan guardrail yang presisi
• Pemeliharaan adalah tindakan evolusi spesifikasi, niat pengembangan diekspresikan melalui bahasa alami, aset desain, dan prinsip inti, sementara kode menempati posisi last mile
• Debugging memprioritaskan perbaikan spesifikasi dan rencana implementasi alih-alih memperbaiki kode yang salah, dan refactoring didefinisikan ulang sebagai restrukturisasi demi kejelasan

The SDD Workflow in Practice

• Ide dimatangkan menjadi PRD melalui interaksi percakapan dengan AI, dan AI memperjelas pertanyaan, edge case, dan kriteria penerimaan
  • Mengubah kebutuhan dan desain menjadi aktivitas berkelanjutan sehingga mendukung pekerjaan spesifikasi berbasis branch di tingkat tim, beserta review dan versioning
• Research agent menelusuri kompatibilitas library, performa, keamanan, dan kendala organisasi (standar DB, autentikasi, kebijakan deployment), lalu otomatis mencerminkannya ke spesifikasi
• Dari PRD dihasilkan rencana implementasi yang memetakan kebutuhan dan keputusan teknis secara dapat ditelusuri, sementara AI terus memverifikasi kontradiksi, ambiguitas, dan kekurangan
• Saat spesifikasi dan rencana sudah cukup stabil, generasi kode dimulai, tetapi pada tahap awal dilakukan generasi eksploratif untuk memverifikasi kelayakan
  • Konsep domain diubah menjadi model data, user story menjadi endpoint API, dan skenario penerimaan menjadi test
• Metrik dan insiden pada tahap operasional memperbarui spesifikasi agar tercermin dalam regenerasi berikutnya; bottleneck performa dinaikkan menjadi kebutuhan nonfungsional, dan kerentanan menjadi kendala global

Why SDD Matters Now

• Titik ambang kapabilitas AI: kini dimungkinkan menghasilkan kode yang berfungsi secara andal dari spesifikasi bahasa alami, dan otomatisasi bagian mekanis dari penerjemahan implementasi mendukung eksplorasi serta amplifikasi kreativitas
• Ledakan kompleksitas: banyaknya layanan, framework, dan dependensi membuat keselarasan antara niat dan implementasi sulit dipertahankan, sehingga diperlukan penyelarasan yang digerakkan spesifikasi ala SDD
• Percepatan perubahan: dalam situasi pivot yang sering terjadi, SDD menangani perubahan lewat regenerasi sistematis alih-alih propagasi manual dokumen-desain-kode
  • Sebagai contoh, ini memungkinkan simulasi what-if dan implementasi paralel, sehingga memberi kelincahan pengambilan keputusan

Core Principles

• Spesifikasi = bahasa bersama: spesifikasi adalah artefak kelas satu, kode adalah ekspresi dari stack tertentu, dan pemeliharaan adalah tindakan evolusi spesifikasi
• Spesifikasi yang dapat dieksekusi: spesifikasi dengan tingkat akurat, lengkap, dan tidak ambigu menghasilkan sistem yang berjalan
• Penyempurnaan berkelanjutan: melakukan verifikasi konsistensi terus-menerus, bukan gate sekali jalan
• Konteks berbasis riset: performa, keamanan, dan kendala organisasi dikumpulkan secara kontinu lalu disuntikkan ke spesifikasi
• Umpan balik dua arah: realitas operasional menjadi input pembaruan spesifikasi
• Branching untuk eksplorasi: mendukung pembuatan banyak implementasi dari spesifikasi yang sama sesuai target optimasi seperti performa, maintainability, UX, dan biaya

Implementation Approaches

• Praktik saat ini berfokus pada kombinasi alat yang sudah ada dan menjaga disiplin, dan dapat diimplementasikan dengan elemen berikut
  • AI assistant untuk penyempurnaan spesifikasi secara iteratif
  • Research agent untuk pengumpulan konteks teknis
  • Alat generasi kode untuk transformasi spesifikasi → implementasi
  • Version control yang disesuaikan dengan workflow spec-first
  • Pengecekan berbasis analisis konsistensi AI terhadap dokumen spesifikasi
• Prinsip umumnya adalah menempatkan spesifikasi sebagai single source of truth, dan memperlakukan kode sebagai artefak yang diminta spesifikasi

Streamlining SDD with Commands

• /specify: mengubah deskripsi fitur menjadi spesifikasi terstruktur, lalu mengotomatiskan penomoran, pembuatan branch, dan susunan direktori berbasis template
• /plan: analisis spesifikasi → peninjauan kepatuhan konstitusi → penerjemahan teknis → dokumentasi model data, kontrak API, dan skenario test → menghasilkan validasi quickstart
• /tasks: membaca plan.md dan desain terkait untuk menghasilkan daftar task yang dapat dieksekusi, serta memberikan penanda task yang bisa diparalelkan dan pengelompokan paralel yang aman
• Contoh: fitur chat
  • Menunjukkan contoh alur yang mempersingkat sekitar 12 jam pekerjaan dokumentasi tradisional menjadi sekitar 15 menit penyiapan melalui otomasi spesifikasi, rencana, dan task
  • Artefaknya mencakup spesifikasi, rencana implementasi dan alasannya, kontrak API dan model data, skenario quickstart, serta tasks.md yang dikelola versinya di branch

The Power of Structured Automation

• Mencegah item terlewat: template mencakup hingga kebutuhan nonfungsional dan penanganan error
• Keterlacakan keputusan: semua pilihan teknis terhubung ke kebutuhan yang konkret
• Dokumen yang hidup: karena spesifikasi menghasilkan kode, sinkronisasi lebih mudah dijaga
• Iterasi cepat: saat kebutuhan berubah, regenerasi rencana memungkinkan respons dalam hitungan menit atau jam

Template-Driven Quality

• Mencegah detail implementasi masuk terlalu dini: aturan fokus pada WHAT/WHY dan mengecualikan HOW membantu menjaga level abstraksi
• Memaksa penandaan ketidakpastian: marker [NEEDS CLARIFICATION] mendorong larangan berasumsi dan pertanyaan eksplisit
• Self-review berbasis checklist: mewujudkan quality gate dengan memeriksa kelengkapan, kejelasan, dan kriteria penerimaan yang terukur
• Constitution gate: menerapkan pemeriksaan tahap awal (-1) seperti gate kesederhanaan (≤3 proyek), gate anti-abstraksi (langsung memakai framework), dan gate integrasi lebih dulu (kontrak dan contract test didahulukan)
• Manajemen detail berlapis: kode dan detail yang berlebihan dipisahkan ke implementation-details/ untuk menjaga keterbacaan
• Prioritas test: memastikan verifiabilitas dengan aturan pembuatan file dan test lebih dulu dalam urutan kontrak → integrasi → E2E → unit
• Menekan asumsi dan fitur spekulatif: memperkuat pengelolaan cakupan lewat larangan fitur spekulatif dan penjelasan prasyarat tiap tahap

The Constitutional Foundation

• Mengadopsi konstitusi pengembangan dalam bentuk prinsip tak berubah di memory/constitution.md untuk menjaga seluruh implementasi tetap konsisten, sederhana, dan berkualitas tinggi
  • Article I: Library-First — semua fitur dimulai sebagai library independen untuk memastikan modularitas
  • Article II: CLI Mandate — semua library harus mengekspos antarmuka CLI yang mendukung input/output teks dan JSON untuk menjamin observabilitas dan kemudahan pengujian
  • Article III: Test-First — implementasi dilarang sebelum test disetujui dan kegagalan (red) dikonfirmasi, dengan prinsip definisi perilaku didahulukan
  • Articles VII & VIII: Kesederhanaan dan anti-abstraksi — menekan overengineering dengan meminimalkan jumlah proyek dan mengandalkan framework secara langsung
  • Article IX: Integration-First Testing — mengutamakan test yang mendekati lingkungan nyata dan mewajibkan contract test didahulukan sebelum implementasi
• Melalui gate Phase -1 pada template, kepatuhan pada konstitusi diubah menjadi checklist, dan pengecualian mencatat alasan eksplisit dalam Complexity Tracking
• Melalui prosedur amandemen, cara penerapan prinsip dapat berevolusi, tetapi filsafat intinya tetap dipertahankan

The Transformation

• Tujuannya bukan menggantikan developer, melainkan mengotomatiskan penerjemahan yang mekanis untuk mengamplifikasi kemampuan manusia dan menjaga keselarasan antara niat dan implementasi
• SDD mempraktikkan transformasi berkelanjutan di mana spesifikasi menghasilkan kode, sehingga spesifikasi, riset, dan kode berevolusi bersama dalam feedback loop yang rapat

[amoplan]

AI apa yang Anda gunakan untuk merangkumnya?

[xguru]

Saya memakainya dengan GPT-5. Saya menggunakan prompt yang cukup panjang yang saya susun untuk keperluan ringkasan.

[heycalmdown]

Saya sangat setuju dengan konsepnya, jadi saya sempat mencoba mengujinya di proyek baru pada akhir pekan, tetapi hasilnya tidak berjalan sebaik yang saya bayangkan. Sepertinya masih perlu banyak perbaikan. Untuk sementara, alur kerjanya secara garis besar, seperti yang sudah beberapa kali diperkenalkan, adalah sebagai berikut:
menulis constitution → menulis spec → menulis task → implementasi

Masalahnya adalah:

• file constitution.md adalah panduan inti tentang "bagaimana pengembangan akan dilakukan", tetapi tidak memuat "apa yang pada akhirnya akan menjadi aplikasi ini"
• spec.md adalah dokumen yang menjelaskan satu fitur
• tidak ada dokumen master tentang "aplikasi ini sebenarnya apa"
• setelah membaca diskusi yang berlangsung di GitHub, tampaknya kesimpulannya adalah chain of specs pada akhirnya akan menjadi source of truth. Agak membuat saya mengernyit, tetapi kurang lebih masih bisa saya pahami.
• melalui perintah /specify dan /tasaks, banyak dokumen dihasilkan sebagai output (yang sebenarnya memang saya inginkan), tetapi mungkin karena itu konteks cepat habis (saya memakai Claude Code)
• begitu mulai masuk ke tahap implementasi, saya untuk sementara menjauh dari Spec Kit dan akhirnya menyelesaikan implementasi seperti biasa melalui percakapan dengan Claude Code
• ketika konteks habis lalu dilakukan compaction atau memulai sesi baru, ia lupa akan keberadaan dokumen yang dibuat oleh Spec Kit
• saat menjalankan pekerjaan yang didefinisikan di tasks.md, kadang saya malah menimpa hal yang sebelumnya sudah dibuat dengan baik, dan dalam proses memperbaiki bug justru menambahkan fitur baru, sehingga makin lama makin menjauh dari tasks.md. Saya tidak paham apa gunanya menyimpan tasks.md secara permanen.

Untuk saat ini, kesimpulan yang saya ambil adalah sebagai berikut:

• meskipun hasilnya berbeda dari yang dipikirkan di awal, tetap selesaikan dulu spec-nya lalu buat spec baru untuk memperbaikinya sedikit demi sedikit
• spec awal pasti akan membesar, jadi mungkin lebih baik sama sekali tidak menjelaskan fitur aplikasi dan hanya membuat boilerplate
• saat membuat sesuatu pada level PoC, sepertinya lebih baik tidak menggunakan Spec Kit