Cara Mengubah Catatan Obsidian Jadi Brief untuk Claude Code

Minggu lalu saya meninggalkan catatan sekitar 2000 kata di Obsidian, lalu keesokan harinya saya minta Claude Code: “Tolong perbaiki tombol checkout itu.”

Yang kembali ke saya: bukan cuma perbaikan tombol, tapi juga atur ulang padding header, susun ulang urutan link footer, dan sekalian rapikan aturan penamaan CSS, semua dalam diff tiga file. Tidak ada satu pun yang saya minta. Kenapa bisa begini? Karena saya menempelkan seluruh catatan apa adanya. Bahkan gumaman “ini juga agak mengganjal” dari tiga hari lalu ikut dibaca dengan bobot yang sama seperti instruksi hari ini.

Catatannya sendiri tidak salah. Yang salah adalah saya, yang mengira catatan itu “bisa langsung diserahkan begitu saja”. Note panjang cocok untuk rekam jejak, tapi tidak cocok untuk instruksi kerja. Hari ini saya tulis cara menutup jurang itu, yaitu langkah mengubah catatan Obsidian menjadi brief instruksi yang pendek.

Poin penting

• Kalau Anda menempel catatan panjang utuh, AI tidak bisa membedakan gumaman lama dari instruksi hari ini, lalu melebarkan kerja ke hal yang tidak diminta.
• Yang Anda serahkan cukup empat: “fakta yang sudah pasti”, “keputusan yang sudah dibuat”, “hal yang belum pasti”, dan “langkah berikutnya”. Tambahkan “area yang tidak disentuh” dan “bukti bahwa pekerjaan selesai”.
• Buat syarat selesai sekecil mungkin. Fokus pada satu file, satu layar, satu perintah, dan lihat sampai build serta screenshot sebelum lanjut.
• Template prompt dan kode pendek untuk mengubah catatan jadi brief bisa Anda salin langsung.
• Yang diserahkan ke AI: “menulis, mencari, memperbaiki”. Yang diputuskan manusia: “cakupan, prioritas, boleh publish atau tidak”. Kalau dua hal ini tercampur, terjadi kecelakaan.

Kenapa tempel utuh bikin kerja melebar

Claude Code bergerak cepat. Justru karena itu, kalau informasi awal yang Anda berikan luas, ia akan berlari sekuat tenaga selebar itu juga.

Catatan punya jarak waktu di dalamnya. Fakta hari ini “tombol terlipat jadi dua baris” berdiri sejajar dalam daftar yang sama dengan kesan seminggu lalu “ngomong-ngomong, palet warnanya kayaknya sudah usang”. Manusia memilah berdasarkan tanggal atau konteks, tapi AI yang menerima tempelan tidak tahu mana instruksi yang masih hidup. Akibatnya, dengan niat baik, ia menyentuh semuanya.

Satu hal lagi. Catatan mencampur “keputusan yang sudah dibuat” dengan “hal yang masih ragu”. Kalau bagian keraguan ikut dibaca sebagai instruksi, AI memutuskan sendiri salah satu arah dan jalan terus. Ini yang paling menakutkan. Maka sebelum menyerahkan, manusia perlu memilah satu kali di sisinya.

Yang diserahkan cukup empat

Sumbu pemilahannya sederhana, tinggal masukkan ke empat kotak ini.

1. Fakta: hal yang benar-benar bisa dipastikan. Misalnya “di layar 375px tombol terlipat jadi dua baris”, “URL publik sudah benar” — sesuatu yang siapa pun setuju kalau melihatnya.
2. Keputusan: hal yang sudah diputuskan. Misalnya “PDF gratis ditaruh sebelum materi berbayar” — kebijakan yang sudah dibahas dan tidak diutak-atik lagi.
3. Belum pasti: hal yang masih belum jelas. Misalnya “komponen mana yang memegang spacing tombol belum diketahui” — lubang yang tidak ingin Anda biarkan diisi sendiri oleh AI.
4. Langkah berikutnya: satu hal yang dikerjakan kali ini. Konkret sampai “identifikasi komponennya, terapkan perubahan CSS sekecil mungkin, verifikasi di lebar ponsel”.

Di sini tambahkan dua hal. Area yang tidak disentuh (contoh: file di sekitar autentikasi tidak diutak-atik kali ini), dan bukti bahwa pekerjaan selesai (contoh: build lolos, screenshot di lebar ponsel). Enam butir inilah isi brief.

Saat memilah, yang perlu diingat: jangan hapus “belum pasti”. Kalau Anda jujur menyisakan hal yang belum jelas, AI akan bertanya di situ. Sebaliknya, kalau Anda hapus “belum pasti” dan menuliskannya seolah fakta, AI menerjang terus dengan asumsi yang salah.

Yang diserahkan ke AI dan yang diputuskan manusia

Garis batasnya ditarik di awal. Kalau bagian ini kabur, brief sebagus apa pun akhirnya tetap goyah.

Tahap	Diserahkan ke AI	Diputuskan manusia
Cakupan	-	File/layar mana yang difokuskan
Investigasi	Mencari komponen atau kode	Prioritas apa yang dicari
Implementasi	Menulis perubahan paling kecil	Batas atas perubahan yang boleh
Verifikasi	Menjalankan build dan tes	Keputusan akhir boleh publish atau tidak

Seperti tabel di atas, “mencari, menulis, menjalankan” adalah keahlian AI. Sementara “sampai mana dikerjakan” dan “boleh publish atau tidak” dipegang manusia. Kalau garis ini Anda tulis di brief, walau AI mencoba melebarkan cakupan, ia berhenti sendiri. Dasar cara mendelegasikan ke AI saya jelaskan di claude-code-for-non-engineers.

Template prompt yang bisa disalin

Pertama, pilih catatan apa adanya, lalu tempel di bawah kalimat permintaan ini. Cara pakainya: pekerjaan memilah itu sendiri diserahkan ke AI.

Rapikan catatan Obsidian berikut menjadi brief instruksi pendek untuk Claude Code.
Output hanya boleh berupa heading di bawah ini, sisanya dibuang.

- Fakta: hanya hal yang sudah dipastikan
- Keputusan: kebijakan yang tidak diutak-atik lagi
- Belum pasti: jangan diisi sendiri, biarkan tetap "belum jelas"
- Langkah berikutnya: satu hal yang dikerjakan kali ini, tulis konkret
- Area yang tidak disentuh: file atau fitur yang tidak diutak-atik kali ini
- Bukti: cara verifikasi bahwa pekerjaan selesai (build, screenshot, dll)

Kesan lama atau obrolan ringan dikumpulkan terpisah sebagai "catatan referensi",
jangan dicampur ke instruksi.

Baca ulang brief yang keluar, lalu cek dua hal saja: apakah “belum pasti” berubah jadi “fakta”, dan apakah “langkah berikutnya” sudah menyusut jadi satu. Kalau tidak ada masalah, tempel brief itu langsung ke CLAUDE.md atau komentar issue, lalu minta implementasi. Cara menulis CLAUDE.md saya rangkum lengkap di claude-md-best-practices.

Kode verifikasi untuk mengubah catatan jadi brief

Sebelum kerja manual, saya taruh kode kecil supaya strukturnya masuk ke tubuh. Jalan di Node.js. Tugasnya cuma memegang catatan terbagi ke enam butir di atas, lalu menyusunnya jadi satu lembar brief untuk diserahkan ke Claude Code.

// Pegang catatan terbagi jadi "fakta, keputusan, belum pasti, langkah berikutnya"
const note = {
  title: "Tombol checkout terlipat di ponsel",
  facts: ["di layar 375px tombol terlipat jadi dua baris", "URL publik sudah benar"],
  decision: "PDF gratis ditaruh sebelum materi berbayar",
  unknowns: ["komponen mana yang memegang spacing tombol belum diketahui"],
  nextAction: "identifikasi komponen, terapkan perubahan CSS terkecil, verifikasi di lebar ponsel",
  doNotTouch: ["file di sekitar autentikasi"],
  proof: ["build lolos", "screenshot lebar 375px"],
};

// Susun enam butir jadi satu lembar teks brief
function toBrief(item) {
  return [
    `Tujuan: ${item.nextAction}`,
    `Fakta: ${item.facts.join(" / ")}`,
    `Keputusan: ${item.decision}`,
    `Belum pasti (jangan diisi sendiri): ${item.unknowns.join(" / ")}`,
    `Area yang tidak disentuh: ${item.doNotTouch.join(" / ")}`,
    `Bukti: ${item.proof.join(" / ")}`,
  ].join("\n");
}

// Penjaga gerbang yang mengecek pemilahan secara mekanis
function checkBrief(item) {
  const missing = [];
  if (item.facts.length === 0) missing.push("fakta");
  if (item.unknowns.length === 0) missing.push("belum pasti");
  if (!item.nextAction) missing.push("langkah berikutnya");
  if (missing.length) {
    throw new Error(`Pemilahan belum lengkap: ${missing.join(", ")}`);
  }
  return true;
}

checkBrief(note);
console.log(toBrief(note));

checkBrief terlihat sepele tapi inilah intinya. Kalau Anda coba mengeluarkan brief dengan fakta kosong, “belum pasti” kosong, atau “langkah berikutnya” kosong, ia berhenti di sini. Dengan melarang “tempel saja dulu” sejak tahap kode, kecelakaan catatan asal-asalan yang langsung mengalir ke AI jadi berkurang. Tempel saja hasil output ke komentar issue atau catatan serah-terima, supaya keputusan yang sama bisa dipakai lagi di pekerjaan berikutnya. Cara membuat catatan serah-terima bisa Anda contoh dari claude-code-session-handoff-template.

Situasi di mana ini ampuh

1. Saat minta perbaikan artikel

Kalau Anda lempar “tolong perbaiki artikel ini” begitu saja, AI cenderung menulis ulang seluruh badan teks. Maka di brief tulis “hanya serahkan search intent dan kebijakan CTA”, “dilarang menulis ulang seluruh badan”. Fakta = heading sekarang, keputusan = arah jalur konversi, belum pasti = paragraf yang lemah, langkah berikutnya = perbaiki satu heading saja. Diff jadi kecil, dan mengembalikannya pun sekejap. Setup integrasi Obsidian-nya sendiri saya rangkum di claude-code-obsidian-integration.

2. Saat memperbaiki bug

Kuncinya: pisahkan fakta yang sudah bisa direproduksi dari penyebab yang masih belum jelas. “Di 375px tombol terlipat” itu fakta, “komponen mana yang punya spacing” itu belum pasti. Kalau dua ini tercampur lalu Anda tulis “penyebabnya pasti CSS”, AI mulai memperbaiki dengan dugaan yang salah. Kalau “belum pasti” diserahkan apa adanya, AI justru menyelidiki bagian itu lebih dulu.

3. Saat menerima konsultasi adopsi

Catatan kerja klien jangan ditunjukkan utuh; bagi jadi “area yang disentuh kali ini”, “area yang mutlak tidak disentuh”, “yang dicek lain kali”. Jangan biarkan data produksi atau bagian billing disentuh otomatis selagi masih “belum pasti”. Cukup tulis garis batas ini di brief, dan Anda bisa berbagi layar dengan tenang saat sesi konsultasi.

Kesalahan yang sering terjadi dan cara membenahinya

Kesalahan yang saya buat di awal kira-kira mengerucut jadi tiga ini.

Yang pertama, menempel seluruh vault. Keputusan lama dan batasan sekarang tercampur, lalu AI bingung harus percaya yang mana. Cara membenahinya sederhana: cukup pilah ke enam butir di atas sebelum menempel. Kesan tiga hari lalu diisolasi ke “catatan referensi”.

Yang kedua, menyerahkan keputusan saja. Saya cuma menulis “PDF ditaruh di depan”, AI tidak tahu kenapa begitu, lalu di situasi lain melakukan kebalikannya. Kalau fakta dan alasan disisakan sepaket, ia bisa menerapkannya ke kasus lain.

Yang ketiga, membuat syarat selesai terlalu besar. Kalau Anda minta “rapikan secara menyeluruh”, AI dengan baik hati melebarkan cakupan. Fokus ke satu file, satu layar, satu perintah, dan lihat build serta screenshot sebelum lanjut. Hanya dengan ini, kecepatan tetap terjaga sementara waktu untuk mengembalikan berkurang. Cara menyusutkan prompt bisa Anda baca juga di claude-code-prompt-engineering-advanced.

Pertanyaan umum

T. Bukankah bikin brief lebih repot daripada menempel seluruh catatan? Beberapa kali pertama memang terasa begitu. Tapi waktu untuk membaca ulang diff yang melebar karena dilempar mentah lalu mengembalikannya, dalam jangka panjang justru lebih berat. Memilah, kalau sudah terbiasa, selesai dalam satu menit.

T. Boleh memilahnya juga diserahkan ke AI? Boleh. Template prompt di atas justru cara pakai seperti itu. Tapi brief yang keluar tetap dibaca sekali oleh manusia, dan cek apakah “belum pasti” berubah jadi “fakta”.

T. Apa bedanya CLAUDE.md dengan brief? CLAUDE.md adalah tempat aturan yang tidak berubah untuk seluruh proyek, brief adalah permintaan untuk satu kali pekerjaan ini. Kalau “keputusan” di brief muncul berulang kali, itu sinyal untuk menaikkannya ke CLAUDE.md.

T. Apa bisa dipakai kalau bukan Obsidian? Bisa. Notion atau catatan teks biasa pun tidak masalah. Yang penting bukan tool-nya, tapi cara berpikir membaginya jadi fakta, keputusan, belum pasti, dan langkah berikutnya.

T. Sampai mana diserahkan ke AI, dari mana manusia yang memutuskan? “Mencari, menulis, menjalankan” aman diserahkan. “Sampai mana cakupan dilebarkan” dan “boleh publish atau tidak” dipegang manusia. Kuncinya menuliskan garis ini di dalam brief.

Hasil setelah saya coba sendiri

Sesudah “kecelakaan tiga file yang tidak diminta” di pembuka, saya selalu memilah ke enam butir sebelum menempel catatan.

Saya benar-benar mencoba lagi perbaikan tombol checkout yang sama, kali ini diserahkan dalam bentuk brief. Diff-nya satu file, hanya beberapa baris CSS. Header maupun footer, semua yang tidak diminta, sama sekali tidak disentuh. checkBrief sempat menghentikan saya sekali karena “belum pasti” masih kosong; setelah saya tambahkan “komponen mana yang memegang spacing” baru saya serahkan — dan itu terasa membantu, karena AI lebih dulu mencari komponen itu.

Yang saya pastikan ada dua. Pertama, “kalau ‘belum pasti’ disisakan, AI tidak mengisi sendiri tapi justru menyelidikinya”. Kedua, “kalau langkah berikutnya disusutkan jadi satu, diff kecil dan mudah dikembalikan”. Daripada mencari prompt yang pintar, satu menit memilah sebelum menyerahkan ternyata yang paling cepat — itu kesan saya sekarang.

Kalau Anda sudah terbiasa memilah catatan dan ingin memutar pola yang sama untuk seluruh tim, saya juga menyiapkan training dan konsultasi untuk merancang langkahnya bersama.

Prasyarat resminya bisa Anda cek di Anthropic Claude Code getting started.