GitHub Spec Kit: Panduan Lengkap Spec-Driven Development buat Coding Agent

Kalau kamu pernah ngerasain agent nulis fitur ketiga sambil ngerusak fitur pertama, kamu udah ketemu masalah yang mau diselesaikan Spec Kit. Toolkit open source dari GitHub ini nggak nambah model baru dan nggak ganti editor kamu. Yang dia ubah cuma satu: urutan kerjanya. Spesifikasi ditulis duluan, kode nyusul belakangan.

Ide ini sendiri bukan barang baru — kita udah bahas di vibe coding vs spec-driven development. Yang baru adalah ada perkakas resmi yang bikin alurnya konkret. GitHub merilis Spec Kit pada September 2025, dan adopsinya meledak sepanjang 2026 — sekarang reponya sudah lewat 125 ribu bintang.

Spec Kit itu apa, sebenarnya

Spec Kit menyebut dirinya harness berbasis maksud yang mendorong coding agent apa pun keluar dari sekadar nulis kode, dan menuntun dia melewati seluruh siklus pengembangan. Praktisnya: dia nambahin serangkaian perintah ke agent yang udah kamu pakai, lalu tiap perintah menghasilkan berkas Markdown yang jadi bahan tahap berikutnya.

Poin pentingnya, artefaknya Markdown biasa yang kamu commit ke repo. Bukan format rahasia, bukan basis data. Jadi bisa dibaca manusia, bisa di-review lewat pull request, dan bisa dipindah antar agent. Dokumentasinya nyebut 35 integrasi termasuk Copilot, Claude, Gemini, Codex, dan Zed, plus satu integrasi generik buat perkakas yang belum terdaftar.

Pasang dan mulai proyek

Pemasangannya lewat uv. Ganti bagian versinya dengan tag rilis terbaru, dan awalan huruf v-nya jangan dihapus:

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

specify init my-project --integration copilot
cd my-project

Bagian --integration diisi nama agent yang kamu pakai. Kamu bisa ganti agent belakangan lewat perintah, jadi nggak terkunci ke satu vendor. Spec Kit juga jalan offline dan di belakang firewall, yang biasanya jadi syarat mati di kantor yang ketat.

Alur perintahnya, satu per satu

Alur intinya empat tahap: spec, plan, tasks, implement. Tapi perintah yang tersedia lebih dari itu, dan yang opsional justru sering paling menyelamatkan.

Perintah inti

• /speckit.constitution — bikin atau perbarui prinsip dan pedoman pengembangan proyek. Ini yang bikin agent punya aturan main tetap, bukan aturan yang berubah tiap sesi.
• /speckit.specify — jelaskan APA yang mau dibangun: kebutuhan dan user story. Tahap ini sengaja belum ngomongin teknologi.
• /speckit.plan — baru di sini teknologinya dipilih, dan rencana teknisnya disusun.
• /speckit.tasks — pecah rencana jadi daftar tugas yang bisa dikerjakan satu-satu.
• /speckit.implement — jalankan semua tugas sesuai rencana.
• /speckit.taskstoissues — ubah daftar tugas jadi GitHub issue kalau kamu mau melacaknya di sana.
• /speckit.converge — nilai kondisi kode sekarang terhadap spec, plan, dan tasks, lalu tambahkan sisa pekerjaannya.

Perintah opsional yang sebaiknya nggak kamu lewati

• /speckit.clarify — memperjelas bagian yang masih kabur. Dokumentasinya menyarankan ini dijalankan SEBELUM /speckit.plan, dan saran itu ada alasannya.
• /speckit.analyze — cek konsistensi dan cakupan antar artefak, jadi spec, plan, dan tasks nggak saling bertentangan.
• /speckit.checklist — bikin daftar periksa buat memastikan kebutuhannya udah lengkap.

Satu catatan soal /speckit.constitution: isinya sering tumpang tindih dengan berkas instruksi repo yang mungkin sudah kamu punya. Kalau repo kamu sudah pakai AGENTS.md, tentukan satu yang jadi sumber asli dan biarkan yang lain menunjuk ke sana — jangan dua-duanya diisi aturan lengkap, karena dalam beberapa minggu isinya pasti mulai beda dan nggak ada yang sadar.

Satu batasan yang jarang disebut

Ini bagian yang perlu jujur. Spec Kit ngasih kamu prosesnya, bukan isinya. Dia tahu urutan yang benar, tapi dia nggak tahu produk kamu.

Waktu kamu ketik /speckit.specify, yang dia terima tetap deskripsi dari kepala kamu. Kalau deskripsinya cuma "bikin aplikasi kasir", spec yang keluar bakal kelihatan rapi tapi isinya tebakan agent soal kasir pada umumnya — bukan kasir yang kamu maksud. Rapi tapi salah itu lebih berbahaya daripada berantakan tapi jelas, karena kesalahannya jadi susah kelihatan.

Gejalanya gampang dikenali: hasil /speckit.plan kelihatan meyakinkan, tapi waktu kamu baca acceptance criteria-nya kamu nggak bisa jawab "ini bener nggak?" karena kamu sendiri belum pernah mikirin sedetail itu. Cara benerinnya bukan ngulang perintahnya, tapi memperjelas masukannya.

Di mana PRD masuk ke alur ini

Di sini posisi kami perlu jelas: Skematik produk kami sendiri, dan Spec Kit gratis serta open source. Keduanya bukan barang yang saling menggantikan, dan kami nggak mau pura-pura begitu.

Yang kami lihat berguna: /speckit.specify jauh lebih bagus hasilnya kalau yang kamu tempel ke sana bukan satu kalimat, tapi dokumen yang udah memaksa kamu memutuskan hal-hal yang biasanya kelewat — siapa penggunanya, apa yang dihitung sukses, apa yang di luar lingkup, dan kasus apa yang harus ditolak sistem. Itu isi PRD, dan cara nyusunnya kami tulis di cara membuat PRD untuk aplikasi.

Kalau kamu mau nyusunnya manual, silakan — hasilnya sama saja asal keputusannya benar-benar kamu ambil. Yang penting bukan alatnya, tapi bahwa waktu agent nanya "apa yang harus dibangun", jawabannya udah ada dan udah dipikirin, bukan dikarang di tempat.

Kapan Spec Kit malah bikin lambat

• Skrip sekali pakai. Kalau hasilnya bakal kamu buang minggu depan, tujuh tahap itu ongkos yang nggak balik.
• Eksplorasi bentuk fitur. Waktu kamu belum tahu mau apa, nulis spesifikasi malah mengunci tebakan yang belum teruji. Vibe coding dulu, baru rapikan.
• Perbaikan satu baris. Nggak semua perubahan butuh konstitusi proyek.

Titik balik biasanya sama: begitu kamu mulai takut nyentuh kode yang kemarin jalan, atau begitu ada orang kedua yang ikut ngerjain. Di situ proses tertulis mulai lebih murah daripada mengulang penjelasan.

Ringkasnya

1. Pasang lewat uv, lalu specify init dengan agent pilihan kamu.
2. Mulai dari /speckit.constitution supaya aturan mainnya tetap.
3. Tulis kebutuhannya di /speckit.specify — dan pastikan masukannya sudah matang, bukan satu kalimat.
4. Jalankan /speckit.clarify sebelum /speckit.plan. Ini yang paling sering diskip dan paling sering bikin nyesel.
5. Lanjut /speckit.plan, /speckit.tasks, baru /speckit.implement.
6. Pakai /speckit.analyze kalau artefaknya mulai banyak dan kamu curiga ada yang bertentangan.