Cek 3 Menit Sebelum Commit: Pastikan Area yang Disentuh Claude Code

Jumat sore, saya cuma minta Claude Code, “tolong perbaiki teks tombol di artikel saja.” Begitu kembali dan menjalankan git status, file yang berubah ada 18. Padahal seharusnya cuma teks tombol, tapi yang muncul malah peta link produk, sisipan artikel terkait, sampai file terjemahan yang “sekalian dirapikan.”

Satu per satu memang perubahan “yang dibuat dengan niat baik.” Tapi kalau saya commit semuanya begitu saja, perubahan dari pekerjaan lain yang belum sempat disimpan ikut terbawa, dan keesokan harinya deploy meledak dengan error tanpa sebab yang jelas. Setengah hari habis cuma untuk mencari biang keroknya.

Makin pintar AI-nya, makin sering ia mengerjakan sedikit lebih luas dari yang diminta. Bukan dengan maksud jahat. Justru karena itu, kita butuh satu jeda tepat sebelum commit: “berhenti di sini dulu, biar mata manusia yang melihat.”

Poin penting

Claude Code patuh pada permintaan, tapi area yang ia sentuh diam-diam melebar. Cek sebelum commit adalah pekerjaan untuk menemukan “kelebihan” itu.
Cek dijalankan dalam urutan tetap selama 3 menit. Empat langkah: cek scope, cek diff, verifikasi, lalu pilih file untuk staging.
Yang diserahkan ke AI adalah “eksekusi perubahan”, yang diputuskan manusia adalah “sejauh mana yang masuk ke commit kali ini.” Jangan campur dua hal ini.
Saya sediakan skrip cek yang bisa langsung disalin. Ia menampilkan git status dan ringkasan diff dalam satu layar agar mengurangi yang terlewat.
Jangan tenang hanya karena build lolos. Tampilan setelah publikasi dan isi terjemahan tetap perlu dilihat dengan mata yang berbeda.

Mengapa cek diletakkan tepat sebelum commit

Waktu paling ampuh untuk mengecek bukan sebelum mulai kerja, bukan juga di tengah-tengah, tapi tepat sebelum commit. Alasannya sederhana: gambaran utuh file yang benar-benar disentuh AI baru pasti pada momen itu.

Sebelum mulai, seberapa pun keras Anda berkata “sentuh bagian ini saja,” AI tetap akan menyentuh hal yang menurutnya “sebaiknya sekalian diperbaiki” di tengah jalan. Kalau dihentikan di tengah, pekerjaannya belum selesai jadi Anda tak tahu apa yang harus dilihat. Semuanya beres, satu langkah sebelum commit, di situlah baru bisa membandingkan “yang diminta” dengan “yang benar-benar berubah.”

Yang paling sering bikin saya celaka adalah bagian yang menyangkut pendapatan. Misalnya link ke halaman produk bergeser satu karakter saja, pembaca yang mengeklik langsung mendarat di “halaman tidak ditemukan.” Sebagus apa pun kualitas tulisannya, kalau link tujuannya mati, peluang penjualan berhenti di situ. Karena itu, saat melihat diff, hal pertama yang saya pastikan adalah apakah link tujuan berubah.

Buat yang belum memantapkan cara dasar memakai Claude Code, baca dulu panduan memulai Claude Code untuk menangkap gambaran besarnya. Makna dari urutan cek ini akan jadi jauh lebih jelas.

Urutan cek yang selesai dalam 3 menit

Kalau tak bisa dilakukan tiap hari, percuma. Karena itu langkahnya saya batasi jadi empat. Ini bukan audit sempurna, tapi pengaman ringan.

Ucapkan scope-nya. Tugas kali ini sebenarnya apa? Ucapkan ulang dalam satu kalimat. Misalnya “memperbaiki teks tombol di artikel.” Kalimat ini jadi tolok ukur untuk semua keputusan berikutnya.
Lihat daftar file yang berubah. Dengan git status, periksa wajah-wajah file yang berubah. Kalau ada file yang keluar dari scope satu kalimat tadi, beri tanda seakan menempelkan sticky note di sana.
Baca diff file yang ditandai. Lihat isi dari file di luar scope saja. Kalau itu perubahan baik, simpan; kalau tak relevan, keluarkan dari commit kali ini. Putuskan satu per satu.
Staging hanya file yang dibutuhkan. Jangan masukkan semua dengan git add .. Tambahkan dengan menyebut nama hanya file yang dibutuhkan untuk tugas kali ini.

Kuncinya ada di langkah ketiga. Jangan jadikan perubahan yang diperluas AI sebagai pilihan dua arah: “terima semua” atau “tolak semua.” Putuskan satu per satu, mana yang disimpan dan mana yang dikeluarkan, oleh manusia. Kelihatannya sepele, tapi kalau langkah ini dilewat, terjadilah insiden 18 file di pembuka tadi.

Yang diserahkan ke AI dan yang diputuskan manusia

Kalau garis ini dibiarkan kabur, ceknya jadi sekadar formalitas. Saya membaginya seperti ini.

Pekerjaan	Penanggung jawab	Alasan
Mengeksekusi perbaikan teks atau kode	AI	Jumlahnya banyak dan bisa dikerjakan mekanis
Memperbaiki error sintaks dan kesalahan jelas	AI	Aturannya jelas dan mudah diotomasi
Memutuskan apakah perubahan masuk commit ini	Manusia	Hanya manusia yang tahu maksud permintaan
Mengecek link tujuan dan tampilan setelah publikasi	Manusia	Build lolos pun isi tak dijamin benar
Operasi hapus, data produksi, dan tagihan	Manusia	Insiden tak bisa dibatalkan wajib disetujui manusia

Kalau “memutuskan apakah masuk” pun diserahkan ke AI, AI akan menganggap wajar memasukkan semua yang ia perbaiki sendiri. Pegang keputusan itu di tangan Anda. Inilah inti paling penting untuk mengurangi insiden.

Template prompt siap salin

Saat meminta AI membantu mengecek, triknya adalah jangan biarkan AI “menilai dirinya sendiri”, tapi suruh ia “menderetkan fakta.” Template berikut bisa langsung Anda tempel.

Saya akan commit sekarang. Sebelum final, laporkan hal berikut sebagai fakta saja. Keputusan ada di tangan saya.

1. Ringkas permintaan kali ini dalam satu kalimat
2. Daftar file yang berubah dari git status (termasuk yang untracked)
3. Dari daftar itu, file yang sepertinya keluar dari satu kalimat permintaan, beserta alasannya
4. Kalau ada perubahan yang berpotensi memengaruhi link atau tampilan setelah publikasi, tunjukkan bagiannya

Jangan tulis "tidak ada masalah." Cukup deretkan bahan untuk pengambilan keputusan.

Kalimat terakhir itu yang ampuh. Tanpa itu, AI akan merangkum dengan nyaman “tidak ada masalah, aman untuk di-commit,” dan makna pengecekan pun lenyap. Cara menyusun prompt secara detail saya rangkum di prompt engineering tingkat lanjut.

Skrip cek yang langsung jalan

Mengetik git status dan git diff bergantian setiap kali itu merepotkan, jadi saya sediakan skrip untuk menampilkan gambaran utuh perubahan dalam satu layar. Saya siapkan versi PowerShell dan bash. Isinya hanya menderetkan “daftar file yang berubah” dan “jumlah baris tambah/hapus per file.”

Versi PowerShell (Windows).

# precommit-check.ps1
# Sebelum commit, cek file yang berubah dan jumlah perubahan dalam satu layar

Write-Host "=== File yang disentuh kali ini ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== Jumlah perubahan per file (tambah / hapus) ===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== Checklist cek ===" -ForegroundColor Yellow
@(
  "Bisa menyebut permintaan dalam satu kalimat",
  "Tidak ada file di luar scope yang tercampur",
  "Sudah melihat link tujuan dan tampilan setelah publikasi",
  "Staging hanya file yang dibutuhkan kali ini"
) | ForEach-Object { Write-Host "  [ ] $_" }

Versi bash (macOS / Linux / Git Bash).

#!/usr/bin/env bash
# precommit-check.sh
# Sebelum commit, cek file yang berubah dan jumlah perubahan dalam satu layar

echo "=== File yang disentuh kali ini ==="
git status --short

echo ""
echo "=== Jumlah perubahan per file (tambah / hapus) ==="
git diff --stat HEAD

echo ""
echo "=== Checklist cek ==="
for item in \
  "Bisa menyebut permintaan dalam satu kalimat" \
  "Tidak ada file di luar scope yang tercampur" \
  "Sudah melihat link tujuan dan tampilan setelah publikasi" \
  "Staging hanya file yang dibutuhkan kali ini"; do
  echo "  [ ] $item"
done

Menjalankannya cukup begini.

bash precommit-check.sh

Skrip ini tidak memutuskan apa pun secara otomatis. Supaya prinsip “keputusan dilakukan manusia” tidak runtuh, saya sengaja membuatnya “hanya menderetkan dan menampilkan.” Begitu keempat item checklist terisi, tambahkan hanya file yang dibutuhkan dengan git add nama_file lalu commit.

Tiga situasi yang terasa di kerja nyata

1. Sebelum publikasi artikel atau materi. Saat memublikasikan artikel multibahasa sekaligus, kadang file terjemahan masih tertinggal dalam bahasa Inggris. Build lolos, tapi isinya belum diterjemahkan. Jangan puas hanya melihat nama file di diff; pastikan sampai bahasa isi tubuh di halaman setelah publikasi.

2. Menulis ulang file yang sudah ada. Maksudnya cuma memperbaiki kalimat, tapi link di dalam halaman atau nama produk ikut berubah. Kalau scope sudah ditetapkan dengan satu kalimat “perbaikan kalimat”, perubahan link bisa diperlakukan sebagai di luar scope dan kita berhenti sejenak.

3. Saat menerapkan ke tim. Catat sampai mana Claude Code maju otomatis dan di mana ia bertanya ke manusia. Kalau aturan persetujuan (operasi yang boleh otomatis, operasi yang wajib bertanya) dibiarkan kabur, cara insiden terjadi berbeda-beda tiap anggota dan akhirnya tak terkendali.

Jebakan umum dan cara memperbaikinya

Jebakan 1: memasukkan semua dengan git add .. Perubahan dari pekerjaan lain yang belum disimpan ikut terbawa. Perbaikannya sederhana: jadikan kebiasaan untuk tidak memakai . dan staging dengan menyebut nama file. Sekalipun terasa repot, ini asuransi yang paling cepat.

Jebakan 2: tenang karena build lolos. Build hanya melihat sintaks; ia tak melihat apakah link tujuan benar atau apakah terjemahan sudah diterjemahkan sampai isinya. Perbaikannya: buka halaman setelah publikasi secara nyata, dan periksa dengan mata judul, isi tubuh, dan link tujuan. Lulus versi mesin dan lulus versi manusia itu dua hal berbeda.

Jebakan 3: bertanya “tidak ada masalah?” ke AI lalu selesai. AI cenderung menjawab “aman” kalau diminta. Perbaikannya: seperti template prompt tadi, instruksikan “jangan tulis penilaian, deretkan fakta saja.” Begitu subjek keputusan dikembalikan ke manusia, ceknya mulai berfungsi.

Kiat menjadikan kebiasaan cek ini melekat juga saya rangkum di tips meningkatkan produktivitas Claude Code. Perilaku resmi --stat di git bisa diperiksa di dokumentasi resmi Git.

Pertanyaan umum

T. Saya tak punya waktu 3 menit untuk cek setiap kali. J. Pada hari dengan perubahan kecil, selesai dalam 1 menit. Yang butuh 3 menit adalah hari dengan banyak file di luar scope, dan itu justru hari yang memang perlu dicek. Anggap lama waktunya sebagai barometer tingkat bahaya.

T. Bolehkah staging diserahkan ke AI sekalian? J. Untuk pekerjaan kecil yang sudah jelas aman, boleh saja. Tapi keputusan akhir “file mana yang dimasukkan” sebaiknya tetap di tangan manusia. Di sinilah pintu masuk insiden paling sering terbuka.

T. Apa yang sebaiknya ditulis di pesan commit? J. Dua hal: “apa yang diubah” dan “dengan apa diverifikasi.” Misalnya “Perbaiki teks tombol, verifikasi link tujuan di halaman setelah publikasi.” Saat dilihat kemudian, jelas dalam sekejap apakah sudah diverifikasi atau belum.

T. Bagaimana kalau file di luar scope ternyata perubahan yang sebaiknya tetap dilakukan? J. Tetap keluarkan untuk kali ini. Cukup pisahkan ke commit lain, bukan dihapus. Menjaga prinsip satu commit satu maksud bikin lebih mudah ditelusuri kemudian.

Hasil yang saya coba sendiri

Setelah insiden 18 file di pembuka, saya menyisipkan keempat langkah ini sebelum setiap commit. Yang saya coba ada tiga pola: publikasi artikel, menulis ulang file, dan mengubah konfigurasi.

Yang paling ampuh adalah langkah pertama, “ucapkan ulang permintaan dalam satu kalimat.” Cukup mengucapkannya, file di luar scope langsung melompat ke pandangan. Setelah saya menjalankan skrip cek dan berhenti mengetik git add ., lalu beralih ke staging dengan menyebut nama file, insiden terbawanya pekerjaan lain jadi nol.

Dan yang mengejutkan adalah efek mengganti cara bertanya ke AI dari “tidak ada masalah?” menjadi “deretkan fakta saja.” AI yang sama mendadak jadi partner cek yang berguna. Daripada mencari AI yang lebih pintar, kembalikan subjek keputusan ke manusia. Inilah, bagi saya, satu langkah yang paling sederhana sekaligus paling ampuh.

Kalau Anda ingin menurunkan desain izin dan pengecekan pra-publikasi ini ke level operasi seluruh tim, di pelatihan dan konsultasi kita susun desain konkretnya bersama. Untuk membandingkan materi belajar yang siap dipakai sendiri, lihat juga daftar produk.