Cara menulis brief tugas pertama untuk Claude Code

“Tolong rapikan bagian README di repositori ini, bikin yang enak dilihat.”

Tiga puluh menit setelah memasang Claude Code, itulah permintaan pertama yang saya lempar. Yang kembali bukan cuma README: nama script di package.json ikut berubah. Memang masih jalan, tapi ada tiga file yang berubah di tempat yang sama sekali tidak saya minta. Saya cuma diam di depan layar sambil mikir, “Ini boleh di-publish nggak, ya?”

Kenapa Claude Code yang katanya pintar malah menyentuh tempat yang tidak diminta? Itu bukan soal kemampuan. Masalahnya, saya tidak pernah menentukan satu pun batas “boleh sampai mana”. Mirip menyuruh pegawai baru “tolong jaga toko, bikin rapi ya” lalu pergi, dan pulang-pulang seluruh rak sudah ditata ulang.

Artikel ini soal menuliskan “sampai mana” itu dalam satu lembar. Saya menyebutnya brief tugas pertama (brief untuk permintaan pertama).

Poin penting

• Tugas pertama sering kebablasan karena kita minta “bikin enak dilihat” tanpa menentukan tujuan, area yang diizinkan, verifikasi, dan cara rollback.
• Brief berisi 9 isian: tujuan / kondisi pembaca / boleh dibaca / boleh diedit / boleh dijalankan / jangan disentuh / verifikasi / cara rollback / langkah berikutnya.
• Yang didelegasikan ke Claude Code: “membaca, memperbaiki, menjalankan command verifikasi”. Penghapusan, rilis ke produksi, dan operasi berbayar tetap diputuskan manusia.
• Tersedia template brief siap salin plus skrip JavaScript yang otomatis mengecek kekurangan isian brief.
• Pilih satu tugas kecil yang “kalau gagal bisa dikembalikan lewat git” sebagai jalan tercepat menuju keberhasilan pertama.

Kenapa tugas pertama mudah kebablasan

Begitu Claude Code terpasang, kebanyakan orang melempar “permintaan luas”: “rapikan repositori”, “perbaiki README”. Saya paham perasaannya, kita memang ingin coba apa saja yang bisa dilakukan.

Tapi permintaan luas membuat sepuluh menit pertama habis untuk eksplorasi. Claude Code membaca file ke sana ke mari, memperbaiki tempat yang sekiranya relevan sesuka hati, lalu menutup dengan laporan samar “kemungkinan jalan”. Anda akhirnya harus membaca ulang seluruh diff, dan kesimpulannya jadi “lebih cepat kalau saya kerjakan sendiri”.

Penyebabnya bukan kepandaian model, melainkan kita tidak menyerahkan tujuan dan batas. Pegawai baru sekalipun, kalau di hari pertama disuruh “kerjakan bebas”, akan berhenti bingung atau malah ngebut tak terkendali. Cukup tentukan batas lebih dulu, dan kecelakaan ini hampir hilang.

Kalau Anda masih ragu pada operasi dasarnya, baca dulu cara memulai Claude Code lalu kembali ke sini supaya pembahasan brief ini lebih mudah masuk.

Sembilan isian dalam brief

Inilah 9 isian yang setiap kali saya tulis dalam satu lembar. Tidak butuh istilah rumit. Cukup isi satu jawaban per baris.

Isian	Apa yang ditulis	Contoh buruk -> contoh baik
Tujuan	Kondisi apa yang berarti berhasil saat selesai	”Perbaiki README” -> “Samakan langkah README dengan package.json”
Kondisi pembaca	Pekerjaan ini untuk siapa	(kosong) -> “Pemula, ingin sekali ini berhasil pasti”
Boleh dibaca	File yang boleh dirujuk	(semua) -> “Hanya README.md dan package.json”
Boleh diedit	File yang boleh diubah	(semua) -> “Hanya README.md”
Boleh dijalankan	Command yang boleh dieksekusi	(apa saja) -> “Hanya npm run build”
Jangan disentuh	Area yang sama sekali tak boleh diubah	(tak disebut) -> “package-lock, setting deploy, harga”
Verifikasi	Bukti keberhasilan	”Asal jalan” -> “build lulus / diff hanya README”
Cara rollback	Cara mengembalikan saat gagal	(tidak ada) -> “Kembalikan README dari git”
Langkah berikutnya	Satu tujuan lanjutan untuk pembaca	(sebut 3) -> “Cukup materi pengantar gratis dulu”

Intinya ada di “jangan disentuh”, “verifikasi”, dan “cara rollback”. Begitu ketiga baris itu ditulis, permintaan berubah dari sekadar “tolong ya” menjadi “pekerjaan yang aman didelegasikan”.

Template brief siap salin

Ini kerangka yang bisa langsung dipakai. Sengaja saya taruh dalam blok kode supaya bisa langsung Anda tempel ke Claude Code. Ganti nama repositori dan area yang ingin diperbaiki sesuai milik Anda.

# Brief tugas pertama

Tujuan: Samakan langkah setup di README dengan isi package.json.
Kondisi pembaca: Pemula. Ingin sekali ini berhasil pasti.
Boleh dibaca:
- README.md
- package.json
Boleh diedit:
- README.md saja
Boleh dijalankan:
- npm run build
Jangan disentuh:
- package-lock.json
- Setting deploy (environment variable, konfigurasi publik)
- Harga atau link pendaftaran
Verifikasi:
- npm run build lulus
- git diff hanya menunjukkan perubahan README.md
Cara rollback:
- Jika verifikasi gagal, kembalikan README.md dari git
Langkah berikutnya:
- Cukup arahkan ke materi pengantar gratis dulu

Untuk contoh nyata, kalau cuma menyamakan langkah README dengan package.json, maka yang dibaca README dan package.json, yang diedit hanya README, dan buktinya npm run build. Dengan ukuran sekecil ini, kalaupun gagal cukup git checkout -- README.md sekali jalan. Tugas pertama memang sebaiknya sesempit ini. Justru karena sempit, Anda sendiri bisa menilai berhasil atau tidak.

Area yang didelegasikan ke Claude Code vs yang diputuskan manusia

Saat menulis brief, saya menarik garis ini di kepala. Kalau batasnya kabur, Claude Code akan melewati garis “dengan niat baik”.

Boleh diserahkan ke Claude Code	Diputuskan manusia (jangan diotomatiskan)
Membaca file yang ditentukan	Menentukan file mana yang boleh disentuh
Mengedit hanya file yang ditentukan	Menghapus file
Menjalankan command verifikasi seperti npm run build	Rilis / deploy ke produksi
Mengembalikan ringkasan diff	Operasi yang menimbulkan biaya
Melaporkan penyebab kegagalan	Operasi tak bisa dikembalikan seperti git push --force

Sisi kiri diserahkan. Sisi kanan, di awal, semua diatur “konfirmasi ke manusia sebelum dieksekusi”. Hanya operasi yang sudah terbukti aman yang belakangan dipindahkan sedikit demi sedikit ke sisi otomatis. Cukup taati urutan ini, dan frekuensi jantung dag-dig-dug tengah malam berkurang drastis.

Saat menyerahkan permintaan, saya menambahkan satu kalimat seperti ini.

Kerjakan satu tugas kecil hanya dalam scope brief ini.
Untuk hal yang Anda nilai di luar scope, jangan dieksekusi, cukup usulkan saja.

Pertama, kembalikan lima hal berikut:
1. File yang akan dibaca
2. File yang akan diedit
3. Command verifikasi yang dijalankan sebelum dan sesudah kerja
4. Ringkasan diff perubahan
5. Cara rollback saat gagal

Kuncinya adalah meminta “kembalikan rencana dan verifikasi sebelum implementasi”. Kalau rencana yang kembali melampaui scope brief, Anda bisa menghentikannya di tempat. Berhenti sebelum tangan bergerak berarti tidak ada yang perlu dibereskan.

Kode pengecek otomatis kekurangan brief

Sudah merasa menulis brief lengkap pun, isian sering terlewat. Saya mengecek ada-tidaknya isian secara mekanis. Ini JavaScript yang langsung jalan. Bisa dieksekusi di Node.js seperti node check-brief.mjs.

// Cek secara mekanis apakah isian wajib dalam brief sudah lengkap
const requiredFields = [
  "Tujuan",
  "Boleh dibaca",
  "Boleh diedit",
  "Boleh dijalankan",
  "Jangan disentuh",
  "Verifikasi",
  "Cara rollback",
  "Langkah berikutnya",
];

export function validateFirstTaskBrief(markdown) {
  // Cari isian yang belum tercantum
  const missing = requiredFields.filter((field) => !markdown.includes(field));

  // Cek juga apakah command verifikasi (di sini npm run build) sudah ditulis
  const hasProofCommand = markdown.includes("npm run build");

  return {
    ok: missing.length === 0,
    missing,
    readyForClaudeCode: missing.length === 0 && hasProofCommand,
  };
}

// Contoh pengujian
const sample = `
Tujuan: Samakan README dengan package.json
Boleh dibaca: README.md
Boleh diedit: README.md
Boleh dijalankan: npm run build
Jangan disentuh: package-lock.json
Verifikasi: npm run build lulus
Cara rollback: kembalikan README.md dari git
Langkah berikutnya: materi pengantar gratis
`;

const result = validateFirstTaskBrief(sample);
console.log(result);
// -> { ok: true, missing: [], readyForClaudeCode: true }

Kalau Anda lolos cek ini dulu baru menyerahkan brief, lupa menulis “jangan disentuh” dan “cara rollback” akan hilang. Kalau hanya mengandalkan mata manusia, di hari sibuk pasti ada yang terlewat. Hal yang bisa dikerjakan mesin sebaiknya diserahkan ke mesin agar lebih ringan.

Tiga situasi di mana ini ampuh

1. Perbaikan README atau dokumen panduan “Perbarui dokumentasi” punya scope tak terbatas. “Hanya bab setup di README, samakan dengan nama script di package.json” mempersempitnya: diff muat dalam satu file dan bisa dipastikan dengan npm run build. Ini paling cocok untuk tugas pertama.

2. Review pertama untuk pull request Bukan “lihat PR ini”, melainkan “baca hanya yang ada di bawah src/ dari file yang berubah, tunjukkan bagian yang berpotensi membuat test gagal. Jangan perbaiki kodenya, cukup tunjukkan saja”. Membaca didelegasikan, keputusan memperbaiki tetap di tangan manusia. Ini mencegah kecelakaan “diperbaiki sendiri lalu malah lahir bug lain”.

3. Mengganti CTA (jalur ke langkah berikutnya pembaca) Bahkan untuk mengganti satu tombol di bawah artikel populer, “cari komponen terkait lalu perbaiki” terlalu luas. Tentukan dulu di brief: “file yang boleh disentuh”, “URL publik yang dicek”, “link yang diganti”. Pengecekan setelah kerja berubah dari “kayaknya sih bagus” menjadi “dengan bukti ini layak rilis”.

Tiga kesalahan yang pernah saya buat

Saya tulis jujur. Sebelum mulai memakai brief, saya berulang kali melakukan kesalahan yang sama.

Pertama, tidak menulis “jangan disentuh”. Padahal saya cuma minta perbaiki README, Claude Code dengan niat baik ikut merapikan package.json, dan build jadi gagal. Cukup menambahkan tiga baris Jangan disentuh: package-lock.json, setting deploy, dan ini tak pernah terjadi lagi.

Kedua, meloloskan verifikasi dengan “asal jalan”. Karena tidak menentukan apa arti “jalan”, setiap kali saya mengejar diff dengan mata sampai habis. Setelah saya ubah jadi command konkret Verifikasi: npm run build lulus / diff hanya README, pengecekan selesai dalam 10 detik.

Ketiga, menyebut tiga langkah berikutnya sekaligus. Saat saya tempel materi, modul belajar, dan ajakan konsultasi semua di akhir artikel, reaksi pembaca jadi kabur. Setelah dipersempit jadi satu sesuai kondisi pembaca, justru yang satu itu benar-benar diklik. Apa yang harus ditulis sebaiknya disimpan sebagai aturan proyek di cara menulis CLAUDE.md agar tidak goyah setiap kali.

Pertanyaan umum

T. Menulis sembilan isian ini setiap kali kan merepotkan? Hanya beberapa kali pertama. Buat satu template dan simpan sebagai first-task-brief.md, lalu berikutnya cukup ganti 3-4 baris isinya. Waktu menulis brief jauh lebih singkat dibanding waktu membaca ulang diff yang kebablasan.

T. Apakah tugas sederhana juga butuh brief? Untuk level “perbaiki satu typo di satu file”, permintaan lisan sudah cukup. Brief ampuh untuk pekerjaan yang berpotensi menyentuh banyak file, atau yang menyenggol produksi, biaya, dan penghapusan. Kalau ragu, tulis saja, tidak akan rugi.

T. Sebaiknya pakai nama key berbahasa Inggris (Goal, May edit, dst.)? Kalau Anda menjajarkan log tim untuk dibandingkan, key Inggris yang seragam memang praktis. Tapi untuk pemakaian sendiri, bahasa Indonesia sudah cukup. Claude Code paham keduanya. Yang penting bukan bahasanya, melainkan tidak ada isian yang terlewat.

T. Apakah orang yang tidak ngoding bisa pakai? Bisa. Untuk menulis artikel atau merapikan materi pun, pola pikir “boleh dibaca, boleh diedit, jangan disentuh” tetap sama. Pintu masuk untuk non-engineer saya rangkum di Claude Code untuk yang bukan engineer.

T. Bagaimana kalau Claude Code mengabaikan brief dan menyentuh di luar scope? Pertama, minta “kembalikan rencana dan verifikasi dulu”, dan hentikan sebelum tangan bergerak, itu prinsip dasarnya. Kalau masih melewati batas, kemungkinan besar “jangan disentuh” Anda belum konkret. Sebutkan sampai ke nama folder dan nama file agar lebih ampuh.

Hasil setelah saya coba sendiri

Mencoba brief ini pada tugas kecil menyamakan README dengan package.json adalah cara paling mudah dipahami. Dengan menulis lebih dulu Boleh diedit: README.md saja, alur Claude Code yang akan menjangkau package-lock atau file konfigurasi berhenti di tahap rencana, sebelum eksekusi. Hilangnya beban membaca ulang diff itu yang paling terasa.

Memasukkan dua hal npm run build dan git diff ke Verifikasi juga ampuh. Keputusan setelah kerja berubah dari “kayaknya bagus” menjadi pernyataan tegas: “build hijau, diff hanya README, jadi layak rilis”. Sebaliknya, sesi saat saya biarkan Langkah berikutnya kosong, saya sendiri bingung “tadi mau arahkan ke mana ya”, dan jalur di akhir artikel jadi kabur.

Yang akhirnya saya pahami: memberi Claude Code kebebasan besar bukanlah nilainya. Potong tugas pertama jadi kecil, lalu buat keberhasilan, kegagalan, dan langkah berikutnya terlihat dengan mata Anda sendiri. Inilah yang paling cepat. Repotnya menulis satu lembar batas itu tidak ada apa-apanya dibanding repotnya membaca ulang diff yang kebablasan.

Kalau ingin mendalami mekanisme di luar brief, cek perilaku pengaturan izin di dokumentasi resmi Claude Code dari Anthropic, agar pembagian peran antara brief dan konfigurasi jadi jelas. Kalau Anda ingin memasukkan Claude Code ke pekerjaan kantor sekaligus menata aturan operasionalnya, lewat pelatihan dan konsultasi kita bisa mulai bersama dari membangun pola brief yang pas dengan pekerjaan nyata Anda.