Ubah catatan Obsidian jadi prompt yang bisa dikerjakan Claude Code hari ini

Jumat malam, saya menulis satu catatan di Obsidian: “Ajakan ke halaman daftar terasa lemah. Kelihatannya banyak orang harus scroll dulu baru sadar ada link PDF gratis.” Senin pagi, catatan itu saya tempel utuh ke Claude Code lalu saya minta, “Tolong perbaiki ini.” Yang kembali adalah dua layar penuh berisi “rangkuman situasi”. Tidak ada satu baris kode pun.

Catatannya sebenarnya tidak jelek. Masalahnya saya menyerahkan catatan itu apa adanya. Hari itu saya membuang 30 menit hanya untuk dijelaskan ulang latar belakang yang saya sendiri yang menulis.

Pengetahuan menumpuk di Obsidian, tapi setiap kali saya tetap menulis pengantar yang sama ke Claude Code. Kalau ini terdengar familier, yang kurang bukan AI yang lebih pintar, melainkan satu pola untuk memangkas catatan menjadi sebuah “prompt tugas”.

Poin penting

• Menempel catatan Obsidian apa adanya membuat Claude Code jadi tukang rangkum, dan implementasi tertunda. Yang dikirim bukan teks penuh, tapi satu tugas yang selesai hari ini.
• Dari catatan, cukup ambil enam hal: tujuan, area terlarang, langkah pertama, cara verifikasi, jalur arah, dan cara mundur.
• Menulis “area yang dibaca” dan “area terlarang” lebih dulu menghapus kecelakaan di mana perubahan merembet ke pembayaran atau autentikasi.
• Simpan prompt sebagai template di Obsidian, supaya lain kali tidak perlu menulis ulang dari nol.
• Jangan percaya laporan “selesai” begitu saja. Nilai dari bukti seperti tangkapan layar dan hasil build.

Kenapa catatan tidak boleh dikirim seluruhnya

Catatan Obsidian itu seperti surat untuk diri sendiri di masa depan. Konteks dan keraguan ditulis semua di sana. Justru karena itu, saat diserahkan ke AI, ia berusaha “membaca semua dan memahami semuanya”.

Kalau rekan kerja manusia, ia membaca catatan panjang lalu memangkasnya sendiri menjadi “intinya posisi link ajakan, kan?”. Claude Code tidak seperhatian itu. Sebanding dengan jumlah teks yang Anda kirim, ia mengembalikan rangkuman yang rapi. Niatnya baik, tapi yang kita mau bukan rangkuman.

Jadi sebelum mengirim, manusia yang memangkas. Dari catatan 1000 karakter, sisakan 30 karakter yang benar-benar dibutuhkan untuk implementasi. Pekerjaan memangkas inilah jalan tercepat untuk menghapus pengantar yang berulang.

Buat yang ingin menyerahkan perapian catatan itu sendiri ke Claude Code, baca dulu dasar integrasi dengan Obsidian supaya langkah di artikel ini terasa nyambung.

Enam hal yang diambil dari catatan

Yang selalu saya ambil dari catatan hanya enam hal berikut. Tidak masalah kalau keenamnya belum lengkap di catatan. Kolom yang kosong saya isi sendiri sambil memangkas.

Hal	Isinya	Contoh
Tujuan	Hasil yang didapat pengguna dalam satu kalimat	Pengunjung sadar ada link PDF gratis sebelum scroll
Area terlarang	Tempat yang tidak boleh rusak	Proses pembayaran, login, tampilan mobile
Langkah pertama	Dari mana mulai dikerjakan	Tambah satu bagian di layar paling atas
Cara verifikasi	Bukti untuk menyatakan selesai	Build lulus, diff perubahan, tampilan URL publik
Jalur arah	Pembaca diarahkan ke mana berikutnya	Halaman pendaftaran PDF gratis
Cara mundur	Jalan pulang kalau gagal	Cukup batalkan commit ini

Intinya ada di “area terlarang”. Kalau kolom ini dibiarkan kosong, bisa-bisa saat memperbaiki link ajakan, ia juga “sekalian merapikan” kode di sekitar pembayaran. Menggambar zona terlarang lebih dulu adalah yang paling ampuh.

Yang diserahkan ke AI, dan yang diputuskan manusia

Kalau dua hal ini tercampur, terjadi kecelakaan. Mari tegaskan garisnya.

• Manusia yang memutuskan: tujuan, area terlarang, cara mundur. Ini keputusan bisnis, jadi jangan dilempar bulat-bulat ke AI.
• Diserahkan ke AI: merinci langkah pertama, menulis kode, menjalankan perintah verifikasi.
• Manusia yang mengecek terakhir: tampilan URL publik, dan apakah diff sesuai dugaan. Bagian ini dipastikan dengan mata.

Yang boleh diserahkan adalah “bagaimana membangun”, bukan “apa yang harus dijaga”. Yang menentukan apa yang dijaga selalu pihak manusia.

Template prompt untuk mengubah catatan jadi tugas

Enam hal yang sudah diambil kita susun menjadi bentuk yang bisa langsung dikirim ke Claude Code. Salin template di bawah, lalu cukup tempel catatan Anda di bagian akhir.

Ubah catatan Obsidian berikut menjadi satu prompt tugas yang bisa kamu implementasikan hari ini.
Pisahkan output ke dalam enam judul di bawah. Jangan tulis kode dulu.

- Tujuan (hasil yang didapat pengguna dalam satu kalimat)
- Area terlarang (tempat yang tidak boleh diubah)
- Langkah pertama (satu perubahan terkecil)
- Cara verifikasi (build, diff, URL publik, dll.)
- Jalur arah (ke mana pembaca diarahkan berikutnya)
- Cara mundur (langkah mengembalikan ke semula kalau gagal)

[Catatan]
(tempel catatan Obsidian di sini)

Yang penting adalah kalimat terakhir, “Jangan tulis kode dulu”. Tanpa ini, Claude Code akan mencoba mengubah dan mengimplementasikan sekaligus, lalu melewati pengecekan area terlarang. Minta ia mengeluarkan prompt tugas dulu, manusia memeriksa zona terlarang, baru kembali dengan “sekarang implementasikan sesuai prompt ini”. Dua tahap ini mengurangi kecelakaan.

Buat yang ingin mempertajam template lebih jauh, saya rangkum trik kalimat detailnya di teknik lanjutan desain prompt Claude Code.

Skrip konversi yang langsung jalan

Kalau menyusun prompt manual setiap kali terasa repot, tulis catatan sebagai objek lalu hasilkan prompt secara otomatis. Asal ada Node.js, ini langsung jalan.

// Skrip minimal untuk mengubah catatan menjadi "prompt tugas yang bisa dikerjakan hari ini"
// Cara pakai: node note-to-issue.mjs

const note = {
  tujuan: "Pengunjung sadar ada link PDF gratis sebelum scroll",
  areaTerlarang: ["Proses pembayaran", "Login", "Tampilan mobile rusak"],
  langkahPertama: "Tambah satu bagian pengumuman di layar paling atas",
  caraVerifikasi: ["Build lulus", "Diff perubahan", "Tampilan URL publik"],
  jalurArah: "Halaman pendaftaran PDF gratis",
  caraMundur: "Cukup batalkan commit ini untuk kembali",
};

function toIssuePrompt(n) {
  // Kalau ada hal wajib yang hilang, biar ketahuan sebelum prompt dikeluarkan
  const required = ["tujuan", "areaTerlarang", "langkahPertama", "caraVerifikasi"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`Hal yang dibutuhkan prompt tugas masih kurang: ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label}: ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("Tujuan", n.tujuan),
    line("Area terlarang", n.areaTerlarang),
    line("Langkah pertama", n.langkahPertama),
    line("Cara verifikasi", n.caraVerifikasi),
    line("Jalur arah", n.jalurArah),
    line("Cara mundur", n.caraMundur),
    "Jangan tulis kode dulu, kembalikan hanya rencana implementasi terkecil dalam cakupan ini.",
  ].join("\n");
}

console.log(toIssuePrompt(note));

Saat dijalankan, keluar prompt berisi enam baris plus satu kalimat penutup. Coba kosongkan areaTerlarang jadi array kosong lalu jalankan lagi, ia akan berhenti dengan “hal masih kurang” sebelum prompt keluar. Ini mekanisme yang menjegal kecelakaan mengirim kolom kosong dari sisi kode.

Tiga situasi nyata di mana ini berguna

1. Catatan perbaikan link ajakan Catatan “link PDF gratis terasa lemah” kalau ditempel apa adanya akan berlanjut jadi penjelasan ide perbaikan tanpa henti. Setelah dipangkas jadi prompt tugas, langkah pertama mengerucut ke satu titik “tambah satu bagian di layar pertama”, dan area pembayaran tidak disentuh. Bandingkan tampilan sebelum dan sesudah lewat URL publik, supaya efeknya dinilai dengan mata, bukan dengan perasaan.

2. Catatan investigasi bug Catatan “kadang layar jadi putih setelah login” punya terlalu banyak informasi. Di prompt tugas, persempit langkah pertama menjadi “bagikan dulu kondisi reproduksi dan log error saja”. Jangan suruh ia mencari penyebab dan memperbaiki sekaligus; fokuskan dulu ke reproduksi, supaya terhindar dari perbaikan yang salah sasaran.

3. Catatan rencana artikel Catatan kabur seperti “artikel berikutnya, mau pasang internal link yang benar” pun bisa jadi dikerjakan kalau tujuan-nya dipangkas menjadi “kunci dua internal link ke artikel terkait”. Set cara verifikasi ke “build lulus”, supaya link mati bisa dihentikan sebelum publish. Sebelum menyerahkan pekerjaan seputar artikel, sebaiknya pemanasan dulu lewat pengantar Claude Code untuk non-engineer.

Menyimpan prompt sebagai template

Prompt yang sudah jadi jangan dipakai sekali buang, tapi kembalikan ke Obsidian. Saat catatan serupa datang lagi, enam judulnya bisa dipakai ulang.

Saya membuat satu nota bernama templates/issue-prompt.md yang berisi template kosong enam judul. Begitu catatan baru datang, tinggal salin template itu lalu isi. Waktu menulis pengantar berulang pun lenyap.

Lebih jauh lagi, kalau aturan yang harus dibaca Claude Code dipasang tetap di proyek, promptnya jadi lebih pendek. Letakkan kesepakatan bersama proyek di cara menulis CLAUDE.md, supaya tidak perlu mengulangnya tiap kali di sisi prompt.

Jebakan yang sering bikin tersandung dan cara memperbaikinya

Berikut kesalahan yang saya lakukan di awal, lengkap dengan cara memperbaikinya.

• Menempel catatan utuh: Claude Code jadi tukang rangkum. Perbaikannya, pangkas jadi enam hal sebelum menempel. Catatan yang tak bisa dipangkas adalah bukti tugasnya belum matang sebagai permintaan, jadi tulis dulu satu kalimat kesimpulan sendiri.
• Tidak menulis area terlarang: perubahan merembet ke pembayaran atau autentikasi. Perbaikannya, jangan biarkan kosong, dan jangan tulis “tidak ada”. Biasakan menyebut minimal satu zona terlarang.
• Cara verifikasi cuma “asal jalan”: Anda terpaksa hanya percaya laporan selesai. Perbaikannya, wajib tentukan minimal satu dari hasil build, diff, atau URL publik.
• Menyuruh implementasi sekaligus: konversi dan implementasi tercampur, pengecekan zona terlarang terlewat. Perbaikannya, selalu sisipkan “jangan tulis kode dulu”, periksa prompt tugas, baru minta implementasi.

Semua jebakan ini ternyata “bisa dicegah kalau satu baris diputuskan lebih dulu”.

Pertanyaan umum

T. Catatan saya potongan-potongan, tidak bisa mengisi enam hal. Tidak harus terisi semua. Asal “tujuan” dan “area terlarang” sudah diputuskan, itu sudah jadi prompt tugas. Sisanya masih sempat diisi setelah prompt keluar, sambil melihat usulan Claude Code.

T. Apakah perlu integrasi yang membuat Claude Code membaca catatan Obsidian langsung? Di awal tidak perlu. Cukup salin catatan secara manual dan tempel ke template, itu sudah berfungsi. Pertimbangkan integrasi otomatis setelah Anda mengulang pekerjaan yang sama berkali-kali; tidak terlambat.

T. Sudah saya tulis “jangan tulis kode dulu”, tapi ia tetap mulai implementasi. Lebih stabil kalau Anda mencantumkan di CLAUDE.md proyek bahwa “saat mengonversi prompt tugas, jangan tulis kode”. Aturan bersama proyek lebih mungkin dipatuhi daripada satu instruksi prompt sekali.

T. Seberapa panjang prompt tugas yang ideal? Saya pakai patokan enam judul, total sekitar 10 baris. Kalau lebih panjang dari itu, itu tanda satu tugas mencampur beberapa tujuan. Pecah tugasnya.

T. Saya tidak tahu apa yang harus diisi di cara verifikasi. Kalau ragu, mulai dengan dua hal: “build lulus” dan “tampilan URL publik”. Dua ini saja sudah cukup untuk keluar dari kondisi menelan mentah laporan selesai.

Hasil setelah saya coba sungguhan

Catatan link ajakan di awal tadi saya pangkas dulu dengan template enam hal ini, lalu saya serahkan lagi ke Claude Code. Kali ini tidak ada rangkuman; yang keluar pertama justru rencana implementasi “tambah satu bagian pengumuman di layar pertama”. Proses pembayaran yang saya cantumkan sebagai area terlarang tidak disentuh sama sekali.

Skrip verifikasi pun, saat saya kosongkan areaTerlarang dengan sengaja lalu jalankan, ia berhenti dengan “hal masih kurang” sebelum prompt keluar. Saya berhasil memastikan bahwa kecelakaan paling umum, yaitu mengirim kolom kosong, bisa dicegah sebelum dieksekusi.

Lebih cepat punya satu pola untuk memangkas catatan daripada memeras instruksi cerdas setiap kali. Itu yang saya rasakan sekarang. Buat yang ingin memperluas cara yang sama ke pembuatan artikel tim atau penanganan pertanyaan masuk, di pelatihan dan konsultasi untuk tim Anda bisa menyusun pola ini sesuai operasi nyata. Standar resminya bisa dicek di dokumentasi resmi Anthropic.