Checklist verifikasi Claude Code: simpan bukti, bukan kata 'selesai'

Jumat malam, saya minta Claude Code “tulis satu artikel sampai terbit, beres ya” lalu tidur. Pagi harinya saya baca log: “Selesai. Artikel sudah dipublikasikan.” Penuh percaya diri. Saya buka URL publiknya dengan tenang, dan yang muncul justru judul artikel yang lama.

Build-nya lolos. URL juga balas 200. Tapi tag h1 masih milik halaman lain. Saya menyerahkan pengecekan diff sepenuhnya ke AI, dan saya cuma percaya pada satu kata: “jalan”.

Saat itu saya sadar, yang bikin tersandung bukan kepintaran Claude Code, tapi cara saya “menutup pekerjaan”. Makin luas yang saya serahkan ke AI, makin penting menyimpan sendiri jawaban atas pertanyaan “sebenarnya apa yang sudah terbukti?” setelah selesai. Tanpa itu, saya akan kena laporan “selesai” palsu setiap kali.

Di artikel ini saya bagikan “pola menyimpan bukti” itu, lengkap dengan kode yang bisa langsung disalin.

Poin penting

• Jangan percaya kata “selesai” dari AI. Jadikan dasar penyelesaian hanya bukti yang sudah dicek mesin: build, URL publik, h1, dan CTA.
• Sebelum mulai mengedit, tetapkan dalam satu kalimat “apa yang mau dibuktikan run ini”, dan tentukan dulu command verifikasinya.
• Setelah terbit, periksa mata selalu dengan urutan yang sama (h1 -> canonical -> awal isi -> CTA). Urutan tetap mengurangi kelalaian.
• Tinggalkan bukti (screenshot, URL, angka berikutnya) dalam satu baris catatan. Besok, kamu atau automasi tidak perlu mengulang keputusan yang sama.
• Daripada menerbitkan artikel sempurna sekali jadi, secara operasional lebih kuat menerbitkan artikel yang bisa diverifikasi besok.

Kenapa kata “selesai” saja bisa bikin celaka

Claude Code merangkum proses kerjanya dalam kalimat. Inilah masalahnya: rangkuman saat benar-benar berhasil dan saat gagal kira-kira datang dengan wajah yang sama.

“Build lolos” hanya bukti bahwa “sintaks tidak rusak”. “URL publik balas 200” hanya bukti bahwa “server mengembalikan sesuatu”. Apakah sesuatu itu adalah artikel yang harusnya kamu buat kali ini, itu cerita lain.

Celaka saya di hari Jumat juga lolos build dan 200, dua-duanya. Yang hancur cuma satu titik: apakah isi halaman cocok dengan URL-nya. Tidak ada yang melihat titik itu.

Karena itu keputusan “selesai” diletakkan pada hasil menumpas satu per satu item cek yang kamu tentukan sendiri, bukan pada kata-kata AI. Kalau pondasi cara verifikasimu masih ragu, samakan dulu alur dasarnya di cara memulai Claude Code, supaya langkah di artikel ini lebih mudah masuk.

Loop verifikasi 15 menit

Kalau setiap kali mengecek pakai langkah yang berbeda-beda, di hari sibuk pasti ada yang terlewat. Tetapkan urutan, jadikan bentuk yang bisa diputar tanpa banyak berpikir.

1. Tulis dalam satu kalimat “apa yang harus terbukti supaya run ini selesai”. Contoh: “Artikel dengan slug ini muncul di URL publik dengan h1 yang benar.”
2. Sebelum mulai mengedit, tentukan command yang dipakai untuk verifikasi (build atau tampilan diff). Jangan dicari setelah selesai.
3. Setelah mengubah, lihat dengan urutan diff -> build -> URL publik. Walau pikiran berubah di tengah jalan, jangan rusak urutan ini.
4. Di URL publik, periksa dengan mata apakah h1, canonical, awal isi, dan CTA tersusun sesuai yang diharapkan.
5. Tinggalkan risiko yang tersisa dan “langkah terkecil berikutnya” dalam satu baris catatan saja.

Yang penting di sini adalah memisahkan dulu di awal: mana yang boleh diserahkan ke AI, dan mana yang diputuskan manusia.

Tahap	Boleh diserahkan ke AI	Diputuskan manusia
Pilih topik	Baca judul yang ada, ajukan kandidat	Akhirnya menulis yang mana
Menulis	Draf isi, kode, dan heading	Apakah tercampur info bohong atau usang
Verifikasi	Menjalankan build, merangkum diff	Cek akhir apakah isi URL publik benar
Publikasi	Menjalankan command publikasi	Persetujuan aksi tak bisa dibalik seperti hapus / deploy produksi

Khusus aksi yang tak bisa dibalik, awalnya jatuhkan semuanya ke “tanya manusia”. Aksi yang sudah terbukti aman baru kemudian dinaikkan ke otomatis. Cara menarik garis ini saya rapikan lebih detail di panduan manajemen izin.

Templat kalimat permintaan yang bisa disalin

Kalau verifikasi disusun dari nol setiap kali, hasilnya bergantung mood hari itu dan ada yang bocor. Buat kalimat permintaan ke Claude Code dalam bentuk templat, supaya item cek-nya stabil.

Artikel ini sudah saya publikasikan. Sebelum melapor selesai, cek hal berikut dan balas hasilnya dalam bentuk tabel.
- Apakah build berhasil (tulis juga command dan exit code-nya)
- Apakah h1 di URL publik cocok dengan judul artikel slug kali ini
- Apakah canonical menunjuk ke slug yang sama
- Apakah awal isi bukan daur ulang dari artikel sebelumnya atau halaman beranda
- Apakah CTA (PDF gratis / produk / konsultasi) tersusun dengan urutan yang sesuai kondisi pembaca
Untuk item yang tidak bisa dicek, tulis jujur "belum dicek". Jangan menulis "OK" berdasarkan tebakan.

Kalimat terakhir itu yang manjur. Tanpa menegaskan “jangan tulis OK berdasarkan tebakan”, AI cenderung membalas “tidak ada masalah” dengan wajah enak bahkan untuk item yang belum ia cek. Kalau ingin mengangkat kualitas cara menyusun kalimat permintaan itu sendiri, baca juga penerapan desain prompt.

Skrip verifikasi yang langsung jalan

Ini inti hari ini. Skrip mengambil URL publik dan menilai secara mesin apakah h1 sesuai judul yang diharapkan. Cukup dengan Node.js (versi 18 ke atas). Bukan kata “selesai” dari AI, melainkan penilaian skrip inilah yang jadi dasar penyelesaian.

// verify-publish.mjs
// Cara pakai: node verify-publish.mjs <URL publik> "<judul h1 yang diharapkan>"
// Contoh: node verify-publish.mjs https://claudecode-lab.com/id/blog/foo/ "Judul artikel"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("Berikan dua argumen: URL dan judul h1 yang diharapkan.");
  process.exit(2);
}

// Ambil halaman publik
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// Ekstrak kasar h1 dan canonical (tidak perlu parser ketat)
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// Tumpas item cek satu per satu
const checks = {
  http200: res.status === 200,
  h1Cocok: h1 === expectedH1,
  canonicalCocok: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("Ada item yang belum dicek atau tidak cocok. Jangan anggap publikasi selesai.");
  console.error(`h1 yang diambil: ${h1 || "(kosong)"}`);
  process.exit(1);
}

console.log("Bukti lengkap. Boleh dianggap selesai.");

Menjalankannya cuma ini.

node verify-publish.mjs https://claudecode-lab.com/id/blog/foo/ "Judul artikel"

Kalau h1Cocok bernilai false, itu persis kondisi celaka saya di hari Jumat. URL hidup tapi isinya beda. Selama exit code bukan 0, publikasi tidak boleh disebut “selesai”. Cukup jadikan ini aturan, dan laporan “selesai” palsu berhenti di depan pagar.

Berguna di situasi seperti ini

1. Pekerjaan menerbitkan artikel Ini situasi yang gampang disangka sukses cuma karena HTTP 200. Dengan skrip di atas, kalau kamu memastikan h1 dan canonical menunjuk slug yang sama, kamu bisa menyaring daur ulang artikel lama atau fallback ke beranda sebelum terbit.

2. Penggantian CTA Setelah memindahkan tombol ke PDF gratis atau materi, simpan screenshot dan “angka yang dilihat berikutnya” di baris catatan yang sama. Nanti kamu bisa menelusuri “apakah perubahan itu menambah pendaftaran” lewat catatan, bukan ingatan.

3. Perubahan setelan atau izin Justru saat mengubah CLAUDE.md atau setelan izin, jalankan command verifikasi yang sama sebelum dan sesudah. Kalau cara menulis setelan masih bikin ragu, rapikan dulu cara menulis CLAUDE.md supaya premis verifikasinya seragam.

Jebakan, dan cara membetulkannya

Jujur saja, sebelum mendarat di pola ini saya berkali-kali jatuh di lubang yang sama.

Pertama, mencoba membetulkan semua dalam satu kali kerja, sehingga membuat diff yang terlalu besar untuk dicek. Diff yang menyentuh 40 file tidak bisa dibaca tuntas, baik oleh manusia maupun AI. Cara membetulkannya sederhana: persempit jadi satu kalimat apa yang mau dibuktikan dalam satu kali kerja. Kalau jadi terlalu besar untuk dicek tuntas, pecah pekerjaannya.

Kedua, menganggap selesai begitu build lokal lolos. Jalan di lokal dan tampil benar di URL publik adalah dua hal berbeda. Cara membetulkannya: jalankan skrip di atas satu kali setiap selesai terbit. Sebelum saya memasukkan ini ke prosedur, saya juga berkali-kali menerbitkan isi yang salah.

Ketiga, cuma menambah CTA tanpa menjelaskan pembaca harus melangkah ke mana. Menyusun tiga tombol pun percuma kalau pembaca tidak bisa memilih. Cara membetulkannya: tambahkan satu kalimat di isi tentang CTA mana yang cocok untuk tiap kondisi pembaca (masih ragu mengoperasikan / lelah karena kerja berulang / sedang mempertimbangkan adopsi tim).

Pertanyaan umum

Q. Kalau build lolos, anggap selesai saja, kan? Build cuma bukti sintaks tidak rusak. Apakah isi URL publik adalah artikel kali ini itu masalah lain. Baru disebut selesai setelah h1 dan canonical ikut dicek.

Q. Skrip verifikasinya dijalankan manual tiap kali? Awalnya manual sudah cukup. Begitu prosedur stabil, kembangkan jadi otomatis jalan tepat setelah command publikasi. Kalau exit code bukan 0 maka publikasi dihentikan; operasi seperti ini mengurangi kecelakaan.

Q. Boleh tidak menyerahkan verifikasi juga sepenuhnya ke AI? Pekerjaan membaca dan merangkum boleh diserahkan. Tapi keputusan akhir “apakah isi URL publik benar” dan persetujuan aksi tak bisa dibalik tetap di tangan manusia. Kalau ini diserahkan, tidak ada lagi yang menghentikan laporan “selesai” palsu.

Q. Non-engineer bisa memutar cek ini? Bisa. Skripnya jalan dengan disalin saja, dan prosedur cek mata cuma soal menghafal urutan. Kalau command-nya sendiri bikin ragu, masuk dari penjelasan untuk non-engineer supaya tidak terlalu berat.

Q. Catatan cukup berisi apa? Cukup tiga: “yang dicek kali ini”, “risiko yang tersisa”, “langkah terkecil berikutnya”. Notulen panjang tidak perlu. Tujuannya hanya satu: besok kamu tidak mengulang keputusan yang sama.

Hasil setelah benar-benar dicoba

Setelah insiden menerbitkan isi yang salah di hari Jumat, saya mengganti standar penyelesaian dari “apa kata AI” menjadi “apakah exit code skrip 0”.

Saya benar-benar menjalankan verify-publish.mjs pada sekitar 10 publikasi, dan 2 di antaranya mengembalikan h1Cocok bernilai false. Keduanya balas 200, jenis yang sekilas tidak ketahuan. Tanpa skrip, saya pasti menerbitkan halaman daur ulang lagi.

Mengunci urutan cek mata juga manjur. Setelah saya selalu melihat dengan urutan h1 -> canonical -> awal isi -> CTA, kelalaian “lho, di sini tadi juga kelewat ya” nyaris hilang. Karena keputusan tidak dilakukan di dalam kepala melainkan dikeluarkan ke prosedur, pengecekan malam terasa lebih ringan.

Daripada mencari AI yang lebih pintar, letakkan dulu mekanisme yang bisa menyadari saat tersandung. Terlihat memutar, tapi inilah jalan tercepat, itu kesimpulan saya sekarang.

Kalau kamu sudah di tahap ingin menjadikan pola verifikasi ini standar tim, atau memasukkannya ke alur publikasi perusahaan, mari kita rancang bersama di pelatihan dan konsultasi. Dokumentasi resmi Claude Code bisa kamu cek di dokumentasi Anthropic.