Runbook tugas pertama Claude Code: prompt aman, review diff, dan handoff

Tugas pertama menentukan apakah Claude Code terasa aman

Setelah memasang Claude Code, mudah sekali tergoda meminta satu fitur penuh, refactor besar, atau “perbaiki seluruh repo ini”. Di titik itulah banyak sesi pertama gagal. Biasanya masalahnya bukan Claude Code tidak mampu membantu, tetapi scope, verifikasi, izin, dan konteks proyek belum disepakati.

Runbook ini untuk tugas praktis pertama di repository nyata. Runbook berarti checklist operasi yang bisa diulang. Di sini, tugas pertama bukan “bangun fiturnya”, melainkan alur kecil: tulis permintaan dengan jelas, konfirmasi rencana, buat satu perubahan terbatas, review diff, lalu tinggalkan catatan handoff.

Jika dasar-dasarnya masih baru, mulai dari panduan awal Claude Code. Saat ingin mencatat aturan proyek, gabungkan dengan template CLAUDE.md untuk Claude Code. Untuk referensi resmi, gunakan Claude Code overview, memory dan CLAUDE.md, permission modes, common workflows, dan CLI reference.

flowchart LR
  A["Baca repository"] --> B["Daftar 3 opsi aman"]
  B --> C["Pilih 1 tugas"]
  C --> D["Review rencana dulu"]
  D --> E["Buat diff terkecil"]
  E --> F["Verifikasi test dan diff"]
  F --> G["Tulis catatan handoff"]

Ciri tugas pertama yang baik

Tugas pertama tidak terutama diukur dari besar hasilnya. Tugas ini menguji apakah alurnya bisa dipercaya terus. Tugas awal terbaik punya lima ciri.

Ciri	Arti sederhana	Contoh baik
Lokal	Tidak menyentuh production, data pelanggan, atau efek keluar	Cek command README atau tambah satu assertion
Terbatas	File dan titik selesai terlihat	Satu komponen, satu test, satu dokumen
Bisa diverifikasi	Command, halaman, atau diff membuktikan sukses	`npm.cmd run test`, `git diff --check`
Bisa dibatalkan	Hasil buruk mudah dibuang	File source biasa, bukan export generated
Bisa dijelaskan	Manusia paham alasan perubahan	Alasan, risiko, dan ketidakpastian tertulis

Permintaan seperti “ulang auth”, “modernisasi semua kode”, atau “perbaiki CI lalu deploy” adalah tugas pertama yang buruk. Semuanya mencampur konteks kurang, prompt izin, test lemah, dan diff yang sulit direview.

Untuk onboarding tim, pilih dari menu ini sebelum membuat tugas sendiri.

Tugas	Mengapa berguna	Syarat sukses
Petakan repository	Menguji pemahaman sebelum edit	Entry point, command, dan area berisiko ditemukan
Ringkas satu test gagal	Menunjukkan granularitas debugging	Titik gagal, hipotesis, dan langkah terkecil jelas
Perbaiki command README yang usang	Mencoba edit nyata yang rendah risiko	Command berjalan dan diff kecil
Tambah assertion ke test yang ada	Menguji pemahaman intent dan testing	Assertion melindungi perilaku yang jelas
Ubah satu teks UI	Menguji pencarian dan perubahan minimum	Hanya komponen target berubah
Perbaiki satu warning lint	Mengukur disiplin perubahan lokal	Satu warning hilang tanpa perubahan perilaku
Buat `CLAUDE.md` minimal	Memperbaiki sesi berikutnya	Command, batas, dan aturan review tertulis ringkas

Kuncinya adalah “kecil tetapi nyata”. Tugas harus terhubung ke onboarding, diagnosis bug, dokumentasi, test, atau kualitas review.

Template prompt siap pakai

Mulai dengan meminta Claude Code membaca dan mengusulkan, bukan mengedit.

Baca repository ini dan jangan edit dulu.

Kembalikan:
1. entry point utama
2. command build/test/lint yang umum
3. direktori berisiko atau file generated
4. 3 opsi tugas pertama yang aman untuk sesi 30 menit
5. cara memverifikasi dan rollback tiap opsi

Setelah opsi muncul, pilih satu dan minta rencana.

Lanjutkan hanya dengan opsi 2. Jangan edit dulu.
Tulis dulu file yang akan disentuh, alasan perubahan, diff yang diharapkan,
command verifikasi, dan risikonya. Jika scope melebar, usulkan opsi yang lebih kecil.

Baru setelah itu izinkan edit.

Ikuti rencana yang disetujui dan buat diff sekecil mungkin.
Jangan sentuh file di luar permintaan.
Setelah edit, rangkum command verifikasi yang dijalankan, check yang gagal atau dilewati,
dan risiko tersisa.

Gunakan prompt terpisah untuk review sebelum commit.

Lakukan review sebelum commit.

1. Baca git diff dan cari perubahan di luar permintaan
2. Cari test yang kurang atau verifikasi yang lemah
3. Cek risiko keamanan, kehilangan data, dan konfigurasi
4. Cari file yang tidak seharusnya ikut commit
5. Tandai keputusan yang masih perlu manusia

Akhiri dengan satu verdict: "siap commit", "perbaiki dulu", atau "hentikan".

Alur 30 menit

Pakai lima menit pertama untuk membekukan kondisi saat ini sebelum menyerahkan pekerjaan. Di Windows PowerShell:

Get-Location
git status --short
git branch --show-current
rg --files | Select-Object -First 40

Di macOS atau Linux:

pwd
git status --short
git branch --show-current
rg --files | head -n 40

Jika worktree sudah kotor, beri tahu perubahan mana yang milik manusia dan tidak boleh disentuh. Jika tidak, diff akhir sulit dinilai.

Gunakan sepuluh menit berikutnya untuk memilih satu tugas. Pilihan bagus: command README yang usang, satu assertion test, atau ringkasan satu test gagal. Hindari fitur baru pada sesi pertama.

Sekitar menit kedua puluh, prioritaskan bukti daripada edit tambahan. Satu perubahan benar dan dapat dijelaskan lebih bernilai daripada tiga perubahan tanpa verifikasi.

git diff --stat
git diff --check
git diff
git status --short

Simpan lima menit terakhir untuk catatan handoff. Catatan handoff adalah memo singkat untuk orang berikutnya atau sesi Claude Code berikutnya. Ini penting karena percakapan panjang bisa kehilangan batas awal, dan sesi berikutnya perlu titik mulai yang bersih.

Empat use case konkret

Use case 1: onboarding developer baru

Jangan beri issue besar pada hari pertama. Minta Claude Code membuat peta repo, command penting, direktori berbahaya, dan file pertama yang perlu dibaca.

Prompt: “Buat catatan onboarding untuk developer baru. Pisahkan fakta dari dugaan. Sertakan output command jika bisa.” Sukses berarti catatan memberi konteks praktis di luar README, seperti file generated, setting lokal, atau perbedaan CI dan lokal.

Use case 2: catatan reproduksi untuk bug yang terlihat

Jika bug-nya “kadang rusak”, jangan mulai dari fix. Minta kondisi, hasil yang diharapkan, hasil aktual, file terkait, dan log yang kurang. Ini cocok dengan template bug report Claude Code.

Sukses bukan patch. Sukses adalah catatan yang bisa diverifikasi manusia. Jika bug tidak bisa direproduksi, output harus menyatakannya dan menyebut log atau data berikutnya yang diperlukan.

Use case 3: dokumentasi atau teks UI

Situs marketing, admin tool, dan dashboard internal sering cocok untuk sesi pertama karena perubahan teks terlihat dan mudah dibatalkan. Tetap sempit: satu CTA, satu penjelasan setting, atau satu paragraf.

Sukses berarti hanya file target yang berubah, maknanya tetap, dan hasilnya bisa dicek lokal. Untuk situs multibahasa, cek juga agar tidak hanya satu bahasa yang diperbarui.

Use case 4: peningkatan test kecil

Jika proyek sudah punya test, menambah satu assertion lebih aman daripada menambah fitur. Tambahkan edge case, ekspektasi pesan error, atau kasus list kosong.

Test yang hijau saja tidak cukup. Claude Code harus menjelaskan perilaku apa yang dilindungi assertion. Assertion yang tidak bisa dijelaskan akan menjadi noise maintenance.

Review diff sebelum commit

Setelah Claude Code mengedit file, kembali ke review manusia. Untuk tugas pertama, hindari commit dan push otomatis. Permission modes menukar kenyamanan dengan pengawasan, jadi mulai dengan review normal atau plan mode. Hindari mode kuat seperti bypass permissions kecuali di lingkungan terisolasi.

Checklist sebelum commit

[ ] Hanya file yang diminta berubah
[ ] Tidak ada generated file, secret, atau setting lokal yang ikut
[ ] Hasil test atau verifikasi pengganti tercatat
[ ] Check yang gagal atau dilewati dinyatakan
[ ] Tidak ada diff yang tidak bisa dijelaskan
[ ] Catatan handoff berisi TODO berikutnya

Mulai dari git diff --stat untuk melihat sebaran. Jalankan git diff --check untuk whitespace dan kebersihan patch. Lalu baca diff untuk mencari refactor kejutan, rename, atau perubahan perilaku tanpa test.

Kegagalan yang sering terjadi

Kegagalan pertama adalah scope terlalu besar. Katakan “verifikasi pesan error login dengan satu test”, bukan “perbaiki login”. Beri otonomi setelah ada kepercayaan dari tugas kecil.

Kegagalan kedua adalah menerima “selesai” tanpa bukti. Jika tidak ada test, tentukan bukti pengganti: halaman yang dirender, type check, git diff --check, perbandingan log, atau command dari README.

Kegagalan ketiga adalah menyetujui prompt izin asal-asalan. Saat prompt muncul, tanya command apa yang berjalan, path mana yang disentuh, dan apakah ada network atau deletion. Jika prompt terlalu sering, approve command yang sempit daripada membuka semuanya.

Kegagalan keempat adalah kehilangan konteks. Percakapan panjang membuat batas awal kabur. Simpan batas tugas, command yang dijalankan, dan risiko tersisa di catatan handoff. Jangan campur aturan permanen CLAUDE.md dengan catatan satu sesi.

Kegagalan kelima adalah merusak pekerjaan yang belum dicommit. Di repo bersama, developer atau agen lain mungkin sudah punya perubahan. Mulai dengan git status --short dan lindungi perubahan yang tidak terkait.

Template handoff

Tempel ini di akhir tugas pertama.

## Handoff note

- Task:
- Changed files:
- Verification run:
- Verification not run:
- Important diff points:
- Remaining risks:
- Do not touch next time:
- Suggested next smallest task:

Catatan ini lebih luas daripada commit message. Sebelum commit, ia bisa menjadi bahan deskripsi PR. Tanpa commit, ia menjadi titik mulai untuk sesi berikutnya.

Langkah berikutnya dan jalur berbayar

Setelah tugas pertama berhasil, bangun repeatability. Pengguna solo sebaiknya mengubah aturan berulang menjadi template CLAUDE.md. Jika approvals dan sandbox masih belum jelas, baca panduan approval dan sandbox Claude Code.

Untuk template, checklist, dan materi onboarding siap pakai, lihat /products/. Untuk rollout tim, onboarding sesuai repository, desain permission, dan workflow review, gunakan /training/. Satu tugas pertama yang aman bisa ditangani dengan artikel ini. Rollout tim membutuhkan aturan, bukti, dan pelatihan sebelum penggunaan diperluas.

Dalam uji nyata Masa, pola paling stabil adalah: baca repo dulu, edit hanya satu file, review git diff bersama, dan tinggalkan catatan handoff. Sesi yang dimulai dengan permintaan besar menghasilkan pekerjaan review lebih banyak daripada penghematan. Sesi yang berhasil pada tugas 30 menit membuat tugas kedua lebih mudah dibatasi dan lebih mudah dijelaskan ke tim.