---
title: "6 Prinsip Prompt untuk Meningkatkan Kualitas Hasil Claude Code"
locale: id
category: tutorial
category_name: "Tutorial"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/claude-code-prompt-six-principles-and-templates
published_at: 2026-08-23T02:30:01+09:00
---

# 6 Prinsip Prompt untuk Meningkatkan Kualitas Hasil Claude Code

> Menjelaskan cara menyampaikan konteks, kontrak output, penanganan pengecualian, dan kriteria verifikasi secara terstruktur, alih-alih sekadar meminta Claude Code membuat kode. Juga menyediakan templat prompt yang dapat langsung diterapkan untuk mengembangkan agen baru, menambahkan fitur, dan memperbaiki kesalahan.

## Key Points

- 1. Sebelum memulai pekerjaan, rangkum konteks pengguna, masalah yang harus diselesaikan, kriteria keberhasilan, dan batasan teknis dalam satu dokumen.
- 2. Tetapkan struktur file, format data, cakupan yang diizinkan, dan syarat penyelesaian hasil sebagai kontrak output yang konkret.
- 3. Tentukan pengecualian yang dapat diperkirakan, seperti kegagalan API eksternal, hasil kosong, data duplikat, dan kesalahan autentikasi, beserta kebijakan penanganannya.
- 4. Bagi pekerjaan menjadi tahap peninjauan rencana, implementasi fungsi minimum, pengujian otomatis, dan perluasan fitur, lalu periksa hasil pada setiap tahap.
- 5. Alih-alih meminta pengerjaan ulang secara ambigu, berikan contoh kegagalan dan target perbaikan yang dapat diukur, lalu verifikasi berdasarkan syarat penerimaan akhir.

Agen coding seperti Claude Code bukan sekadar alat untuk menghasilkan sepotong kode, melainkan lingkungan kerja yang dapat menjelajahi repositori, mengubah beberapa file, serta menjalankan pengujian dan perintah. Karena itu, kualitas hasil lebih banyak ditentukan oleh **seberapa jelas ruang lingkup pekerjaan dan metode verifikasi didefinisikan** daripada seberapa meyakinkan kalimat yang dihasilkan.

Prompt yang baik bukanlah uraian panjang, melainkan spesifikasi pekerjaan yang dapat dijalankan. Prompt harus menyampaikan bukan hanya apa yang harus dibuat, tetapi juga mengapa hal itu diperlukan, ketentuan apa yang harus dipatuhi, bagaimana menangani kegagalan, dan apa yang harus lolos agar pekerjaan dianggap selesai.

## Hal yang Harus Dibedakan Terlebih Dahulu: Prompt dan Lingkungan Eksekusi

Vibe coding adalah metode kolaborasi yang menyampaikan maksud melalui bahasa alami dan menyerahkan implementasinya kepada agen AI. Namun, fakta bahwa permintaan disampaikan dalam bahasa alami tidak menjamin keakuratan kode atau stabilitas operasional.

Dalam pekerjaan Claude Code, unsur-unsur berikut bekerja bersama-sama.

| Unsur | Peran | Hal yang perlu diperiksa dalam prompt |
|---|---|---|
| Permintaan pengguna | Menyampaikan tujuan dan ruang lingkup perubahan | Tujuan, prioritas, hal yang dilarang |
| Konteks repositori | Menyediakan struktur dan aturan yang sudah ada | Framework, perintah eksekusi, file terkait |
| `CLAUDE.md` | Menyediakan panduan proyek yang diterapkan berulang kali | Aturan coding, metode pengujian, konvensi direktori |
| Izin alat | Mengendalikan cakupan yang diizinkan untuk perubahan file dan eksekusi perintah | Perintah yang boleh dijalankan dan pekerjaan yang memerlukan konfirmasi terlebih dahulu |
| Koneksi eksternal | Mengakses API, database, server MCP, dan sebagainya | Metode autentikasi, batas kepercayaan, kebijakan kegagalan |
| Prosedur verifikasi | Menilai apakah hasil memenuhi persyaratan | Pengujian, analisis statis, butir pemeriksaan manual |

Menulis prompt dengan baik saja tidak menyelesaikan semua masalah. Sebagai contoh, Claude Code dapat membuat kode eksekusi terjadwal, tetapi agar pekerjaan tetap berjalan ketika komputer mati, diperlukan server terpisah, layanan CI, atau penjadwal sistem operasi. Pengiriman email juga tidak dapat diselesaikan tanpa informasi autentikasi dan izin pengiriman dari penyedia yang sebenarnya.

## Prinsip 1. Jelaskan Latar Belakang, Tujuan, dan Batasan Terlebih Dahulu

Jika hanya menyebutkan nama hasil yang diinginkan seperti `Buatkan agen pengumpul berita`, agen harus menebak pengguna, sumber data, lingkungan eksekusi, dan kriteria keberhasilannya. Meskipun sama-sama berupa pengumpul berita, staf pengembangan bisnis, investor, dan editor surat kabar kampus membutuhkan sumber serta kriteria klasifikasi yang berbeda.

### Permintaan yang Tidak Memadai

```text
Buatkan agen pengumpul berita AI.
```

### Permintaan yang Ditingkatkan

```text
Saya adalah staf pengembangan bisnis di startup TI.
Setiap hari sebelum mulai bekerja, saya ingin meninjau dengan cepat berita
di bidang AI, cloud, dan fintech yang dapat memengaruhi kemitraan bisnis
atau strategi produk.

Tujuan:
- Mengumpulkan kandidat artikel terbaru untuk setiap kata kunci yang ditentukan.
- Menghapus artikel dengan URL yang sama dan artikel duplikat dengan judul serupa.
- Mengklasifikasikan dampaknya sebagai tinggi, sedang, atau rendah berdasarkan
  apakah keputusan produk atau kemitraan diperlukan dalam waktu 3 bulan.
- Membuat hasilnya menjadi briefing email dalam bahasa Korea.

Batasan:
- Pertahankan versi Python dan metode pengelolaan paket yang digunakan repositori saat ini.
- Sebelum menambahkan library baru, jelaskan kebutuhan dan alternatifnya.
- Jangan mencatat API key dan kata sandi email dalam kode atau log.
- Sebelum benar-benar mengirim email, hanya buat file pratinjau.

Periksa terlebih dahulu struktur repositori dan cara menjalankannya,
lalu usulkan rencana implementasi.
Jangan menebak informasi lingkungan yang tidak diketahui,
tetapi susun sebagai daftar pertanyaan.
```

Informasi latar belakang yang baik mencakup empat hal berikut.

1. **Pengguna dan situasi penggunaan:** Siapa yang menggunakannya, kapan, dan untuk keputusan apa
2. **Tujuan:** Masalah apa yang harus diselesaikan, bukan sekadar menulis kode
3. **Batasan:** Teknologi apa yang harus dipertahankan serta aturan keamanan, batas biaya, atau batas waktu apa yang berlaku
4. **Bukan tujuan:** Fitur apa yang secara eksplisit dikecualikan dari perubahan kali ini

Menuliskan hal yang bukan tujuan dapat mencegah ruang lingkup berkembang tanpa batas. Sebagai contoh, dengan menetapkan `Pada tahap ini, eksekusi terjadwal dan pengiriman email sebenarnya dikecualikan`, logika pengumpulan dan klasifikasi dapat diverifikasi terlebih dahulu secara stabil.

## Prinsip 2. Jadikan Format Output yang Diinginkan sebagai Kontrak Output

`Kirimkan melalui email agar enak dilihat` dapat ditafsirkan berbeda oleh setiap orang. Untuk format output, jangan hanya menunjukkan contoh, tetapi definisikan juga field wajib, nilai yang diizinkan, cara menangani data yang tidak tersedia, dan urutan pengurutan.

```text
Subjek email:
[Briefing Berita] {YYYY-MM-DD} Berita Utama Hari Ini

Format artikel dalam isi:
1. {Judul}
Ringkasan: {1~2 kalimat dalam bahasa Korea}
Dampak: {Tinggi|Sedang|Rendah}
Alasan penilaian: {1 kalimat}
Sumber: {Nama media}
Tautan: {URL asli}

Aturan pengurutan:
1. Urutkan dari dampak tertinggi
2. Jika dampaknya sama, urutkan dari waktu publikasi terbaru

Statistik bagian bawah:
- Jumlah seluruh artikel
- Jumlah artikel menurut tingkat dampak
- Kata kunci yang tidak memiliki hasil pencarian

Batasan:
- Jangan membuat angka atau klaim yang tidak terdapat dalam sumber asli di dalam ringkasan.
- Jika tanggal tidak dapat diverifikasi, jangan memperkirakannya dan tandai sebagai 'Tidak dapat diverifikasi'.
- Kecualikan item tanpa tautan dari briefing akhir.
```

Jika hasil harus diteruskan antarprogram, sebaiknya minta skema JSON atau definisi tipe bersama contoh yang dapat dibaca manusia.

```json
{
  "title": "string",
  "summary": "string",
  "impact": "high | medium | low",
  "reason": "string",
  "source": "string",
  "url": "absolute URL",
  "published_at": "ISO 8601 string | null"
}
```

Kontrak output tidak hanya mencakup format, tetapi juga makna. Jika tidak ada kriteria penilaian mengenai arti `impact: high`, sintaks JSON mungkin benar, tetapi hasil klasifikasinya bisa tidak konsisten.

## Prinsip 3. Nyatakan Situasi Pengecualian dan Kebijakan Pemulihan

Kualitas kode operasional terlihat pada jalur kegagalan, bukan pada jalur normal. Prompt harus mencantumkan kegagalan yang dapat diperkirakan, apakah percobaan ulang diperbolehkan, kondisi yang harus diberitahukan kepada pengguna, dan informasi yang tidak boleh dicatat.

| Situasi pengecualian | Contoh kebijakan yang disarankan |
|---|---|
| Tidak ada hasil pencarian | Lewati kata kunci tersebut dan catat dalam statistik akhir |
| Kesalahan jaringan sementara | Coba ulang hanya dalam jumlah terbatas dengan interval tertentu |
| Kegagalan autentikasi | Jangan mencoba ulang; segera hentikan dan berikan panduan untuk memeriksa konfigurasi |
| Batas penggunaan API | Patuhi petunjuk waktu tunggu dalam respons dan larang percobaan ulang tanpa batas |
| Artikel duplikat | Hapus berdasarkan URL yang dinormalisasi dan tingkat kemiripan judul |
| Data dengan format yang salah | Pertahankan data asli dan isolasi hanya item tersebut |
| Kegagalan pengiriman email | Jika masih gagal setelah dicoba ulang, catat notifikasi alternatif atau status kegagalan |
| Keberhasilan sebagian | Laporkan hasil yang berhasil dan item yang gagal secara terpisah |

Kebijakan dapat diminta secara spesifik seperti berikut.

```text
Perlakukan waktu tunggu jaringan yang habis sebagai kesalahan yang dapat dicoba ulang.
Berikan waktu tunggu di antara setiap percobaan ulang, dan jika jumlah maksimum
terlampaui, tandai hanya sumber tersebut sebagai gagal.
Kesalahan autentikasi dan permintaan yang salah tidak akan terselesaikan
meskipun diulang, jadi segera hentikan.

Dalam semua log kesalahan, catat waktu, tahap pekerjaan, sumber, dan jenis kesalahan,
tetapi jangan mencatat API key, alamat email lengkap, header autentikasi,
atau teks lengkap isi artikel.
Bedakan keberhasilan penuh, keberhasilan sebagian, dan kegagalan penuh
melalui status penghentian proses.
```

Nilai seperti `coba ulang tiga kali` atau `tunggu 5 detik` bukanlah jawaban universal. Nilai tersebut harus ditentukan dalam proyek berdasarkan batas resmi layanan eksternal, urgensi pekerjaan, dan risiko eksekusi duplikat. Pekerjaan yang memiliki efek samping seperti pembayaran atau pengiriman pesan dapat diproses secara duplikat jika dicoba ulang secara otomatis tanpa jaminan idempotensi.

## Prinsip 4. Kembangkan Secara Bertahap dalam Urutan Perencanaan, Implementasi Minimum, dan Verifikasi

Jika beberapa layanan eksternal dan eksekusi otomatis dihubungkan sekaligus, penyebab kesalahan akan sulit dipisahkan. Dengan membagi implementasi menjadi unit verifikasi kecil, input dan output setiap tahap dapat diperiksa.

### Urutan Proses yang Disarankan

1. Periksa struktur repositori, file terkait, dan perintah eksekusi.
2. Minta agen menyajikan rencana dan file yang akan terdampak sebelum mengubah kode.
3. Implementasikan fungsi pengumpulan dengan satu kata kunci dan data sampel tetap.
4. Uji deduplikasi dan klasifikasi dampak secara terpisah.
5. Verifikasi email melalui pratinjau lokal, bukan pengiriman sebenarnya.
6. Setelah pengujian lolos, tambahkan integrasi dengan penyedia sebenarnya dan eksekusi terjadwal.

Permintaan pertama dapat dibatasi sebagai berikut.

```text
Sekarang hanya lakukan tahap 1.
Periksa repositori dan laporkan hal-hal berikut.
- Titik masuk aplikasi saat ini
- Modul dan file pengujian terkait
- Metode pengelolaan paket serta perintah pengujian yang digunakan
- File yang diperkirakan perlu diubah
- Pertanyaan yang harus diputuskan sebelum implementasi

Jangan ubah file apa pun terlebih dahulu.
```

Setelah meninjau rencana, implementasikan dengan mempersempit ruang lingkup perubahan.

```text
Dari rencana yang telah disetujui, implementasikan hanya pengumpulan berita dan deduplikasi.
Jangan tambahkan klasifikasi, pengiriman email, atau eksekusi terjadwal.
Pastikan dapat dijalankan dengan data pengujian tetap,
dan pada bagian akhir rangkum file yang diubah serta hasil pengujian yang dijalankan.
```

Jika mode khusus perencanaan tersedia di lingkungan Claude Code, mode tersebut dapat dimanfaatkan pada tahap eksplorasi dan desain. Namun, fakta bahwa rencana terlihat meyakinkan tidak berarti implementasinya akurat, sehingga pengujian sebenarnya dan tinjauan kode tetap harus dilakukan setelahnya.

## Prinsip 5. Sampaikan Umpan Balik melalui Kasus Kegagalan dan Angka

`Hasilnya kurang bagus`, `Kinerjanya lambat`, atau `Klasifikasinya salah` menyulitkan penentuan arah perbaikan. Sampaikan kondisi saat ini, kondisi yang diharapkan, input untuk mereproduksi masalah, dan rentang perubahan yang dapat diterima.

### Permintaan Perubahan Panjang

```text
Saat ini, isi email yang dihasilkan memiliki panjang sekitar 3.000 karakter.
Saya ingin menguranginya menjadi maksimal 500 karakter agar dapat dibaca cepat di perangkat seluler.
Batasi ringkasan setiap artikel menjadi 1~2 kalimat dan pertahankan alasan penilaian.
Hubungkan URL asli pada judul dan hapus baris tautan terpisah.
Pertahankan statistik di bagian bawah.
```

### Permintaan Perubahan Kriteria Klasifikasi

```text
Dari 10 data pengujian, 8 diklasifikasikan sebagai 'Tinggi'.
Klasifikasikan prospek teknologi jangka panjang atau pengenalan produk umum sebagai 'Rendah'.
Klasifikasikan sebagai 'Tinggi' hanya jika terdapat bukti konkret bahwa keputusan
mengenai harga, roadmap produk, respons terhadap regulasi, atau kemitraan
harus diubah dalam waktu 3 bulan.

Dalam kasus yang dilampirkan, jawaban yang benar adalah A dan B sebagai Tinggi,
serta C sebagai Rendah.
Perbaiki aturan klasifikasi dan tambahkan kasus-kasus ini sebagai pengujian regresi.
```

### Permintaan Perubahan Kinerja

```text
Waktu eksekusi rata-rata untuk input sampel yang sama saat ini sekitar 45 detik.
Targetnya adalah maksimal 30 detik dalam lingkungan yang sama.
Pertama-tama, ukur waktu setiap tahap dan tunjukkan bottleneck.
Jangan menghapus akurasi hasil maupun penanganan kesalahan,
bandingkan dampak dan risiko dari opsi perbaikan,
lalu terapkan perubahan terkecil terlebih dahulu.
```

Angka kinerja hanya dapat dibandingkan jika lingkungan pengukuran dan data inputnya sama. Jangan menyimpulkan bahwa kinerja telah meningkat hanya berdasarkan satu hasil eksekusi; metode pengukuran, sampel, dan status cache juga harus ditetapkan bersama.

## Prinsip 6. Gunakan Templat Prompt Berdasarkan Jenis Pekerjaan

### Templat Pembuatan Agen Baru

```text
[Peran dan situasi]
Saya adalah {pekerjaan/peran} dan ingin menyelesaikan {situasi masalah}.
Hasil ini akan digunakan oleh {pengguna atau sistem lanjutan}.

[Tujuan]
{Hasil yang harus dicapai dan kriteria keberhasilan}

[Pemicu eksekusi]
{Eksekusi manual, peristiwa, waktu terjadwal, dan sebagainya}

[Input]
- Sumber data: {file/API/database}
- Field wajib: {daftar field}
- Metode autentikasi: {variabel lingkungan atau metode pengelolaan rahasia}

[Logika pemrosesan]
1. {Tahap 1}
2. {Tahap 2}
3. {Tahap 3}

[Kontrak output]
{Format file, skema, templat, aturan pengurutan dan data yang tidak tersedia}

[Penanganan pengecualian]
{Hasil kosong, waktu habis, kesalahan autentikasi, kebijakan kegagalan sebagian}

[Batasan dan bukan tujuan]
- Teknologi yang harus dipertahankan: {item}
- Hal yang dilarang: {item}
- Fitur yang dikecualikan dari pekerjaan kali ini: {item}

[Verifikasi]
- Pengujian yang harus lolos: {item}
- Hal yang harus disertakan dalam laporan penyelesaian:
  file yang diubah, perintah eksekusi, hasil pengujian, risiko yang tersisa

Periksa repositori terlebih dahulu dan ajukan rencana implementasi.
Jangan menebak informasi yang tidak diketahui; ajukan pertanyaan.
```

### Templat Penambahan Fitur yang Sudah Ada

```text
Tambahkan {fitur baru} ke {nama agen atau modul} yang sudah ada.
Fitur baru harus dijalankan setelah {tahap A yang sudah ada}
dan sebelum {tahap B yang sudah ada}.

Logika terperinci:
- {Kondisi dan aturan pemrosesan}
- {Format input dan output}
- {Tindakan saat terjadi kegagalan}

Ketentuan yang harus dipertahankan:
- Jangan mengubah antarmuka publik dan format konfigurasi yang sudah ada.
- Pertahankan semua pengujian yang sudah ada.
- Jangan mengubah file yang tidak terkait.

Jelaskan terlebih dahulu cakupan dampak dan risiko regresi,
lalu tambahkan pengujian yang mempertahankan perilaku lama sebelum mengimplementasikannya.
```

### Templat Perbaikan Kesalahan

```text
Reproduksi kesalahan berikut dan perbaiki akar penyebabnya.

Pesan kesalahan lengkap:
{Pesan kesalahan dan stack trace setelah informasi rahasia dan data pribadi dihapus}

Kondisi terjadinya:
- Perintah eksekusi: {perintah}
- Input: {input reproduksi minimum}
- Lingkungan: {sistem operasi, runtime, versi terkait}
- Waktu terjadinya: {pada tahap apa}

Perilaku yang diharapkan:
{Hasil yang seharusnya muncul jika berjalan normal}

Perilaku sebenarnya:
{Hasil yang diamati saat ini}

Permintaan:
1. Reproduksi kesalahan terlebih dahulu.
2. Jelaskan penyebab berdasarkan bukti.
3. Perbaiki dalam ruang lingkup sekecil mungkin.
4. Tambahkan pengujian regresi yang mencegah kesalahan yang sama.
5. Laporkan pengujian yang dijalankan dan risiko yang tersisa.
```

Saat menempelkan pesan kesalahan, informasi sensitif seperti API key, token sesi, data pelanggan, dan alamat internal harus dihapus.

## Contoh Lengkap: Permintaan Agen Briefing Berita

Contoh berikut menggabungkan keenam prinsip dalam satu permintaan.

```text
Saya adalah staf pengembangan bisnis di startup SaaS.
Setiap hari, saya hanya ingin memeriksa berita mengenai perubahan pasar AI,
cloud, dan fintech yang dapat mengubah keputusan produk atau kemitraan
dalam waktu 3 bulan.

Periksa repositori saat ini dan rancang alat briefing berita.
Pada tahap pertama, implementasikan hanya fungsi untuk membaca sampel JSON,
menghapus duplikat, mengklasifikasikan dampak, lalu membuat file pratinjau HTML.
Pencarian web, pengiriman email sebenarnya, dan eksekusi terjadwal
dikecualikan dari tahap ini.

Field input:
- title, url, source, published_at, body

Aturan pemrosesan:
- Jika URL yang telah dinormalisasi sama, anggap sebagai duplikat.
- Meskipun URL berbeda, tandai sebagai kandidat duplikat jika judulnya serupa.
- Klasifikasikan sebagai dampak 'Tinggi' hanya artikel yang memerlukan perubahan konkret
  dalam keputusan mengenai harga, respons terhadap regulasi, roadmap produk,
  atau kemitraan dalam waktu 3 bulan.
- Jika bukti tidak memadai, jangan menebak peringkat tinggi.

Output:
- Tampilkan judul, ringkasan 1~2 kalimat, dampak, alasan penilaian, sumber, dan URL.
- Urutkan dari dampak tertinggi.
- Tampilkan jumlah keseluruhan, jumlah duplikat yang dihapus,
  dan jumlah berdasarkan peringkat di bagian bawah.

Penanganan pengecualian:
- Jangan mengecualikan item yang tidak memiliki field wajib;
  catat dalam daftar kesalahan terpisah.
- Jangan memperkirakan tanggal yang salah dan pertahankan sebagai null.
- Jangan meninggalkan isi lengkap artikel atau informasi autentikasi dalam log.

Verifikasi:
- Uji input normal, input kosong, URL duplikat, tanggal yang salah,
  dan field wajib yang tidak tersedia.
- Jika terdapat pengujian yang sudah ada, semuanya harus lolos.

Urutan pekerjaan:
1. Periksa struktur repositori dan file terkait.
2. Sajikan file yang akan diubah dan rencana pengujian.
3. Jangan mengubah kode sebelum saya memeriksa rencana tersebut.
4. Setelah disetujui, implementasikan fungsi minimum dan laporkan hasil pengujian.
```

Permintaan ini tidak meminta agar semua fungsi yang diperlukan diterapkan sekaligus ke lingkungan operasional. Ruang lingkupnya terbatas, sementara makna output, penanganan kegagalan, dan butir pengujian didefinisikan bersama, sehingga hasilnya mudah dinilai.

## Kriteria Kualitas yang Mudah Terlewat Jika Hanya Mengandalkan Prompt

Banyak panduan vibe coding berfokus pada penulisan instruksi yang lebih terperinci. Namun, unsur tambahan yang menentukan kualitas sebenarnya adalah **kemampuan verifikasi, pengendalian perubahan, observabilitas, dan batas keamanan**.

### 1. Ubah Kriteria Penerimaan Menjadi Pengujian

Alih-alih mengatakan `Buat agar berfungsi dengan baik`, berikan pasangan input dan output yang diharapkan. Simpan kasus klasifikasi penting sebagai pengujian regresi untuk memastikan hasil tetap dipertahankan dalam perubahan berikutnya.

### 2. Jangan Gunakan Penilaian Mandiri Agen sebagai Bukti Akhir

Pernyataan agen bahwa pekerjaan `selesai` berbeda dengan pengujian yang telah lolos. Minta agen melaporkan perintah yang dijalankan, hasil pengujian, file yang diubah, dan risiko yang belum terselesaikan, lalu manusia harus meninjau diff.

### 3. Minimalkan Izin dan Informasi Rahasia

Jangan memberikan sekaligus akses ke direktori yang tidak diperlukan, database produksi, dan kredensial deployment. Jangan masukkan API key secara langsung ke dalam prompt atau repositori; gunakan variabel lingkungan atau sistem pengelolaan rahasia yang disetujui. Jangan memberikan izin akses ke repositori sensitif kepada server MCP atau skrip yang sumbernya tidak diketahui.

### 4. Minta Kode yang Dapat Diobservasi

Dalam pekerjaan otomatis, simpan informasi yang diperlukan untuk menemukan penyebab gangguan, seperti status setiap tahap, kesalahan terstruktur, waktu eksekusi, dan jumlah item yang diproses. Sebaliknya, hapus informasi autentikasi dan data pribadi dari log.

### 5. Buat Perubahan agar Dapat Dikembalikan

Jangan mencampurkan refactoring yang tidak terkait dan penambahan fitur dalam satu perubahan. Meninjau diff dalam unit kecil dan mencatatnya dalam version control memudahkan pemisahan serta pengembalian perubahan yang salah.

## Tips Operasional Proyek Claude Code

- Catat aturan proyek yang berulang secara singkat dan spesifik dalam `CLAUDE.md`.
- Berikan perintah build, pengujian, dan lint dalam bentuk yang benar-benar dapat dijalankan.
- Jangan masukkan informasi rahasia, log kesalahan sementara, atau dokumen referensi panjang ke dalam `CLAUDE.md`.
- Sebelum perubahan berskala besar, minta agen memeriksa file terkait dan hubungan dependensinya terlebih dahulu.
- Saat menambahkan paket baru, tinjau kebutuhan, lisensi, dan risiko pemeliharaannya.
- Jangan menyetujui secara otomatis perintah berbahaya untuk penghapusan, deployment, atau perubahan data.
- Sebelum menghubungkan API eksternal atau MCP, periksa ke mana data dikirim.
- Saat selesai, minta agen merangkum file yang diubah, perintah eksekusi, hasil pengujian, dan batasan yang tersisa.

## Checklist Sebelum Mengirimkan Prompt

- [ ] Apakah pengguna dan situasi penggunaan telah dijelaskan?
- [ ] Apakah tujuan dan hal yang bukan tujuan telah dipisahkan?
- [ ] Apakah teknologi yang sudah ada dan ruang lingkup yang dilarang untuk diubah telah dinyatakan?
- [ ] Apakah data input dan format output telah didefinisikan?
- [ ] Apakah arti nilai klasifikasi dan nilai status telah dijelaskan?
- [ ] Apakah tersedia kebijakan untuk hasil kosong, kegagalan autentikasi, waktu habis, dan kegagalan sebagian?
- [ ] Apakah perencanaan dan implementasi telah dipisahkan per tahap?
- [ ] Apakah tersedia pengujian untuk kasus normal, kasus batas, dan kasus kegagalan?
- [ ] Apakah informasi rahasia dan data pribadi dikecualikan dari prompt serta log?
- [ ] Apakah diff dan bukti eksekusi yang akan ditinjau manusia telah diminta?

Inti prompt Claude Code yang baik bukanlah menulis perintah yang panjang. Intinya adalah mengurangi bagian yang harus ditebak oleh agen serta memungkinkan pihak ketiga mereproduksi dan menilai apakah hasilnya benar.

## FAQ

### Apakah prompt Claude Code semakin panjang semakin baik?
Yang lebih penting daripada panjangnya adalah apakah informasi yang diperlukan untuk tugas tercantum secara terstruktur. Latar belakang, tujuan, batasan, kontrak keluaran, penanganan pengecualian, dan kriteria penyelesaian sebaiknya ditulis secara spesifik, tetapi penjelasan yang tidak relevan dan instruksi yang berulang sebaiknya dihapus.

### Apakah tidak boleh meminta pembuatan seluruh program sejak awal?
Hal itu mungkin untuk alat kecil yang berdiri sendiri, tetapi tugas yang melibatkan API eksternal, basis data, email, dan eksekusi terjadwal sekaligus lebih aman dikembangkan secara bertahap. Dengan terlebih dahulu meninjau pemeriksaan repositori dan rencana, lalu memperluasnya secara berurutan mulai dari fungsi minimum, pengujian, hingga integrasi eksternal, penyebab kegagalan akan lebih mudah dipisahkan.

### Apakah pengujian boleh dilewati jika menggunakan Plan Mode?
Tidak. Mode perencanaan berguna untuk meninjau struktur dan pendekatan sebelum melakukan perubahan, tetapi tidak membuktikan keakuratan kode yang sebenarnya. Setelah implementasi, pengujian otomatis, analisis statis, peninjauan riwayat perubahan, dan pemeriksaan manual yang diperlukan harus dilakukan secara terpisah.

### Apa yang harus ditulis dalam CLAUDE.md?
Sebaiknya tuliskan instruksi yang berulang dalam berbagai tugas, seperti struktur proyek, aturan penulisan kode, perintah build dan pengujian, serta area yang tidak boleh diubah. Sebaiknya jangan memasukkan kunci API, kata sandi, informasi pribadi, penjelasan tugas sekali pakai, dan materi referensi yang terlalu panjang.

### Informasi apa yang harus diberikan dalam permintaan perbaikan kesalahan?
Pesan kesalahan dan pelacakan stack yang telah dibersihkan dari informasi sensitif, perintah eksekusi, input reproduksi minimum, lingkungan terkait, perilaku aktual, dan perilaku yang diharapkan harus diberikan bersama-sama. Sebaiknya minta juga penjelasan penyebab, perbaikan dengan cakupan minimum, pengujian regresi, dan hasil eksekusi.

### Apakah kunci API boleh diberikan kepada Claude Code melalui prompt?
Pada prinsipnya, jangan menuliskan kunci API yang sebenarnya secara langsung dalam prompt atau kode sumber. Gunakan variabel lingkungan atau sistem pengelolaan rahasia yang telah disetujui, dan pastikan informasi autentikasi juga tidak terekspos dalam log maupun hasil pengujian.

### Apakah jumlah percobaan ulang dan waktu tunggu harus selalu dicantumkan dalam prompt?
Untuk otomatisasi operasional, penting untuk membedakan kesalahan yang dapat dicoba ulang dan kesalahan yang mengharuskan penghentian segera. Namun, jumlah percobaan dan waktu tunggu yang spesifik harus ditentukan setelah memeriksa batasan layanan eksternal, urgensi tugas, dan risiko pemrosesan duplikat, serta tidak semua kesalahan boleh selalu dicoba ulang.

### Bagaimana cara menentukan apakah kode yang dihasilkan sudah selesai?
Penentuannya didasarkan pada kriteria penerimaan yang telah ditetapkan sebelumnya. Periksa apakah pengujian fungsi wajib dan kasus pengecualian telah berhasil, perintah yang dijalankan, berkas yang diubah, serta apakah batasan kinerja atau keamanan telah terpenuhi, dan manusia harus meninjau riwayat perubahan kode.

## Sources

- [Gambaran umum Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview)
- [Claude Code: Praktik terbaik untuk pengodean agentik](https://www.anthropic.com/engineering/claude-code-best-practices)
- [Repositori GitHub Anthropic Claude Code](https://github.com/anthropics/claude-code)

## Images

![Pengembang bekerja di depan monitor besar yang menampilkan kode dan diagram alur kerja](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNTQsInB1ciI6ImJsb2JfaWQifX0=--9f2d2e2c8a61fc294a6019e4807ece297f36e85a/ai-4caeb237.webp)
![Laptop dengan editor kode yang terhubung ke spesifikasi, tabel, galat, kontrol versi, dan grafik kinerja](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNjAsInB1ciI6ImJsb2JfaWQifX0=--285d7ecdc8209e07e0fc4eb68085cd8a304b9a81/ai-062b34c5.webp)