BAB 3: Plan Mode — Dari Spec ke Blueprint
Cara kerja plan mode Claude Code untuk mengubah spesifikasi menjadi rencana implementasi teknis yang detail dan kontekstual
Spec yang sudah kamu review dan setujui di bab sebelumnya adalah dokumen niat — ia mendefinisikan apa yang ingin dibangun dari perspektif pengguna. Tapi spec belum menjawab pertanyaan yang paling penting bagi Claude: file mana yang perlu disentuh, komponen apa yang perlu dibuat, urutan perubahan apa yang paling aman? Menjawab pertanyaan-pertanyaan itu adalah tugas plan mode.
Plan mode adalah mode khusus di Claude Code yang memisahkan fase riset dari fase eksekusi. Saat aktif, Claude tidak akan menulis satu baris kode pun — ia hanya membaca, menganalisis, dan menyusun rencana. Hasilnya adalah file plan.md yang menjadi blueprint implementasi: lengkap dengan contoh kode, struktur file yang diusulkan, dan penjelasan di balik setiap keputusan teknis.
Mengaktifkan Plan Mode
Cara masuk ke plan mode adalah dengan menekan Shift+Tab dua kali dari layar Claude Code yang sedang berjalan. Setiap kali Shift+Tab ditekan, mode bersepeda: dari mode normal ke auto-accept edits, lalu ke plan mode. Kamu tahu sudah berada di plan mode ketika ada indikator hijau di bagian bawah antarmuka.
Untuk keluar dari plan mode dan kembali ke mode normal, tekan Shift+Tab sekali lagi.
Sejak versi 2.1.0+, kamu juga bisa menggunakan perintah /plan langsung dari input untuk masuk ke plan mode tanpa perlu menghafal urutan tombol.
Setelah plan mode aktif, cara memberikan instruksi paling efektif adalah dengan membuka file spec yang sudah dibuat, lalu kirim perintah singkat: plan the feature described in this spec. Dengan file spec terbuka, Claude otomatis mendapatkannya sebagai konteks — kamu tidak perlu menyalin isi spec ke prompt.
Yang Terjadi Saat Plan Dibuat
Begitu kamu menekan enter, Claude tidak langsung menulis rencana. Ia terlebih dahulu mendelegasikan pekerjaan riset ke sebuah Plan Subagent — proses terpisah yang tugasnya adalah mengumpulkan informasi sebanyak mungkin tentang kodebasis sebelum rencana disusun.
Plan Subagent ini bisa menggunakan tools seperti Read, Glob, Grep, dan WebFetch untuk membaca file, mencari pola, dan mengumpulkan konteks. Untuk proyek yang besar, ia mungkin juga memanggil Explore Subagent — subagent yang lebih ringan dan cepat, berbasis model Haiku, yang dioptimalkan untuk memetakan struktur kode tanpa menghabiskan banyak token di konteks utama.
Selama proses ini berlangsung, Claude mungkin meminta izin untuk menjalankan perintah seperti ls atau membaca file tertentu. Berikan izin selama permintaannya masuk akal — semakin banyak konteks yang dikumpulkan, semakin akurat rencana yang dihasilkan.
Yang membuat plan mode berbeda dari sekadar “tanya Claude di chat” adalah ini: rencana yang dihasilkan bukan dibuat dari nol berdasarkan pengetahuan umum. Claude sudah membaca proyek kamu terlebih dahulu. Ia tahu kalau kamu sudah punya class .button di CSS. Ia tahu pola penamaan file yang kamu gunakan. Ia tahu library apa yang sudah terinstal. Rencana yang keluar adalah rencana yang disesuaikan dengan situasi proyek kamu — bukan template generik.
Anatomi File Plan
Setelah proses selesai, Claude menyimpan file plan ke direktori plan yang dikonfigurasi. Secara default, lokasi ini adalah ~/.claude/plans/ di home directory komputermu — bukan di dalam folder proyek. Jika kamu ingin menyimpannya di dalam proyek (yang lebih disarankan agar bisa di-commit bersama spec), kamu bisa mengonfigurasi lokasi custom melalui settings.json:
// ~/.claude/settings.json
{
"plansDirectory": "~/.claude/plans"
}Atau, yang lebih praktis: saat Claude menanyakan apakah ingin langsung diimplementasikan, jawab “tidak” dan minta ia menyimpan plan ke folder spesifik di dalam proyek, misalnya _plans/. Cara ini lebih mudah daripada mengedit konfigurasi.
Isi file plan biasanya mencakup beberapa bagian:
Overview berisi ringkasan tujuan implementasi — parafrase dari spec yang sudah kamu setujui, tapi kali ini dari sudut pandang teknis.
Critical Files adalah daftar file yang perlu dibuat dan file yang perlu dimodifikasi, lengkap dengan alasan singkat mengapa file tersebut terlibat.
Implementation Steps adalah inti dari plan — urutan langkah yang perlu dilakukan, masing-masing disertai contoh kode, pendekatan styling yang diusulkan, dan keputusan teknis yang diambil.
Design Decisions menjelaskan mengapa Claude memilih pendekatan tertentu. Ini bagian yang sering dilewatkan tapi sebenarnya sangat berharga — kamu bisa tidak setuju dengan keputusan tertentu dan menggantinya sebelum implementasi dimulai.
Technical Considerations mencakup hal-hal seperti TypeScript interfaces yang perlu dibuat, accessibility requirements, dan konvensi yang perlu diikuti — biasanya Claude mengambil ini dari CLAUDE.md kalau ada.
Membaca Plan dengan Kritis
Plan yang dihasilkan Claude biasanya panjang. Sangat panjang. Melewatinya dengan cepat bukan pilihan yang baik — justru ini adalah momen paling berharga dalam seluruh workflow sebelum kode ditulis.
Luangkan waktu 10 sampai 20 menit untuk membaca plan secara menyeluruh. Yang perlu dicek:
Pertama, apakah komponen baru yang diusulkan memang perlu dipisah, atau bisa digabung? Plan mode cenderung membuat abstraksi yang granular. Kadang ini tepat; kadang ini over-engineering untuk kebutuhan yang sebenarnya sederhana.
Kedua, apakah urutan implementation steps masuk akal? Kalau step 4 bergantung pada hasil step 6, itu masalah — Claude yang mengeksekusi bisa bingung atau membuat keputusan yang tidak diinginkan.
Ketiga, apakah ada keputusan teknis di Design Decisions yang tidak sesuai dengan ekspektasi kamu? Misalnya: Claude memutuskan untuk menggunakan React.useState untuk form state, tapi kamu sebenarnya ingin menggunakan library form management seperti react-hook-form. Ganti sekarang — jauh lebih murah daripada mengoreksi setelah kode sudah ditulis.
Plan yang tidak dibaca dengan seksama sama bahayanya dengan tidak punya plan sama sekali. Jika kamu langsung menekan “implementasikan sekarang” tanpa membaca, kamu hanya memindahkan masalah dari fase implementasi ke fase review — dan biaya mengoreksi kode yang sudah jadi jauh lebih tinggi.
Memodifikasi Plan Sebelum Eksekusi
Salah satu keunggulan terbesar plan mode adalah plan yang dihasilkan adalah file biasa yang bisa kamu edit. Tidak ada lock, tidak ada format khusus yang tidak boleh diubah.
Kalau ada bagian yang tidak sesuai, edit langsung. Hapus langkah yang tidak diperlukan. Tambahkan catatan untuk langkah tertentu. Ganti nama komponen yang diusulkan. Tambahkan constraint yang lupa disebutkan di spec.
Claude akan membaca plan yang sudah dimodifikasi saat diminta mengeksekusi — bukan versi asli yang ia buat. Jadi setiap perubahan yang kamu buat langsung berpengaruh ke implementasi.
Menyimpan Plan ke Sejarah Git
Sebelum melanjutkan ke implementasi, ada satu kebiasaan yang sangat disarankan: commit spec dan plan ke Git terlebih dahulu.
git add _specs/authentication-forms.md _plans/authentication-forms.md
git commit -m "docs: add spec and plan for authentication forms"Alasannya sederhana. Implementasi tidak selalu berjalan mulus — kadang kode yang dihasilkan merusak sesuatu yang tidak diinginkan, atau ada keputusan teknis yang belakangan terasa salah. Dengan spec dan plan sudah di-commit, kamu bisa git reset --hard ke commit tersebut dan mulai ulang dengan plan yang sudah direvisi, tanpa kehilangan pekerjaan dokumentasi yang sudah dilakukan.
Ini adalah checkpoint yang bersih: kamu punya apa yang ingin dibangun (spec) dan bagaimana cara membangunnya (plan), keduanya sudah terverifikasi dan tersimpan. Implementasi yang dimulai dari titik ini punya landasan yang jauh lebih kokoh.
Latihan
Tiga latihan berikut dirancang untuk memperdalam pemahaman tentang plan mode. Latihan pertama cukup sederhana; yang ketiga membutuhkan pemikiran lebih.
-
Aktifkan plan mode, lalu kirim prompt tanpa membuka file spec terlebih dahulu. Bandingkan kualitas plan yang dihasilkan dengan plan yang dibuat saat file spec disertakan sebagai konteks. Apa yang berbeda?
-
Buka file plan yang sudah dihasilkan dan identifikasi minimal satu keputusan teknis di bagian Design Decisions yang bisa kamu perdebatkan. Modifikasi plan untuk mencerminkan pendekatan yang kamu inginkan, lalu simpan.
-
Spec yang ditulis dengan baik biasanya menghasilkan plan yang lebih akurat dan lebih sedikit membutuhkan koreksi manual. Coba buat dua plan untuk spec yang sama — satu dari spec yang minim detail, satu dari spec yang lengkap dengan edge cases dan acceptance criteria. Bandingkan hasilnya.
Dengan spec dan plan yang sudah siap dan tersimpan di Git, kamu punya semua yang dibutuhkan untuk mulai mengeksekusi. Tapi sebelum menekan “go”, ada satu lapisan lagi yang akan membuat implementasi jauh lebih terkontrol: memecah plan menjadi tugas-tugas atomik yang bisa dilacak satu per satu. Itulah yang akan dikerjakan selanjutnya dengan tasks.md.