15 Langkah Vibe Coding

Panduan praktik berbahasa Indonesia • Edisi 28 Oktober 2026

Dari ide, spesifikasi, implementasi, pengujian, sampai persiapan rilis. Diadaptasi dari 15 topik pada gambar yang diberikan pengguna. Penjelasan, prompt, dan contoh TaskFlow disusun ulang sebagai materi editorial asli; bukan transkripsi atau klaim afiliasi dengan pembuat gambar.

1. Daftar istilah

Definisi berikut adalah glosarium kerja ringkas. Rujukan teknis produk tersedia pada bab terkait dan daftar sumber.

2. Latar belakang

Panduan ini dirancang untuk pemula yang ingin menggunakan AI sambil tetap memahami keputusan proyek. Praktik resmi Claude Code menekankan pemberian konteks yang spesifik dan cara memverifikasi pekerjaan. [Claude-praktik (2026/10), Scope the task / verification]

Seluruh target, struktur TaskFlow, urutan latihan, prompt, dan kriteria selesai dalam paket ini adalah usulan editorial, bukan kutipan dokumentasi atau hasil pengujian sebuah aplikasi yang telah dibuat. Paket ini merupakan panduan dan template, bukan kode aplikasi TaskFlow yang siap dijalankan.

3. Mekanisme kerja

Gunakan siklus: tentukan kebutuhan → pilih satu fitur → tulis perilaku → minta implementasi → jalankan pemeriksaan → tinjau perubahan → simpan versi. Jika pemeriksaan gagal, kembali ke spesifikasi atau debug; jangan melanjutkan seolah pekerjaan sudah selesai. Urutan ini adalah rancangan latihan.

Nomor 01–15 mengikuti topik gambar, bukan urutan wajib yang kaku. Keamanan, tes, Git, dan pemeriksaan otomatis sebaiknya diperkenalkan sejak awal lalu diulang. MCP bersifat opsional. “Ultra Plan Mode” tidak diperlakukan sebagai perintah bawaan.

4. Langkah konkret

Persiapan awal

1. Siapkan komputer, editor, terminal, Git, browser, dan satu asisten coding yang sudah dapat dipakai. Baca persyaratan pemasangan versi alat yang dipilih pada dokumentasi resminya.

2. Buat folder latihan tersendiri. Untuk proyek lama, buat cadangan dan periksa status Git sebelum mengubah apa pun.

3. Gunakan data dummy. Simpan kredensial pada mekanisme konfigurasi yang disediakan alat, bukan dalam prompt atau repositori.

4. Tentukan stack berdasarkan kebutuhan dan kemampuan lingkungan. Contoh arsitektur latihan: antarmuka web dan layanan akun/database. Supabase hanya contoh, bukan kewajiban.

5. Buka prompts/00-konteks-proyek.txt, isi placeholder, lalu berikan kepada asisten. Salin satu prompt langkah setiap kali.

6. Simpan keputusan di dokumen proyek. Bila asisten menyebut perintah yang tidak ada, minta ia membaca konfigurasi dan memperbaikinya.

Perintah pemeriksaan awal opsional untuk terminal yang menyediakan Git:

git --version
git status

git status dijalankan di repositori yang sudah ada. Jika folder baru belum memakai Git, inisialisasikan melalui editor atau git init setelah memastikan direktori benar. Jangan menjalankan perintah instalasi paket sebelum stack disepakati.

01. PRD: jelaskan masalah sebelum meminta kode

Tentukan siapa pengguna, masalah yang dialami, dan hasil yang ingin dicapai. Dalam latihan TaskFlow, pengguna adalah pekerja mandiri yang ingin mencatat tugas pribadi. Fokus versi awal hanya masuk akun, membuat tugas, mengganti status, menyaring daftar, dan keluar akun. Tunda kolaborasi tim, pembayaran, dan integrasi kalender.

Langkah praktik

1. Tuliskan tiga situasi pengguna.

2. Pilih satu alur utama: masuk → tambah tugas → tandai selesai.

3. Buat daftar kebutuhan wajib dan yang ditunda.

4. Tentukan ukuran keberhasilan serta cara mengukurnya.

Prompt siap salin

Bertindak sebagai analis produk. Susun PRD TaskFlow, aplikasi tugas pribadi untuk pekerja mandiri. Wajib: akun pengguna, tambah/edit/hapus tugas, status todo/doing/done, filter status. Di luar cakupan: tim, pembayaran, kalender. Buat masalah, persona, user stories, kebutuhan fungsional, kebutuhan kualitas, risiko, asumsi, dan kriteria penerimaan terukur. Bedakan target yang diusulkan dari hasil yang sudah diukur. Jangan menulis kode. Tandai keputusan yang belum tersedia, jangan mengarang kebutuhan. Simpan hasil sebagai docs/PRD.md.

Contoh hasil yang diharapkan: PRD menyatakan judul tugas wajib 1–120 karakter setelah spasi tepi dihapus; pengguna hanya mengelola tugas sendiri; tugas tetap ada setelah halaman dimuat ulang.

Kriteria selesai: Semua fitur wajib punya kriteria penerimaan; fitur yang ditunda tertulis; tidak ada angka keberhasilan yang diklaim sudah tercapai.

Kesalahan yang perlu dihindari: Meminta “buat aplikasi keren” tanpa menyebut pengguna dan batas fitur.

02. Instruksi proyek: buat konteks yang konsisten

Tuliskan keputusan yang harus dipatuhi asisten di dalam proyek. Pada Claude Code, CLAUDE.md menjadi tempat instruksi proyek. Buat dokumen singkat berisi perintah yang benar-benar tersedia, batas perubahan, konvensi, dan cara memverifikasi pekerjaan. Jangan menaruh kata sandi atau menyalin seluruh dokumentasi dependensi.

Rujukan teknis pendamping: [Claude-memory (2026/10), CLAUDE.md]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Minta asisten membaca struktur proyek.

2. Catat teknologi dan perintah dari berkas proyek.

3. Pisahkan keputusan tetap dari daftar pekerjaan.

4. Perbarui aturan ketika keputusan berubah.

Prompt siap salin

Periksa repositori ini. Susun CLAUDE.md singkat berdasarkan file yang benar-benar ada: ringkasan TaskFlow, struktur direktori, konvensi, perintah instalasi/jalankan/uji/build, aturan rahasia, serta definisi selesai. Jangan mengarang perintah. Jika proyek masih kosong, tandai semua pilihan sebagai usulan dan buat daftar keputusan yang diperlukan. Instruksikan agar perubahan kecil, hasil tes jujur, dan file pengguna tidak ditimpa tanpa alasan.

Contoh hasil yang diharapkan: Aturan: baca PRD dan spesifikasi fitur; jangan memasukkan .env ke Git; setiap laporan menyebut tes yang dijalankan, hasil, dan tes yang belum dijalankan.

Kriteria selesai: Perintah sudah dicocokkan dengan proyek; aturan tidak saling bertentangan; tidak ada kredensial.

Kesalahan yang perlu dihindari: Menganggap sebuah file instruksi otomatis dikenali semua alat AI. Periksa mekanisme instruksi alat yang dipakai.

03. Rencana bertahap: dari versi minimum ke rilis

Gunakan tahap perencanaan untuk menyusun urutan pekerjaan dan ketergantungan. Istilah “Ultra Plan Mode” pada gambar diperlakukan sebagai ajakan membuat rencana mendalam, bukan nama fitur universal. Untuk latihan ini, bangun satu alur pengguna sampai berfungsi sebelum menambahkan fitur berikutnya.

Langkah praktik

1. Bagi pekerjaan menjadi fondasi, alur utama, pengamanan, dan rilis.

2. Tulis ketergantungan setiap pekerjaan.

3. Tentukan keluaran yang dapat diperiksa.

4. Tambahkan titik berhenti ketika keputusan belum jelas.

Prompt siap salin

Baca PRD TaskFlow. Buat roadmap dari proyek kosong sampai staging dengan fase, daftar tugas kecil, ketergantungan, keluaran, risiko, dan kriteria selesai. Prioritaskan satu alur vertikal masuk akun → tambah tugas → baca ulang. Pisahkan rencana dari implementasi; jangan mengedit kode dahulu. Nyatakan mana estimasi, bukan janji waktu. Simpan docs/ROADMAP.md.

Contoh hasil yang diharapkan: Fase 1: tampilan dengan data contoh. Fase 2: akun dan penyimpanan tugas milik pengguna. Fase 3: uji hak akses dan kegagalan. Fase 4: staging serta uji pemulihan.

Kriteria selesai: Tiap tugas punya keluaran konkret dan ketergantungan; tidak ada tugas sebesar “selesaikan backend”.

Kesalahan yang perlu dihindari: Menghasilkan daftar panjang tanpa menyebut apa yang harus selesai lebih dahulu.

04. Spesifikasi fitur: tetapkan perilaku yang tepat

Spesifikasi menjawab apa yang terjadi saat pengguna melakukan tindakan tertentu, termasuk ketika masukan salah atau jaringan gagal. Mulai dengan fitur tambah tugas. Hubungkan setiap aturan dengan pemeriksaan yang bisa diulang. Pilih cara komunikasi aplikasi berdasarkan arsitektur yang disepakati, bukan membuat API tambahan tanpa kebutuhan.

Langkah praktik

1. Tetapkan masukan, keluaran, dan aturan validasi.

2. Jelaskan kondisi kosong, memuat, sukses, serta gagal.

3. Tentukan pemilik data dan penanganan klik ganda.

4. Tulis skenario diterima dan ditolak.

Prompt siap salin

Susun docs/SPEC-tambah-tugas.md dari PRD. Definisikan field title 1–120 karakter setelah trim, status awal todo, pemilik berasal dari identitas terverifikasi, dan created_at. Jelaskan alur sukses, judul kosong, sesi habis, akses pengguna lain, jaringan gagal, dan klik ganda. Tentukan kontrak operasi create/list sesuai stack terpilih. Buat kriteria Given/When/Then dan kasus uji. Jangan mengimplementasikan dulu.

Contoh hasil yang diharapkan: Ketika judul hanya spasi dikirim, aplikasi menampilkan pesan validasi dan tidak membuat baris. Ketika penyimpanan gagal, teks masukan tetap tersedia untuk dicoba ulang.

Kriteria selesai: Perilaku gagal jelas; pemilik tidak dipercaya dari formulir; setiap aturan punya kasus uji.

Kesalahan yang perlu dihindari: Hanya mendeskripsikan layar sukses lalu membiarkan AI menebak semua perilaku lainnya.

05. Desain UI dan UX: rancang semua keadaan layar

Rancang tampilan sekaligus perjalanan pengguna. Untuk TaskFlow, gunakan satu halaman daftar tugas dengan formulir ringkas dan filter status. Pilih ukuran teks yang mudah dibaca, label yang jelas, dan indikator fokus. Ilustrasi pada panduan adalah visual konseptual, bukan tangkapan layar produk yang sudah dibangun.

Langkah praktik

1. Daftar halaman dan tindakan utama.

2. Rancang tampilan ponsel terlebih dahulu.

3. Tentukan keadaan kosong, memuat, gagal, dan berhasil.

4. Periksa navigasi papan ketik serta label formulir.

Prompt siap salin

Buat brief UI/UX TaskFlow berdasarkan PRD dan spesifikasi. Hasilkan struktur layar masuk dan daftar tugas, komponen, hierarki teks, warna, jarak, respons pada layar sempit, serta keadaan empty/loading/error/success. Gunakan label bahasa Indonesia. Jangan mengandalkan warna saja untuk status. Tentukan fokus papan ketik, pesan kesalahan dekat field, dan konfirmasi hapus. Simpan docs/DESIGN.md sebelum membuat komponen.

Contoh hasil yang diharapkan: Daftar kosong menampilkan “Belum ada tugas” dan tombol tambah. Saat proses simpan berlangsung, tombol menjelaskan “Menyimpan…” dan mencegah pengiriman berulang.

Kriteria selesai: Alur dapat dipahami tanpa penjelasan lisan; semua keadaan dirancang; formulir bisa dipakai dengan papan ketik.

Kesalahan yang perlu dihindari: Meminta “mirip aplikasi terkenal” tanpa menjelaskan kebutuhan pengguna atau keadaan gagal.

06. Implementasi: kerjakan satu bagian yang bisa dibuktikan

Gunakan rencana sebagai daftar pekerjaan, lalu pilih satu bagian kecil. Satu putaran yang baik menghasilkan perubahan yang dapat dijalankan dan dibandingkan dengan kriteria penerimaan. Minta asisten menjelaskan berkas yang berubah dan bukti verifikasi. Hindari menambahkan fitur baru hanya karena asisten menyarankannya.

Rujukan teknis pendamping: [Claude-praktik (2026/10), Scope the task / verification]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Pastikan direktori proyek benar dan cadangan tersedia.

2. Pilih satu tugas dari roadmap.

3. Minta implementasi dengan batas berkas dan perilaku.

4. Jalankan pemeriksaan yang relevan lalu tinjau perubahan.

Prompt siap salin

Implementasikan hanya formulir tambah tugas sesuai docs/SPEC-tambah-tugas.md dan docs/DESIGN.md. Baca kode terkait dahulu, gunakan pola yang sudah ada, dan jelaskan rencana singkat. Jangan menambah dependensi tanpa alasan. Sertakan validasi server atau lapisan tepercaya, penanganan gagal, dan tes perilaku penting. Jalankan pemeriksaan yang tersedia. Laporkan file berubah, perintah beserta hasil, hal yang belum diuji, dan pekerjaan berikutnya.

Contoh hasil yang diharapkan: Satu perubahan menambahkan formulir dan operasi simpan yang dapat diuji; tidak sekaligus mengganti desain seluruh aplikasi dan sistem akun.

Kriteria selesai: Kriteria fitur lolos; build yang relevan berhasil; hasil pemeriksaan tercatat tanpa klaim palsu.

Kesalahan yang perlu dihindari: Menerima jawaban “sudah selesai” tanpa menjalankan aplikasi atau membaca perubahan.

07. MCP: tambahkan integrasi hanya jika dibutuhkan

MCP dapat menjadi penghubung asisten dengan alat dan sumber eksternal. Integrasi memperluas akses, sehingga izin dan kredensial harus dipikirkan sejak awal. Dalam TaskFlow versi minimum, MCP tidak diperlukan. Pelajari bagian ini setelah alur inti stabil, misalnya untuk akses dokumentasi yang hanya membaca.

Rujukan teknis pendamping: [MCP-security (2026/10), Risks and mitigations]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Sebutkan kebutuhan yang tidak terpenuhi alat bawaan.

2. Pilih server dengan asal-usul yang dapat diperiksa.

3. Mulai dari izin baca dan lingkungan percobaan.

4. Uji input salah, batas waktu, serta respons gagal.

Prompt siap salin

Nilai apakah TaskFlow membutuhkan MCP untuk kebutuhan [ISI KEBUTUHAN]. Jika tidak, jelaskan dan jangan memasang apa pun. Jika perlu, usulkan server tepercaya, tools/resources yang digunakan, izin minimum, autentikasi, lokasi konfigurasi sesuai klien, batas waktu, dan cara mencabut akses. Jangan menampilkan token atau memberi akses basis data produksi. Buat rencana uji read-only sebelum mengaktifkan operasi tulis.

Contoh hasil yang diharapkan: Contoh opsional: asisten membaca dokumentasi melalui server terbatas. Jangan memberi izin hapus data hanya untuk mencari referensi.

Kriteria selesai: Kebutuhan jelas; izin minimum; akses dapat dicabut; uji gagal selesai. Jika tidak perlu, tandai dilewati.

Kesalahan yang perlu dihindari: Menganggap semakin banyak server terhubung berarti aplikasi semakin baik atau aman.

08. Basis data: simpan dengan aturan kepemilikan

Rancang tabel bersama aturan aksesnya. Jika memilih Supabase/Postgres, periksa izin tingkat tabel dan kebijakan RLS untuk membatasi baris yang dapat diakses pengguna. Jangan hanya menyembunyikan tugas pengguna lain pada tampilan. Kunci dengan hak istimewa harus tetap berada di sisi server.

Rujukan teknis pendamping: [Supabase-RLS (2026/10), Grants and policies / policy tests]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Tentukan tabel tasks dan relasi pemilik.

2. Buat migrasi yang dapat diulang di lingkungan percobaan.

3. Terapkan aturan baca, tambah, ubah, dan hapus.

4. Uji dua pengguna dan pengguna tanpa sesi.

Prompt siap salin

Rancang migrasi TaskFlow untuk Supabase/Postgres: tasks(id, owner_id, title, status, created_at). Tetapkan constraint title dan status, indeks sesuai pola baca, grants minimum dan RLS per operasi. owner_id harus cocok dengan identitas pengguna terautentikasi; cegah pengalihan pemilik pada update. Berikan data dummy dan rencana uji akun A, akun B, serta tanpa login. Simpan rahasia di konfigurasi server. Jangan menjalankan migrasi produksi.

Contoh hasil yang diharapkan: Akun A dapat membaca tugas A. Akun B tidak dapat membaca, mengubah, atau menghapus tugas A walaupun mengetahui ID-nya. Tanpa sesi, akses ditolak.

Kriteria selesai: Operasi yang diizinkan benar-benar mengubah data; operasi terlarang tidak mengubah data; migrasi diuji terpisah.

Kesalahan yang perlu dihindari: Mengandalkan filter antarmuka atau meletakkan service-role key di browser.

09. Tinjau keamanan: uji batas akses secara nyata

Susun pemeriksaan berdasarkan alur data dan kewenangan pengguna. Dalam latihan ini, risiko utama yang harus diperiksa adalah akses tugas milik orang lain, masukan tidak valid, rahasia di kode, dan operasi berulang yang tidak terkendali. Pemeriksaan otomatis membantu menemukan masalah, tetapi hasil bersih bukan sertifikat keamanan.

Rujukan teknis pendamping: [Supabase-RLS (2026/10), Grants and policies / policy tests]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Petakan data yang masuk dan siapa yang boleh mengubahnya.

2. Periksa validasi pada lapisan tepercaya.

3. Uji permintaan langsung tanpa mengandalkan tombol UI.

4. Urutkan temuan berdasarkan dampak dan bukti.

Prompt siap salin

Tinjau TaskFlow terhadap spesifikasi akses. Cari akses lintas pengguna, validasi yang hanya di browser, kebocoran secret, penanganan sesi, pesan error sensitif, serta penyalahgunaan operasi berulang. Untuk setiap temuan tuliskan file/baris, skenario reproduksi aman memakai data dummy, dampak, perbaikan minimum, dan tes regresi. Bedakan temuan terbukti dari dugaan. Jangan mengubah sistem eksternal atau melakukan pengujian ke produksi.

Contoh hasil yang diharapkan: Mengganti ID tugas dalam permintaan akun B tidak boleh mengubah tugas A. Verifikasi keadaan data setelah percobaan, bukan hanya kode respons.

Kriteria selesai: Temuan penting ditangani dan diuji ulang; batas pemeriksaan terdokumentasi.

Kesalahan yang perlu dihindari: Menyatakan “100% aman” setelah satu pemindaian atau setelah tombol berbahaya disembunyikan.

10. Debug: reproduksi, buktikan penyebab, perbaiki

Mulai dari gejala yang dapat diulang. Catat tindakan, hasil yang diharapkan, hasil aktual, dan pesan kesalahan yang sudah dibersihkan dari rahasia. Minta asisten membuat hipotesis, lalu mencari bukti sebelum mengubah kode. Perbaikan terbaik untuk latihan ini adalah perubahan paling kecil yang memulihkan perilaku dan menjaga kasus lain.

Rujukan teknis pendamping: [Claude-praktik (2026/10), Scope the task / verification]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Ulangi masalah dengan data dummy.

2. Catat langkah dan lingkungan.

3. Uji satu hipotesis pada satu waktu.

4. Tambahkan pemeriksaan untuk mencegah masalah yang sama.

Prompt siap salin

Bantu debug TaskFlow. Langkah reproduksi: [ISI]. Harapan: [ISI]. Hasil aktual: [ISI]. Error yang sudah disanitasi: [ISI]. Baca kode terkait, susun hipotesis berdasarkan bukti, lalu pilih pemeriksaan paling sederhana. Jangan mengganti arsitektur atau menonaktifkan validasi untuk menutupi masalah. Terapkan perbaikan kecil setelah penyebab didukung bukti. Tambahkan tes regresi dan laporkan hasil aktualnya.

Contoh hasil yang diharapkan: Jika tugas hilang setelah refresh, periksa apakah simpan benar-benar berhasil dan daftar membaca sumber yang sama; jangan langsung menambahkan penyimpanan browser sebagai penutup gejala.

Kriteria selesai: Kasus awal gagal sebelum perbaikan dan lolos sesudahnya; skenario terkait tetap lolos.

Kesalahan yang perlu dihindari: Menempel log berisi token atau meminta AI mengubah banyak hal sebelum masalah dapat direproduksi.

11. E2E: uji alur seperti pengguna

Tes end-to-end memeriksa perjalanan pengguna melintasi beberapa bagian aplikasi. Dokumentasi Playwright menyarankan menguji perilaku yang terlihat pengguna dan menjaga tes terisolasi. Gunakan lingkungan percobaan serta data yang terkendali. Jangan membuat tes yang bergantung pada urutan tes sebelumnya.

Rujukan teknis pendamping: [Playwright (2026/10), Testing philosophy]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Tentukan alur bisnis paling penting.

2. Siapkan akun uji dan data milik tes.

3. Gunakan pencarian elemen melalui peran atau label.

4. Uji alur sukses dan kegagalan yang berarti.

Prompt siap salin

Buat tes Playwright untuk TaskFlow berdasarkan perilaku pengguna: masuk, membuat tugas, refresh dan melihat tugas tetap ada, mengganti status, filter, menghapus, dan keluar. Tambahkan judul kosong serta sesi habis. Isolasi data setiap tes dan lakukan cleanup aman. Gunakan locator berbasis role/label dan assertion yang menunggu keadaan UI, bukan jeda waktu tetap. Untuk akses lintas pengguna, tambahkan pengujian lapisan API/database yang sesuai. Laporkan tes yang benar-benar dijalankan.

Contoh hasil yang diharapkan: Tes tambah tugas dinyatakan lolos setelah judul terlihat dan tetap ada sesudah refresh, bukan hanya setelah tombol dapat diklik.

Kriteria selesai: Tes dapat dijalankan mandiri; data produksi tidak dipakai; kegagalan memberi bukti yang bisa ditelusuri.

Kesalahan yang perlu dihindari: Menulis tes yang hanya memeriksa keberadaan tombol atau menambah jeda panjang untuk menyembunyikan masalah.

12. Bersihkan kode: pertahankan perilaku

Lakukan pembersihan setelah perilaku utama memiliki pemeriksaan yang memadai. Identifikasi kode tidak terpakai dengan pencarian referensi dan perhatian pada pemanggilan dinamis. Pisahkan penghapusan kode dari perubahan fitur supaya peninjauan mudah. Jika penggunaan sebuah bagian belum jelas, catat dan tunda penghapusannya.

Langkah praktik

1. Cari kandidat file, impor, dan fungsi tidak terpakai.

2. Periksa referensi konfigurasi dan pemanggilan dinamis.

3. Hapus bertahap lalu jalankan pemeriksaan relevan.

4. Tinjau selisih untuk perubahan perilaku tidak sengaja.

Prompt siap salin

Audit kode TaskFlow untuk impor, fungsi, dependensi, dan file yang tampak tidak digunakan. Sebelum menghapus, cari referensi langsung, route, konfigurasi, pemanggilan dinamis, dan penggunaan pada tes. Beri bukti tiap kandidat. Kerjakan pembersihan kecil tanpa mengubah perilaku publik. Jalankan lint/typecheck/build dan tes yang tersedia sesuai dampak. Jika bukti tidak cukup, jangan hapus; masukkan ke daftar tinjauan.

Contoh hasil yang diharapkan: Menghapus komponen contoh yang tidak direferensikan berbeda dengan menghapus berkas route yang ditemukan otomatis oleh framework.

Kriteria selesai: Tidak ada perilaku yang berubah tanpa sengaja; build dan tes relevan lolos; alasan penghapusan dapat ditelusuri.

Kesalahan yang perlu dihindari: Menghapus semua file yang tidak ditemukan oleh satu pencarian teks.

13. Commit Git: rekam satu perubahan yang jelas

Buat catatan perubahan yang menjelaskan tujuan, bukan sekadar “update”. Untuk latihan ini, pakai format tipe dan ringkasan pendek secara konsisten. Tinjau berkas yang akan direkam agar tidak menyertakan rahasia, log, atau perubahan yang tidak terkait. Jangan melakukan push ke tujuan yang belum disepakati.

Langkah praktik

1. Periksa status dan selisih perubahan.

2. Kelompokkan satu tujuan per commit.

3. Tinjau file staged beserta hasil pemeriksaan.

4. Tulis pesan yang menjelaskan perubahan dan alasan.

Prompt siap salin

Tinjau perubahan TaskFlow yang belum di-commit. Kelompokkan berdasarkan tujuan, identifikasi file sensitif atau tidak terkait, dan usulkan pesan commit dengan format tipe(scope): ringkasan. Sertakan alasan pada body bila perlu. Jangan staging semua file secara membabi buta. Sebelum commit, tampilkan ringkasan staged diff dan hasil tes. Jangan push, mengubah riwayat, atau menyertakan perubahan pengguna yang tidak terkait.

Contoh hasil yang diharapkan: Contoh pesan editorial: fix(tasks): pertahankan judul saat penyimpanan gagal. Body menjelaskan masalah yang diperbaiki dan pemeriksaan yang dilakukan.

Kriteria selesai: Isi commit sesuai judul; tidak ada rahasia; perubahan dapat ditinjau sebagai satu tujuan.

Kesalahan yang perlu dihindari: Commit terlalu besar yang mencampur desain, migrasi data, dan perbaikan error.

14. Hooks: otomatisasi pemeriksaan berulang

Bedakan hook Git yang berjalan pada peristiwa Git dengan hook alat AI yang berjalan pada peristiwa alat tersebut. Hook pre-commit dapat menghentikan commit ketika pemeriksaan gagal, tetapi dapat dilewati; karena itu gunakan pemeriksaan CI sebagai lapisan tambahan untuk kolaborasi. Pilih pemeriksaan cepat untuk lokal dan yang lebih berat untuk CI.

Rujukan teknis pendamping: [Git-hooks (2026/10), pre-commit]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Pastikan perintah pemeriksaan tersedia.

2. Pasang hook pada lingkup proyek yang tepat.

3. Uji kasus lolos dan kasus gagal.

4. Dokumentasikan cara pemasangan pada mesin baru.

Prompt siap salin

Usulkan guardrail TaskFlow. Pisahkan Git pre-commit, hook alat AI, dan CI. Gunakan script yang memang tersedia untuk lint, typecheck, pemeriksaan secret, dan tes relevan. Jelaskan cara mengaktifkan hook, perilaku ketika command gagal, dan cara memasangnya pada clone baru. Jangan menonaktifkan pemeriksaan untuk membuat commit lolos. Tunjukkan rencana uji dengan pelanggaran yang disengaja dan versi yang sudah diperbaiki.

Contoh hasil yang diharapkan: Hook harus mengembalikan kegagalan ketika pemeriksaan gagal. Tes penerimaan: pelanggaran terdeteksi, commit lokal diblokir, lalu versi bersih lolos.

Kriteria selesai: Hook terbukti berjalan; kegagalan diteruskan; CI mengulang pemeriksaan penting; keterbatasan bypass diketahui.

Kesalahan yang perlu dihindari: Menyamakan file instruksi dengan kontrol akses atau mengira hook lokal tidak dapat dilewati.

15. Jadikan pengalaman sebagai prosedur yang bisa dipakai ulang

Setelah satu alur berhasil, rangkum prosedur yang benar-benar teruji menjadi bahan skill. Dokumentasi Claude Code menjelaskan skill sebagai direktori dengan SKILL.md yang berisi instruksi, dan dapat membawa berkas pendukung. Dalam paket ini yang disertakan adalah lembar rancangan, bukan skill yang sudah dipasang atau diuji pada alat tertentu.

Rujukan teknis pendamping: [Claude-skills (2026/10), Create a skill]. Contoh penerapan TaskFlow di bawah merupakan rancangan editorial.

Langkah praktik

1. Pilih pekerjaan yang memang berulang.

2. Catat pemicu, input, langkah, dan keluaran.

3. Tambahkan batas penggunaan dan contoh gagal.

4. Uji rancangan pada tugas baru sebelum dipasang.

Prompt siap salin

Ubah pengalaman menyelesaikan fitur TaskFlow menjadi rancangan skill “implementasi-fitur-kecil”. Buat kapan digunakan dan kapan tidak, input wajib, urutan baca spesifikasi → rencana → implementasi → verifikasi → laporan, batas akses, serta format output. Sertakan contoh penggunaan dan tiga skenario evaluasi. Gunakan hanya langkah yang telah terbukti pada proyek; tandai bagian yang belum diuji. Jangan memasang skill atau mengubah konfigurasi global.

Contoh hasil yang diharapkan: Prosedur harus meminta spesifikasi yang kurang, mengerjakan satu fitur, menjalankan pemeriksaan yang tersedia, dan melaporkan kegagalan secara jujur.

Kriteria selesai: Orang lain dapat mengikuti prosedur; contoh gagal ditangani; hasil diuji pada lebih dari satu fitur.

Kesalahan yang perlu dihindari: Membungkus prompt panjang menjadi skill tanpa menguji pemicu dan kualitas hasilnya.

Bonus: checklist sebelum dan sesudah rilis

Checklist ini merupakan rekomendasi latihan. Sesuaikan dengan penyedia hosting dan risiko aplikasi.

- [ ] Jalankan pemeriksaan relevan dari kondisi proyek yang bersih; catat perintah dan hasil.

- [ ] Periksa konfigurasi untuk lingkungan staging dan produksi secara terpisah.

- [ ] Periksa ulang akses antar pengguna, penanganan sesi habis, dan kegagalan simpan.

- [ ] Pastikan rahasia tidak berada dalam berkas yang dikirim ke browser atau riwayat Git.

- [ ] Cadangkan data dan uji cara pemulihan sebelum menjalankan migrasi produksi.

- [ ] Catat versi rilis, perubahan struktur data, dan orang yang menangani gangguan.

- [ ] Uji di staging: masuk, tambah tugas, refresh, ubah status, hapus, keluar.

- [ ] Rilis hanya ke akun dan tujuan yang telah ditentukan pemilik proyek.

- [ ] Jalankan smoke test setelah rilis; pantau kesalahan tanpa mencatat token atau data pribadi.

- [ ] Jika rilis gagal, jalankan rencana pemulihan; periksa kompatibilitas data sebelum mengembalikan kode lama.

Contoh sesi pertama

Mulai dengan prompt konteks dan prompt 01. Baca PRD, perbaiki batas fitur, lalu jalankan prompt 02–05 untuk menyiapkan dokumen. Pilih satu tugas kecil dari rencana dengan prompt 06. Jika hasil gagal, gunakan prompt 10; jangan menumpuk fitur baru. Setelah satu alur stabil, lengkapi pengujian 08–11, rapikan 12–14, lalu dokumentasikan proses yang terbukti pada 15. Lewati 07 bila integrasi tidak dibutuhkan.

5. Status materi dan batas penggunaan

Referensi ditinjau pada 28 Oktober 2026 melalui Parallel Search dan TinyFish. Bulan pada sitasi dokumentasi menandai waktu akses, bukan tanggal publikasi. Antarmuka alat, konfigurasi, dan perintah dapat berubah; periksa dokumentasi yang sesuai dengan versi terpasang. Panduan ini tidak mengklaim bahwa contoh TaskFlow sudah dibangun, diuji, atau diaudit.

Gambar dibuat dengan ImageGen sebagai ilustrasi editorial. Gambar tidak menjadi bukti perilaku perangkat lunak. Feature image dan 15 ilustrasi bab disertakan terpisah. Prompt generasi disediakan agar visual dapat ditinjau atau dibuat ulang; hasil generasi ulang tidak dijamin identik.

Daftar sumber

[Claude-praktik, 2026/10] Anthropic. Best practices for Claude Code. Dokumentasi resmi, diakses 28 Oktober 2026. https://code.claude.com/docs/en/best-practices

[Claude-memory, 2026/10] Anthropic. How Claude remembers your project. Dokumentasi resmi, diakses 28 Oktober 2026. https://code.claude.com/docs/en/memory

[MCP-security, 2026/10] Model Context Protocol. Security Best Practices. Dokumentasi resmi, diakses 28 Oktober 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices

[Supabase-RLS, 2026/10] Supabase. Row Level Security. Dokumentasi resmi, diakses 28 Oktober 2026. https://supabase.com/docs/guides/database/postgres/row-level-security

[Playwright, 2026/10] Microsoft. Best Practices — Playwright. Dokumentasi resmi, diakses 28 Oktober 2026. https://playwright.dev/docs/best-practices

[Git-hooks, 2026/10] Git. githooks. Dokumentasi resmi, diakses 28 Oktober 2026. https://git-scm.com/docs/githooks

[Claude-skills, 2026/10] Anthropic. Extend Claude with skills. Dokumentasi resmi, diakses 28 Oktober 2026. https://code.claude.com/docs/en/skills

[Claude-hooks, 2026/10] Anthropic. “Automate actions with hooks.” Dokumentasi resmi, diakses 28 Oktober 2026. https://code.claude.com/docs/en/hooks-guide

[Gambar-pengguna, tanggal tidak diketahui] Infografik “15 Vibe Coding Prompts”, lampiran percakapan. Dipakai sebagai daftar topik; identitas penerbit dan tanggal publikasi tidak diverifikasi.