# Plan Mode di Claude Code: Panduan Langkah demi Langkah dan 4 Fase pada 2026 > Plan Mode di Claude Code: apa itu, cara mengaktifkannya dengan Shift+Tab, 4 fase Anthropic, templat prompt siap pakai, dan perintah /goal untuk tugas otonom semalaman. Source: https://ailoot.ai/blog/id/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/id/claude-code-plan-mode/ Language: id Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-a9454c08762263c302c81cd820f1c0403bc22478dfb85972897f2db30f5a6955 Petunjuk tambahan tersedia di [dokumentasi Ailoot](https://ailoot.ai/docs/). ## Apa itu Plan Mode, dan mengapa mode ini saja tidak cukup?
Poin utama Plan Mode di Claude Code adalah mode ketika AI membaca file, menganalisis kode, dan mengusulkan rencana perubahan, tetapi tidak menulis apa pun sampai Anda menyetujuinya. Mode ini diaktifkan dengan menekan Shift+Tab dua kali atau menggunakan flag `--permission-mode plan`. Mode ini berguna ketika pendekatan belum pasti, kode belum familier, atau perubahan membawa risiko lintas file atau operasional yang berarti. Perbaikan salah ketik yang jelas dan berisiko rendah biasanya tidak memerlukan fase perencanaan terpisah.
Dalam mode normal, Claude Code langsung menulis kode, dan jika Anda tidak mengawasinya, Anda bisa tiba-tiba mendapatkan diff yang mencakup banyak file. Plan Mode membalik urutannya: pertama riset dan perencanaan, lalu persetujuan, kemudian perubahan. Anthropic menjelaskan Plan Mode dalam dokumentasi resminya sebagai berikut:

Plan mode memerintahkan Claude untuk meneliti dan mengusulkan perubahan tanpa menerapkannya. Claude membaca file, menjalankan perintah shell untuk melakukan eksplorasi, dan menulis rencana, tetapi tidak mengedit kode Anda.

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
Kedengarannya sederhana, tetapi perubahan utamanya sering luput. Plan Mode mengubah ritme kerja: sepakati dulu, baru bertindak. Ini perubahan mode, bukan penyesuaian kosmetik. Masalah bagi vibe coder adalah agen AI cenderung terburu-buru. Jika Anda meminta, “Tambahkan autentikasi Google,” dalam mode normal Claude akan menulis kode dalam satu menit, tetapi separuh filenya akan salah. Dalam Plan Mode, permintaan yang sama menjadi rencana tertulis yang bisa Anda baca dalam dua menit dan koreksi sebelum kode apa pun disentuh. Ada jebakan yang tidak dibahas dalam panduan internasional. Plan Mode saja adalah alat yang lemah: rencana hanya ada dalam percakapan saat ini. Tutup jendelanya, dan rencana itu hilang. Anda tidak bisa menyerahkannya kepada agen lain. Tidak ada versi atau riwayat. Jika tugasnya besar (memfaktorkan ulang modul berisi 30 file, bermigrasi ke basis data baru), rencana itu akan segera mencapai batas jendela konteks dan mulai menurun kualitasnya. Itulah sebabnya Plan Mode cocok dipadukan dengan folder `plans/` di repositori. Rencana disimpan sebagai `plans/2026-05-21-google-oauth.md`, dipecah menjadi beberapa fase dengan kotak centang, dan agen berikutnya bisa melanjutkannya. Begitulah [rekayasa konteks](https://ailoot.ai/blog/id/context-engineering/) bekerja—mengelola konteks sebelum prompt, bukan saat prompt berlangsung. ## Bagaimana cara mengaktifkan Plan Mode di Claude Code?
Poin utama Ada empat cara resmi untuk mengaktifkan Plan Mode. Saat sesi berlangsung, tekan Shift+Tab dua kali atau letakkan awalan `/plan` sebelum prompt. Saat meluncurkan sesi, gunakan flag `claude --permission-mode plan`. Secara global, atur field `defaultMode` di `.claude/settings.json`. Indikator mode aktif adalah `⏸ plan mode on` di bagian bawah terminal.
Cara tercepat selama sesi berlangsung adalah menggunakan keyboard: ``` Shift+Tab # cycles through modes: default → acceptEdits → plan ``` Setelah ditekan dua kali, indikator `⏸ plan mode on` akan muncul di bagian bawah terminal. Tekan ketiga kalinya untuk kembali ke mode normal. Ini cara yang paling praktis—Anda bisa mengaktifkannya sewaktu-waktu saat melihat tugas mulai membesar. Cara kedua adalah menambahkan awalan sebelum satu prompt: ``` /plan write a plan to migrate the database from MySQL to Postgres ``` Opsi ini berguna jika Anda berada dalam mode auto-accept dan tidak ingin mengubahnya untuk seluruh sesi. Satu permintaan dalam Plan Mode, lalu pekerjaan berlanjut seperti biasa. Cara ketiga adalah saat meluncurkan sesi: ```bash claude --permission-mode plan ``` Gunakan cara ini jika Anda sudah tahu sebelumnya bahwa tugas memerlukan perencanaan. Misalnya, sebelum refaktor besar atau migrasi. Cara keempat adalah menetapkan mode default di `.claude/settings.json` dalam proyek: ```json { "permissions": { "defaultMode": "plan" } } ``` Kapan cara ini berguna? Saat tim mengerjakan sistem yang rumit dan perubahan apa pun bisa berdampak pada modul terkait. Dalam situasi itu, Plan Mode sebagai mode default melindungi semua orang dari perubahan yang tidak disengaja. Trik kelima yang sering terlewat: `Ctrl+G` membuka rencana di editor teks. Gunakan saat rencananya hampir tepat, tetapi Anda perlu merumuskan ulang 2-3 poin atau menambahkan batasan. Edit secara manual, simpan, dan Claude akan melanjutkan dengan versi Anda. ## Apa saja 4 fase kanonis Anthropic dalam Plan Mode: Explore, Plan, Implement, Commit?
Poin utama Dalam panduan praktik terbaiknya, Anthropic menyebut alur kerja kanonis yang terdiri dari empat fase: Explore (membaca file dan menjelajahi konteks), Plan (membuat rencana perubahan tanpa mengedit), Implement (beralih ke mode normal dan menerapkan rencana), Commit (membuat commit dengan pesan deskriptif dan PR). Setiap fase memiliki pembatasan alatnya sendiri.
Banyak panduan menjelaskan 3 fase (Explore-Plan-Execute) atau hanya 2 (Plan-Implement). Itu penyederhanaan. Dalam [panduan praktik terbaik resmi](https://www.anthropic.com/engineering/claude-code-best-practices), Anthropic menjelaskan tepat 4 fase. Perbedaannya penting: Commit sebagai fase tersendiri membuat Anda mencatat hasilnya alih-alih berhenti pada “saya membuat beberapa penyesuaian lagi di sini, nanti saya commit”—penyebab paling umum hilangnya pekerjaan. Semakin tepat rencananya, semakin sedikit iterasi yang diperlukan saat implementasi. Jika Anda menghabiskan 10 menit untuk rencana, implementasi cukup dengan satu prompt. Jika Anda menyusun rencana dalam satu menit, implementasi akan memerlukan satu jam perbaikan. Berikut gambaran 4 fase untuk menambahkan Google OAuth (contoh dari Anthropic Docs): | Fase | Yang dilakukan Claude | Yang Anda lakukan | Mode | |----|----|----|----| | **Explore** | Membaca `/src/auth`, mencari tahu cara sesi dan variabel lingkungan ditangani | Menentukan cakupan eksplorasi | Plan Mode | | **Plan** | Membuat rencana: file mana yang diubah, file baru mana yang dibuat, dan apa risikonya | Membaca rencana, mengeditnya dengan Ctrl+G, dan menyetujuinya | Plan Mode | | **Implement** | Menerapkan rencana, menulis kode alur OAuth, tes, dan callback | Memantau setiap perubahan saat diterapkan | Default atau acceptEdits | | **Commit** | Membuat commit dengan deskripsi dan membuka Pull Request | Memeriksa pesannya dan meninjau PR | Default | Prompt di setiap fase juga berbeda. Dalam Explore: “baca /src/auth dan pahami cara kita menangani sesi dan login”. Dalam Plan: “Saya ingin menambahkan Google OAuth. File mana yang perlu diubah? Buat rencana”. Dalam Implement: “terapkan alur OAuth dari rencana Anda, tulis tes, jalankan suite dan perbaiki kegagalan”. Dalam Commit: “buat commit dengan pesan deskriptif dan buka PR”. Nuansa penting: Plan Mode tidak mencegah Claude menjalankan perintah untuk riset. Read, LS, Glob, Grep, web fetch, dan perintah shell untuk eksplorasi diperbolehkan. Hanya Edit, Write, dan semua operasi sistem file yang memutasi data yang dilarang. Artinya, Claude dapat membaca struktur proyek, menjalankan `git log`, dan melihat tes—tetapi tidak akan bisa mengubah apa pun secara tidak sengaja. ## Bagaimana cara membaca rencana Claude dan memutuskan apakah akan menyetujuinya?
Poin utama Rencana Claude yang baik memuat daftar file spesifik dan perubahan yang harus dilakukan, urutan langkah, risiko yang dinyatakan secara jelas, serta kriteria keberhasilan. Rencana yang buruk menggunakan frasa umum seperti “Saya akan memperbarui modul auth” tanpa rincian. Gunakan 7 tanda di bawah ini untuk memutuskan apakah akan menyetujuinya. Sempurnakan dengan masukan atau edit langsung menggunakan Ctrl+G.
Setelah Claude selesai membuat rencana, Claude menampilkan pilihan untuk langkah berikutnya: - Setujui dan mulai dalam mode otomatis - Setujui dan terima pengeditan - Setujui dan tinjau setiap pengeditan secara manual - Lanjutkan perencanaan dengan masukan - Sempurnakan dengan Ultraplan (tinjauan melalui browser) Kemampuan menilai apakah rencana perlu disetujui adalah keterampilan utama dalam Plan Mode. Mudah sekali menekan “Approve” secara otomatis, lalu harus membatalkan commit. AI penjilat ingin memberi jawaban cepat, dan Anda ingin segera masuk ke kode. Kalian berdua keliru. Rencana yang baik memenuhi 7 kriteria: 1. **Nama file yang spesifik.** Bukan “Saya akan memperbarui auth,” melainkan “Saya akan mengubah `src/auth/login.ts:42-58`, membuat `src/auth/oauth-callback.ts`, dan memperbarui `src/auth/session.ts:103`.” 2. **Urutan dijelaskan.** Rencana dibagi menjadi fase atau langkah, bukan “Saya akan mengerjakan semuanya entah di mana.” 3. **Dependensi eksternal disebutkan.** Jika tugas memerlukan pustaka baru, cantumkan. Jika memerlukan variabel lingkungan, cantumkan. 4. **Risiko dicantumkan.** Rencana yang baik menyatakan, “Migrasi dapat merusak sesi yang ada; X perlu diperiksa.” Rencana yang buruk tidak menyebut dampak samping. 5. **Ada kriteria keberhasilan.** “Tes `test/auth` lulus, linter bersih, dan server dev berjalan tanpa kesalahan.” 6. **Tidak ada asumsi yang “dikarang begitu saja”.** Jika Claude mengatakan “Saya akan menggunakan pustaka Z,” periksa: apakah pustaka itu sudah dipasang di proyek? Jika AI mengarangnya, Anda akan melihat bahwa pustaka tersebut tidak disebutkan di `package.json`. 7. **Rencana muat di layar.** Jika rencana Claude terdiri dari 200 baris untuk fitur sederhana, tugas itu mungkin terlalu besar untuk satu rencana. Pecah menjadi beberapa bagian. Jika rencana gagal dalam pemeriksaan, ada tiga pilihan: - **Lanjutkan perencanaan dengan masukan**—berikan komentar spesifik kepada Claude tentang hal yang tidak Anda sukai, lalu Claude akan menulis ulang rencana. - **Ctrl+G**—buka rencana di editor, edit secara manual, lalu simpan. Claude akan melanjutkan dengan versi Anda. - **Sempurnakan dengan Ultraplan**—rencana dibuka dalam mode browser Claude Code di web, sehingga Anda dapat meninjau bagian dan memberi komentar, lalu menjalankannya secara lokal atau di cloud. Jika ada yang keliru di tengah implementasi, jangan memaksakannya. Kembali ke Plan Mode dan tulis ulang rencana. Biayanya 10 kali lebih murah daripada membatalkan 40 commit nantinya. ## Plan Mode + folder `plans/`: kombinasi untuk konteks panjang
Poin utama Plan Mode saja hanya berfungsi dalam percakapan saat ini. Tutup jendelanya, dan rencana itu hilang. Folder `plans/YYYY-MM-DD-feature.md` di repositori mengubah rencana menjadi artefak yang bertahan lama: file berisi fase, kotak centang, dan status yang bisa dilanjutkan oleh agen berikutnya. Ini adalah peralihan dari “rencana dalam ingatan” ke “rencana dalam kode.”
Plan Mode adalah mode Claude Code. Folder `plans/` adalah metodologi yang dibangun di atasnya. Jika menggunakan Plan Mode tanpa folder, Anda akan mencapai batas setelah satu jam bekerja. Begini logikanya. Jendela konteks Claude adalah ingatan sesi. Jendela ini dapat menampung 1 juta token di Opus 4.7, tetapi itu adalah kapasitas seluruh percakapan Anda. Jika Anda merencanakan tugas rumit dalam satu percakapan, lalu meminta Claude menerapkannya, kemudian membahas bug, lalu hal lain, jendelanya akan “membengkak.” Claude mulai melupakan keputusan awal, mencampuradukkan konteks, dan mengajukan pertanyaan lagi. Solusinya adalah aturan emas: **satu tugas—satu percakapan**. Begini caranya: 1. **Percakapan 1—susun rencana.** Aktifkan Plan Mode, jelaskan tugasnya, dan Claude akan membuat rencana. Simpan rencana di `plans/2026-05-21-feature-name.md`. Tutup jendelanya. 2. **Percakapan 2—pecah menjadi fase.** Buka obrolan baru. Minta: “ambil `plans/2026-05-21-feature-name.md` dan pecah menjadi beberapa fase.” Simpan file yang sudah diperbarui. 3. **Percakapan 3—terapkan fase 1.** Buka obrolan baru. Minta: “terapkan Fase 1 dari `plans/2026-05-21-feature-name.md`, dan centang item setelah selesai.” Tutup jendelanya. 4. **Percakapan 4—terapkan fase 2.** Lakukan hal yang sama. Apa manfaatnya? Jendela konteks setiap percakapan tetap segar. Claude pada fase 3 tidak mengetahui detail fase 1, tetapi mengetahui rencananya karena file `plans/` tersimpan di repositori. Agen berikutnya (baik subagen, sesi baru, atau proses melalui `/goal`) dapat melanjutkan rencana tersebut. Perbandingan pendekatan: | Fitur | Plan Mode saja | Plan Mode + folder `plans/` | |----|----|----| | Ketahanan | Hanya di obrolan saat ini | Selamanya di repositori | | Serah terima ke agen lain | Tidak mungkin | `cat plans/file.md` | | Versi dan riwayat | Tidak ada | Melalui git diff | | Dukungan subagen | Hanya di sesi saat ini | Setiap fase → subagen tersendiri | | Kotak centang dan status | Teks saja | Kotak centang Markdown `[ ]` / `[x]` | | Ukuran rencana | Dibatasi oleh jendela | Ukuran apa pun | Setiap fitur memiliki file rencananya sendiri. Jika tiga bulan kemudian Anda perlu mengingat alasan memilih satu penyedia pembayaran daripada alternatifnya, Anda bisa membuka rencana terkait dan membaca riwayat keputusannya: apa yang dibahas, opsi apa yang dipertimbangkan, dan mengapa jalur itu yang dipilih. Ini adalah rencana kerja yang terus berkembang; dokumentasi statis menjadi usang dalam hitungan bulan. ## Bagaimana cara membuat Claude bekerja saat Anda tidur dengan Plan Mode dan /goal?
Poin utama `/goal` adalah siklus otonom yang telah dibicarakan Anthropic selama setahun. Perintah `/goal` muncul di Claude Code v2.1.139 (11 Mei 2026). Perintah ini menetapkan syarat penyelesaian, dan Claude mengerjakannya tanpa campur tangan manusia sampai syarat itu terpenuhi. Model evaluator kecil memeriksa setelah setiap giliran apakah syarat tersebut sudah terpenuhi.
Batasan utama sesi AI yang panjang bukanlah modelnya sendiri, melainkan orang yang menekan Enter. Setiap kali Claude mencapai akhir giliran, Claude menunggu jawaban Anda. `/goal` menghilangkan waktu tunggu itu. Sintaksnya sederhana: ```bash /goal all tests in test/auth pass and lint is clean, or stop after 20 turns ``` Syaratnya bisa mencapai 4000 karakter. Satu goal per sesi. Setelah setiap giliran, model mini Haiku melihat transkrip dan memutuskan: “syarat terpenuhi—selesai” atau “belum terpenuhi—giliran berikutnya.” Evaluator tidak memanggil alat; evaluator hanya membaca. Alias untuk menghapusnya: `/goal stop`, `/goal off`, `/goal reset`, `/goal none`, `/goal cancel`. Kombinasinya dengan Plan Mode seperti ini: 1. Aktifkan Plan Mode (tekan `Shift+Tab` dua kali). 2. Minta: “buat rencana untuk memigrasikan basis data dari MySQL ke Postgres, simpan ke `plans/2026-05-21-postgres-migration.md` dengan fase dan kriteria.” 3. Tinjau rencana, edit, lalu setujui. 4. Keluar dari Plan Mode (tekan `Shift+Tab` sekali lagi). 5. Tetapkan goal: “selesaikan semua fase dalam `plans/2026-05-21-postgres-migration.md`, centang kotak, semua tes lulus, atau berhenti setelah 50 giliran.” 6. Tutup laptop dan tidur. Paginya, periksa hasilnya: entah “✓ goal completed” atau “◎ stopped after 50 turns,” beserta riwayat pekerjaan yang dilakukan. Ada tiga aturan penting untuk `/goal`, kalau tidak Anda akan membuang-buang token: **Aturan 1: Kondisi akhir yang terukur.** “Buat tampilannya bagus” itu buruk. “`npm test` menghasilkan 0, `npm run lint` menghasilkan 0, dan entri telah ditambahkan ke `CHANGELOG.md`” itu bagus. **Aturan 2: Verifikasi eksplisit.** Syarat harus merujuk pada sesuatu yang bisa diverifikasi: perintah, file, atau endpoint. Bukan “semuanya berfungsi,” melainkan “curl localhost:3000/api/users mengembalikan 200.” **Aturan 3: Batasi jumlah giliran.** Selalu tambahkan `or stop after N turns`. Anthropic secara eksplisit merekomendasikan hal ini dalam dokumentasinya:

Untuk membatasi durasi goal, tambahkan klausa jumlah giliran atau waktu ke dalam syarat, misalnya, 'atau berhenti setelah 20 giliran'.

— Anthropic Docs, https://code.claude.com/docs/en/goal
Jika Anda mengaktifkan `/goal` tanpa `or stop after`, anggaran Anda bisa habis semalaman. ## Siklus 4 langkah apa yang mengubah Plan Mode menjadi proses rekayasa?
Poin utama Plan Mode sederhana tanpa struktur menghasilkan hasil biasa saja. Alur kerja yang kuat mengikuti 4 langkah dalam satu jendela: menetapkan fakta tanpa solusi, menyusun opsi dengan contoh terdahulu dari internet, membuat rencana terperinci dengan risiko 2-3 langkah ke depan, dan mewajibkan pemeriksaan mandiri atas asumsi yang “dikarang begitu saja” dalam rencana. Urutan ini menghalangi AI penjilat.
Kesalahan yang umum adalah bertanya “bagaimana cara memperbaikinya?”: Claude memberi solusi, Anda menerapkannya, tetapi tidak ada yang berhasil atau keadaan justru memburuk. Inilah “AI penjilat”: AI dilatih untuk menjawab dengan cepat, dan Anda ingin segera masuk ke kode. Siklus 4 langkah mengatasi masalah ini. Siklus 4 langkah ini menghalangi pola tersebut. Siklus ini digunakan secara berurutan dalam satu sesi Plan Mode: **Langkah 1. Tetapkan fakta tanpa solusi.** Prompt: “Saya mengalami hal berikut: \[deskripsi gejala\]. Tugas Anda sekarang adalah menetapkan fakta. Semua solusi, ide, dan saran dilarang. Hanya: apa yang saya amati, langkah apa yang dapat direproduksi, data apa yang tersedia, dan data apa yang belum ada. Syarat berhenti yang tegas: JANGAN mengusulkan solusi; hanya catat diagnosisnya.” Ini menghalangi dorongan pertama AI: “ini solusinya.” Claude harus berhenti pada “apa yang diketahui dan apa yang belum diketahui.” **Langkah 2. Susun opsi dengan contoh terdahulu.** Prompt: “Setelah diagnosis ditetapkan, cari contoh terdahulu di internet untuk menyelesaikan masalah serupa. Setidaknya 3 pendekatan berbeda. Untuk masing-masing: tautan ke sumber primer, deskripsi singkat, serta kelebihan dan kekurangannya untuk situasi kita.” Ini menghalangi dorongan kedua AI: “mengarang solusi begitu saja.” Kita memintanya mencari pendekatan yang bisa diperiksa di dunia nyata. **Langkah 3. Rencana terperinci dengan risiko.** Prompt: “Ambil opsi terbaik dari Langkah 2 dan susun rencana terperinci: file spesifik mana yang disentuh, apa yang ditambahkan, apa yang dihapus, tes apa yang ditulis, apa yang bisa rusak, dan risiko apa yang ada 2-3 langkah ke depan.” Ini adalah fase Plan yang sudah dikenal, tetapi dengan satu perbedaan: rencana didasarkan pada opsi terverifikasi dari Langkah 2, bukan tebakan Claude. **Langkah 4. Periksa rencana sendiri.** Prompt: “Sekarang lakukan pemeriksaan mandiri wajib. Periksa kembali rencana Anda dengan jujur: apakah ada bagian yang Anda karang begitu saja dan belum diverifikasi dengan kode, dokumentasi, atau contoh terdahulu dari Langkah 2? Jika ada, tandai dan revisi rencana.” Ini adalah penyaring terakhir. Claude harus memeriksa penalarannya sendiri dan mengakui bagian yang dihalusinasikannya. Biasanya setidaknya 2 butir rencana direvisi pada langkah ini. Setelah 4 langkah tersebut, rencana siap disetujui. Anda dapat beralih ke implementasi dengan yakin bahwa tugas sudah dipahami, opsi sudah ditimbang, dan risikonya sudah dipertimbangkan. Metodologi ini ditujukan untuk mendiagnosis bug sulit dan mengambil keputusan arsitektur—situasi yang biaya kesalahannya tinggi. Jika diterapkan pada Plan Mode, metodologi ini menghilangkan masalah utama vibe coder: “AI memberi saya solusi, saya menerapkannya, lalu semuanya rusak.” ## 5 prompt siap pakai apa yang berguna di Plan Mode untuk tugas umum?
Poin utama Prompt siap pakai menghemat 10-15 menit per tugas dan meningkatkan kualitas rencana. Ada lima templat umum untuk memfaktorkan ulang modul, memigrasikan basis data, menambahkan fitur baru, menulis tes, dan men-debug kesalahan rumit. Masing-masing mengikuti siklus 4 langkah dan dikaitkan dengan folder `plans/`.
**Templat 1. Memfaktorkan ulang modul.** ``` I'm enabling Plan Mode. Task: refactor the {module-name} module. Step 1: Study the current structure of the {module-path} module. Describe: - which files are part of the module - which external dependencies it has - which parts are duplicated - which functions are overcomplicated Step 2: Find 2-3 examples online of refactoring similar modules. At least 1 source must be official Anthropic or related framework documentation. Step 3: Create a refactoring plan in plans/YYYY-MM-DD-refactor-{module}.md: - which files to rename - which functions to extract into separate modules - which tests to keep and which to rewrite - risks: what could break for users Step 4: Self-check. Are there any assumptions in the plan that are "pulled out of thin air"? Rewrite or remove them. ``` **Templat 2. Migrasi basis data.** ``` I'm enabling Plan Mode. Task: migrate the database from {old} to {new}. Step 1: Study the current database schema using {schema-reading-command}. Describe: - which tables exist and their size - which relationships, indexes, and constraints there are - where migrations are stored - which data is critical Step 2: Find precedents for {old → new} migrations in production projects. At least 3 different approaches: pg_dump, dual-write, blue-green. For each, list the pros and risks for our data size. Step 3: Create a migration plan in plans/YYYY-MM-DD-db-migration.md: - phases (backup, migration, verification, switchover) - success criteria for each phase - rollback plan if something goes wrong - downtime or no downtime Step 4: Self-check. Are all figures supported by documentation? Have all steps been mentally checked against the dev environment? ``` **Templat 3. Menambahkan fitur baru.** ``` I'm enabling Plan Mode. Task: add the {description} feature to the project. Step 1: Study how similar features currently work in the project. Specifically, look at: - {file-1} - {file-2} - which architectural patterns are used - which tests are written for similar features Step 2: Find how this feature is implemented in open-source projects with a similar architecture. At least 2 different approaches. Step 3: Create a plan in plans/YYYY-MM-DD-feature-{name}.md: - list of new files - list of changed files with specific lines - implementation sequence - which tests to add - what to add to CLAUDE.md as a rule for future sessions Step 4: Self-check. Does the plan follow the project's architecture? Does it assume libraries that haven't been installed yet? ``` **Templat 4. Menulis tes.** ``` I'm enabling Plan Mode. Task: cover the {name} module with tests. Step 1: Study the {path} module. Identify: - public functions and their signatures - internal functions we will NOT test (implementation details) - edge cases: empty input, errors, concurrent access Step 2: Find test examples for a similar class of tasks in popular open-source projects using the same framework. Step 3: Create a test plan in plans/YYYY-MM-DD-tests-{module}.md: - for each public function, a list of tests - which mocks are needed - which fixtures - which verification approach (assertion style) Step 4: Self-check. Do all tests check behavior rather than implementation? Does the coverage include edge cases? ``` **Templat 5. Men-debug kesalahan rumit.** ``` I'm enabling Plan Mode. Task: understand the cause of the error {symptom-description}. Step 1: ESTABLISH THE FACTS. Solutions and ideas are prohibited. Only: - what I observe (exact wording of the error) - reproducible steps - what data is available (logs, traces, library versions) - what data is missing (what needs to be collected additionally) Step 2: Find precedents for this error. At least 3 sources: issue trackers, documentation, and other relevant references. For each, provide a link and a brief summary of the solution. Step 3: Create a diagnostic plan in plans/YYYY-MM-DD-bug-{name}.md: - which hypotheses to check (sorted by likelihood) - which commands/scripts to run to check each one - the expected result of each check Step 4: Self-check. Are there any hypotheses in the plan that are "pulled out of thin air"? Are all hypotheses tied to facts from Step 1? ``` Salin setiap templat, ganti `{parameters}` dengan milik Anda, lalu tempelkan ke Claude Code dalam Plan Mode. Hasilnya adalah rencana kerja di `plans/` yang dapat Anda setujui dan gunakan untuk implementasi. ## Plan Mode vs. mode normal: mana yang sebaiknya dipilih?
Poin utama Gunakan Plan Mode untuk pendekatan yang belum pasti, kode belum familier, keputusan arsitektur, migrasi, atau perubahan dengan dampak samping signifikan. Jumlah file merupakan pengingat untuk mempertimbangkan dependensi, bukan aturan keras. Diff kecil, dipahami, dan berisiko rendah dapat ditangani langsung; deskripsi satu kalimat saja tidak membuat autentikasi atau migrasi aman.
Anthropic menyatakannya secara langsung dalam dokumentasinya:

Plan mode berguna, tetapi menambah beban. Untuk tugas dengan cakupan jelas dan perubahan kecil (salah ketik, satu baris log, mengganti nama variabel), minta Claude langsung mengerjakannya. Perencanaan paling berguna saat Anda tidak yakin dengan pendekatannya, saat perubahan menyentuh banyak file, atau saat Anda belum mengenal kodenya. Jika Anda bisa menjelaskan diff dalam satu frasa, lewati rencana.

— Anthropic Docs, https://www.anthropic.com/engineering/claude-code-best-practices
Lewati rencana terpisah hanya ketika diff sebenarnya kecil, dipahami, dan berisiko rendah. Gunakan perencanaan ketika perlu menemukan pendekatan atau mengoordinasikan perubahan berisiko antar komponen. Mengetahui nama file atau merangkum tujuan dalam satu kalimat tidak menghilangkan risiko migrasi, autentikasi, atau integritas data. Tabel keputusan: | Tugas | Mode | Alasan | |----|----|----| | Salah ketik di README | Default | Satu file, satu perubahan, diff jelas | | Mengganti nama variabel di satu file | Default | Cakupan jelas dan referensi dapat diperiksa; nilai dampak samping | | Menambahkan baris logging | Default | Perubahan satu baris yang tidak memengaruhi logika | | Menambahkan tombol baru ke halaman | Default | Jika hanya ada satu tombol dan Anda tahu letaknya, rencana tidak diperlukan | | Memfaktorkan ulang modul | Plan Mode | 5+ file, risiko dampak samping | | Migrasi basis data | Plan Mode + `/goal` | Proses beberapa langkah; perlu rencana rollback | | Menambahkan autentikasi | Plan Mode | Memengaruhi 10+ file; keamanan sangat penting | | Menulis tes untuk modul | Plan Mode | Anda perlu menentukan apa yang akan dites | | Men-debug bug yang tidak jelas | Plan Mode + siklus 4 langkah | Tanpa diagnosis, solusi akan meleset | | Migrasi framework secara menyeluruh | Plan Mode + `plans/` + `/goal` semalaman | Tugas panjang yang memerlukan fase dan siklus otonom | Sebelum memilih mode, tanyakan apakah pendekatan, dampak samping, dan verifikasinya dipahami. Kerjakan langsung perubahan kecil, lokal, dan berisiko rendah dengan pemeriksaan yang jelas. Rencanakan terlebih dahulu ketika ada ketidakpastian, kode belum familier, migrasi, autentikasi, atau koordinasi antar komponen—meskipun semua 3–5 file terdampak sudah dapat disebutkan. ## Bagaimana cara menggabungkan Plan Mode + CLAUDE.md + subagen untuk pekerjaan yang andal?
Poin utama Plan Mode menjadi 10 kali lebih kuat jika dipadukan dengan [CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/) yang dikonfigurasi dengan baik dan [subagen](https://ailoot.ai/blog/id/claude-code-subagents/). CLAUDE.md menetapkan aturan yang digunakan Claude untuk menyusun rencana. Subagen memungkinkan Anda membagikan fase rencana kepada agen yang bekerja secara paralel. Tanpa kombinasi ini, Plan Mode tetap menjadi alat sekali pakai.
CLAUDE.md adalah file yang dibaca Claude pada awal setiap sesi, termasuk Plan Mode. Jika CLAUDE.md menyatakan “jangan pernah menulis tanggal secara hardcode; selalu ambil dari basis data,” rencana tidak akan menyarankan tanggal hardcode. Tanpa aturan tersebut, rencana bisa menyarankan apa saja. Kombinasinya bekerja seperti ini: **Lapisan 1. CLAUDE.md menetapkan aturan.** File tersebut menjelaskan stack proyek, prinsip arsitektur, larangan (“jangan gunakan API usang”), dan persyaratan (“semua email harus memakai tata letak bersama”). Panduan terperinci: [Cara mengonfigurasi CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/). **Lapisan 2. Plan Mode menerapkan aturan pada tugas.** Saat Anda mengaktifkan Plan Mode dan meminta “tambahkan OAuth,” Claude membaca CLAUDE.md, melihat aturan (“simpan token di Redis, bukan di basis data”), lalu langsung mempertimbangkannya dalam rencana. Rencana tersebut sesuai dengan arsitektur proyek. **Lapisan 3. Subagen membagi pekerjaan.** Jika rencana dibagi menjadi beberapa fase, setiap fase dapat diberikan kepada [subagen](https://ailoot.ai/blog/id/claude-code-subagents/) tersendiri. Setiap subagen bekerja dalam jendela konteksnya sendiri tanpa memenuhi jendela utama. Rencana di `plans/` tetap menjadi sumber kebenaran utama: subagen membacanya, mengerjakan fasenya, dan memperbarui kotak centang. ## 7 kesalahan apa yang merusak Plan Mode?
Poin utama Plan Mode sering bermasalah karena kesalahan penggunaan yang umum, bukan karena alatnya lemah. Tujuh kesalahan utamanya adalah: menyimpan rencana dalam ingatan alih-alih file, menumpuk semua tugas dalam satu obrolan, membuat rencana tanpa fase, melewatkan riset mendalam, membiarkan AI penjilat menawarkan solusi tanpa diagnosis, melewatkan pemeriksaan mandiri, dan menggunakan syarat `/goal` yang samar.
**Kesalahan 1. Rencana hanya ada di obrolan.** Gejala: Anda menulis rencana, menutup jendela, lalu perlu kembali keesokan harinya—tetapi tidak ada apa-apa; konteksnya hilang. Solusi: selalu simpan rencana di `plans/YYYY-MM-DD-feature-name.md` dalam repositori. Obrolan adalah meja kerja; file adalah arsip. **Kesalahan 2. Semua tugas ada dalam satu obrolan.** Gejala: dalam satu sesi, Anda membahas auth, lalu migrasi, lalu desain UI, kemudian bug. Jendela konteks menjadi “membengkak,” dan Claude melupakan hal-hal sebelumnya. Solusi: satu tugas—satu percakapan. Rencana selesai? Tutup jendelanya. Mulai implementasi? Buka yang baru. **Kesalahan 3. Satu rencana 3000 baris tanpa fase.** Gejala: rencana ada, tetapi tidak memiliki kotak centang atau pembagian. Tidak mungkin mengetahui apa yang sudah selesai dan apa yang belum. Delegasi mustahil. Solusi: bagi setiap rencana menjadi 3-7 fase. Setiap fase berupa daftar kotak centang dengan tindakan spesifik. **Kesalahan 4. Tidak ada riset mendalam sebelum membuat rencana.** Gejala: Claude mengusulkan solusi begitu saja karena Anda tidak memintanya mencari contoh terdahulu. Seminggu kemudian, Anda mengetahui bahwa proyek sumber terbuka sudah lama memiliki pendekatan yang lebih baik. Solusi: Langkah 2 dari siklus 4 langkah—minta Claude menemukan 2-3 contoh terdahulu secara daring sebelum membuat rencana. **Kesalahan 5. AI penjilat memberi solusi tanpa diagnosis.** Gejala: Anda bertanya “bagaimana cara memperbaiki kesalahan X?”, Claude memberi solusi, Anda menerapkannya, tetapi tidak ada yang berhasil atau keadaan memburuk. Solusi: selalu mulai dengan “tetapkan faktanya; solusi dilarang.” Setelah diagnosis, barulah lanjut ke opsi. **Kesalahan 6. Melewatkan pemeriksaan mandiri.** Gejala: rencana tampak masuk akal, tetapi berisi 2-3 asumsi yang “dikarang begitu saja” (pustaka rekaan, API yang tidak ada, atau versi yang keliru). Implementasi gagal pada bagian tersebut. Solusi: Langkah 4 dari siklus 4 langkah—minta Claude memeriksa ulang rencananya dengan jujur dan menandai asumsi. **Kesalahan 7. Syarat `/goal` yang samar.** Gejala: Anda menetapkan `/goal make it look nice`, membiarkannya semalaman, lalu bangun dan mengetahui bahwa kuota senilai $200 telah habis. Solusi: gunakan hanya syarat terukur dengan perintah verifikasi dan `or stop after N turns` yang wajib. Hindari “buat lebih baik” atau “rapikan.” Kesalahan kedelapan, yang paling sering dilakukan vibe coder, adalah mengabaikan konsep folder `plans/`. Plan Mode tanpa folder `plans/` bukan metodologi; itu mainan. Jika menggunakan Plan Mode tetapi tidak membuat file, Anda hanya mendapatkan 10% kemampuannya. ## Apa yang sebaiknya dilakukan setelah pengalaman pertama dengan Plan Mode?
Poin utama Pengalaman pertama dengan Plan Mode adalah titik awal. Langkah berikutnya: konfigurasi [CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/) jika belum memilikinya (tanpanya, rencana menggantung di udara), buat folder `plans/` di repositori sebagai metodologi kerja, dan coba `/goal` untuk satu tugas otonom sebelum tidur. Kombinasi ketiganya—Plan Mode, CLAUDE.md, dan `plans/`—adalah sistem yang berfungsi.
Tiga langkah konkret dengan tingkat kesulitan yang meningkat: **Langkah 1. Konfigurasikan CLAUDE.md jika belum memilikinya.** Tanpa CLAUDE.md, Plan Mode bekerja “dalam ruang hampa”—Claude tidak mengetahui aturan proyek dan mengusulkan rencana yang merusak arsitektur. Panduan lengkap: [Cara mengonfigurasi CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/). CLAUDE.md minimal terdiri dari 50-80 baris yang menjelaskan stack, aturan, dan larangan. Panjang bukan yang utama. Yang penting adalah kekhususan. **Langkah 2. Buat folder `plans/` di repositori.** Tambahkan folder `plans/` ke akar proyek. Sepakati format penamaan: `YYYY-MM-DD-feature-name.md`. Setiap rencana mendapat filenya sendiri. Setelah sebulan, Anda akan memiliki 20-30 file; setelah enam bulan, 100+. Itulah riwayat keputusan proyek yang terus berkembang. **Langkah 3. Coba `/goal` untuk satu tugas.** Pilih tugas yang biasanya Anda kerjakan sendiri selama 30-40 menit. Aktifkan Plan Mode, buat rencana, dan simpan di `plans/`. Keluar dari Plan Mode. Tetapkan `/goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns`. Tutup laptop selama satu jam dan lakukan hal lain. Kembali, lalu periksa hasilnya. Ketiga langkah itu adalah batas minimumnya. Ini dibangun secara bertahap; jangan coba menyusun semuanya dalam satu malam. Mulailah dengan CLAUDE.md, tambahkan `plans/` setelah seminggu, dan coba `/goal` semalaman setelah sebulan.
### Sumber - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal) - [Anthropic Docs - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
Saat Anda siap, kenali [Ailoot](https://ailoot.ai/). ## Pertanyaan tentang Plan Mode di Claude Code: Panduan Langkah demi Langkah dan 4 Fase pada 2026 ### Bisakah melewati perencanaan hanya karena saya tahu file mana yang akan berubah? Tidak. Nama file yang sudah diketahui tidak menghapus ketidakpastian dampak samping atau verifikasi. Rencanakan migrasi, perubahan autentikasi, dan perubahan komponen terkoordinasi meskipun daftar filenya sudah jelas. ### Kapan fase Plan Mode terpisah tidak diperlukan? Untuk diff kecil, dipahami, dan berisiko rendah dengan pemeriksaan jelas, seperti salah ketik lokal, pengerjaan langsung masuk akal. Gunakan perencanaan ketika pendekatan belum jelas, kode belum familier, atau risiko operasional serta lintas file perlu dipikirkan. ## Ailoot · Perusahaan dan portofolio proyeknya Ailoot bertumpu pada pengalaman operasional yang teruji, basis pelanggan yang besar, layanan yang stabil, dan pemantauan KPI berkelanjutan. Perusahaan dan portofolio proyeknya: jutaan pelanggan; penjualan miliaran setiap bulan. Ailoot memanfaatkan pengalaman operasional ini untuk akses API ke fitur AI dalam produk pelanggan, agen, aplikasi, dan otomatisasi.