BAB 2: Membuat Spec Pertama

Di bab sebelumnya, kita membangun semua fondasi yang diperlukan: command /spec, folder _specs/, dan template yang menjadi acuan struktur. Tapi setup itu belum pernah benar-benar diuji. Sekarang saatnya menjalankan command tersebut untuk pertama kali, dan melihat apa yang sebenarnya terjadi saat Claude Code mulai menulis spesifikasi dari deskripsi singkat.

Ada satu hal yang perlu diingat: setelah membuat atau memodifikasi file command, kamu perlu keluar dari sesi Claude Code dan membukanya kembali. Claude Code membaca daftar available commands saat startup — perubahan yang dibuat saat sesi berjalan tidak akan langsung terdeteksi.

Menulis Prompt yang Tepat

Kualitas spec yang dihasilkan sangat bergantung pada kualitas input yang kamu berikan. Tapi “kualitas” di sini bukan berarti panjang atau detail — justru sebaliknya.

Prompt yang baik untuk /spec cukup menjawab tiga pertanyaan: apa yang ingin dibangun, di mana lokasinya dalam proyek, dan batasan apa yang berlaku. Tidak perlu menjelaskan cara implementasinya — itulah yang akan ditentukan di tahap planning nanti.

Ambil contoh fitur authentication forms. Alih-alih menulis:

/spec tambahkan form login dengan React menggunakan useState untuk menyimpan
nilai email dan password, ada button submit yang memanggil fungsi handleSubmit,
dan tombol eye untuk toggle visibility password

Cukup tulis:

/spec tambahkan authentication forms pada halaman login dan signup.
Perlu ada field email, password dengan hide/show icon, dan tombol submit.
Form cukup log ke console untuk sekarang. Harus bisa beralih antara login dan signup.

Versi kedua lebih pendek tapi jauh lebih berguna. Kamu mendefinisikan apa yang dibutuhkan dari perspektif pengguna, bukan bagaimana implementasinya. Claude yang akan menerjemahkan kebutuhan itu ke keputusan teknis — dan memverifikasi terjemahannya adalah pekerjaan kamu setelah spec selesai dibuat.

Proses yang Berjalan di Balik Layar

Setelah kamu menekan enter, Claude tidak langsung menulis spec. Ia menjalankan instruksi di spec.md secara berurutan.

Langkah pertama adalah mengecek status Git. Claude akan menjalankan git status dan memastikan tidak ada perubahan yang belum di-commit. Kalau ada, proses berhenti dan kamu diminta untuk menyelesaikannya dulu — entah dengan git stash atau membuat commit. Ini proteksi penting: kita tidak mau spec baru bercampur dengan perubahan yang belum selesai.

Jika branch bersih, Claude mengekstrak tiga nilai dari input kamu: feature title (nama yang mudah dibaca), feature slug (versi kebab-case), dan branch name dengan format claude/feature/<slug>. Dari contoh authentication forms tadi, hasilnya kira-kira:

• Feature title: Authentication Forms
• Feature slug: authentication-forms
• Branch name: claude/feature/authentication-forms

Setelah itu, Claude berpindah ke branch baru menggunakan git checkout -b claude/feature/authentication-forms, lalu menulis file spec di _specs/authentication-forms.md.

Membaca Spec yang Dihasilkan

File spec yang baru dibuat punya lima bagian utama. Memahami fungsi masing-masing bagian membantu kamu tahu di mana harus memberikan perhatian lebih.

Summary adalah parafrase dari deskripsi yang kamu berikan. Claude biasanya memperluas sedikit — menambahkan konteks yang dianggap implisit. Cek bagian ini dulu: kalau ada framing yang berbeda dari yang kamu maksud, koreksi sekarang sebelum lanjut.

Functional Requirements adalah daftar perilaku yang harus ada. Ini yang paling sering perlu ditambah atau dipangkas. Cek setiap item: apakah requirement itu memang perlu ada di fitur ini? Apakah ada requirement yang hilang karena tidak disebutkan secara eksplisit di prompt?

Edge Cases berisi skenario yang perlu dipikirkan tapi sering terlewat saat menulis prompt awal. Contohnya: apa yang terjadi kalau user submit form dengan email kosong? Apa yang terjadi kalau user toggle visibility password berkali-kali cepat? Edge case yang teridentifikasi di sini jauh lebih murah ditangani daripada yang ditemukan saat testing.

Acceptance Criteria adalah daftar kondisi yang harus terpenuhi agar fitur dianggap selesai. Berbeda dengan requirements yang mendefinisikan apa yang dibangun, acceptance criteria mendefinisikan kapan kita bisa bilang “ini sudah done”. Pastikan setiap kriteria konkret dan bisa diverifikasi — hindari kriteria seperti “UI terlihat bagus” yang tidak punya definisi jelas.

Open Questions adalah bagian paling berharga yang sering dilewati begitu saja. Ini adalah pertanyaan yang Claude identifikasi sebagai ambigu atau belum terjawab dalam input kamu.

Menjawab Open Questions

Untuk authentication forms, Claude mungkin mengajukan pertanyaan seperti:

• Haruskah ada validasi format email sebelum submit?
• Haruskah ada minimum panjang password?
• Apakah input form harus dipertahankan saat berpindah antara login dan signup?
• Perlu tombol “Remember me”?
• Perlu link “Forgot password”?

Kamu tidak harus menjawab semuanya secara formal. Cukup edit langsung file spec dan ubah bagian Open Questions menjadi keputusan yang sudah diambil. Misalnya: ubah “Haruskah ada validasi format email?” menjadi catatan “Validasi ringan di frontend, validasi ketat di backend nanti.” Atau hapus pertanyaan yang sudah jelas jawabannya (tidak perlu “Remember me” atau “Forgot password” untuk sekarang).

Waktu yang Perlu Diluangkan

Proses membaca dan mengedit spec membutuhkan waktu. Lima sampai sepuluh menit adalah minimum yang wajar — bukan karena spec yang dihasilkan biasanya jelek, tapi karena kamu perlu memastikan setiap bagian mencerminkan niatmu, bukan asumsi Claude.

Perhatian ekstra layak diberikan pada Acceptance Criteria. Kriteria yang terlalu longgar membuat kamu tidak punya dasar untuk mengatakan implementasi sudah selesai. Kriteria yang terlalu ketat bisa membuat Claude menghabiskan waktu untuk hal-hal yang sebenarnya tidak penting. Temukan keseimbangan yang tepat.

Setelah spec selesai di-review dan dikoreksi, kamu punya dokumen yang benar-benar merepresentasikan apa yang ingin dibangun. Bukan interpretasi Claude, bukan draft awal yang belum dikonfirmasi — tapi niat yang sudah tertulis eksplisit.

Spec inilah yang menjadi input untuk tahap berikutnya: menerjemahkannya menjadi rencana implementasi teknis. Tapi “menerjemahkan” di sini bukan pekerjaan sederhana — ada keputusan arsitektur, pemilihan file yang perlu dimodifikasi, dan urutan perubahan yang harus dipikirkan. Itulah yang akan kita kerjakan selanjutnya, menggunakan Claude Code’s plan mode untuk mengubah spec yang sudah disetujui menjadi blueprint implementasi yang bisa langsung dieksekusi.