Setiap kali saya buka sesi baru dengan AI untuk proyek yang sama, dia mulai dari nol lagi. Aturan yang kemarin sudah disepakati, gaya penulisan yang sudah dikoreksi tiga kali, kesalahan yang sudah pernah dibahas, semuanya hilang. Saya jelaskan ulang, dia kerjakan, lalu besok saya jelaskan ulang lagi.
Untuk tugas sekali jalan, itu tidak masalah. Untuk proyek yang jalan berminggu-minggu, itu melelahkan dan mahal. Lebih parah lagi, hasilnya jadi tidak konsisten, karena penjelasan saya hari ini tidak pernah sama persis dengan penjelasan saya minggu lalu.
Jalan keluarnya ternyata bukan prompt yang lebih panjang. Yang saya lakukan sekarang: sebelum minta dikerjakan apa pun, saya bangun dulu dokumen aturan timnya, lalu saya pasang ke proyeknya supaya kepanggil sendiri waktu pekerjaannya cocok.
Dua file, dua tugas yang berbeda
Isinya cuma dua file, dan pembagian tugasnya penting.
File persona tim, atau dalam istilah Claude, “sumber kebenaran”. Isinya panjang: proyek ini apa, aturan yang berlaku selalu, daftar kesalahan yang pernah terjadi, siapa saja “anggota tim” yang harus aktif untuk jenis pekerjaan tertentu, dan urutan kerja yang wajib diikuti.
SKILL.md adalah pemicunya. Isinya pendek, cuma beberapa paragraf, dan tugasnya menyuruh AI membaca file persona tadi sampai habis sebelum menyentuh apa pun. File ini yang diletakkan di folder khusus supaya Claude tahu skill ini ada. Yang ikut terbaca di awal sesi cuma nama dan deskripsinya, sedangkan isinya baru masuk waktu skill-nya dipanggil.
Pemisahan ini sengaja. File persona boleh tumbuh sampai ratusan baris tanpa mengganggu apa pun, sementara pemicunya tetap ringan.
Yang bikin file persona ini berguna
Saya sudah beberapa kali bikin file aturan yang ternyata tidak berpengaruh apa-apa. Bedanya ada di empat hal ini.
Aturan yang lahir dari kejadian nyata, bukan dari teori. Aturan seperti “tulis kode yang bersih” tidak mengubah apa pun, karena terlalu umum. Yang berpengaruh itu aturan yang menyebut peristiwanya, misalnya larangan menghapus file sebelum dibuktikan isinya tidak unik, yang saya tulis setelah satu backup benar-benar hilang permanen. Aturan yang membawa ceritanya akan lebih dipatuhi, dan saya juga jadi ingat kenapa aturan itu ada.
Daftar jebakan. Ini bagian favorit saya. Setiap kali ada bug yang sifatnya jebakan, artinya kelihatan benar tapi diam-diam salah, saya catat di situ lengkap dengan gejalanya dan cara mengenalinya. Isinya jadi semacam catatan luka proyek. Di proyek kantor saya, salah satunya soal file Excel dari tim finance yang menyimpan baris total di dalam rentang datanya, sehingga penjumlahan biasa membuat angkanya dobel persis dua kali lipat.
Pembagian persona. Saya pecah jadi beberapa peran, misalnya yang memutuskan sebuah permintaan itu besar atau kecil, yang menulis kodenya, yang menjaga keamanan file, dan yang membedah angka. Gunanya supaya setiap jenis pekerjaan punya daftar periksa sendiri, dan AI harus menyebut peran mana yang sedang dia pakai sebelum mulai.
Workflow wajib. Urutan kerja yang tidak boleh dilewati, termasuk gerbang verifikasi di akhir. Ini yang menahan kebiasaan AI menyatakan pekerjaan selesai padahal baru sampai tahap “berhasil dibangun tanpa error”.
Aturan standing, berlaku selalu Jangan pernah menebak angka ke dalam laporan keuangan. Sel kosong yang jujur mengaku tidak tahu selalu lebih baik daripada angka masuk akal yang ternyata salah, karena angka yang salah akan dipercaya. Kalau data sumber tidak bisa membedakan dua kemungkinan, kosongkan, sebutkan minggu mana yang kosong, dan jelaskan bukti apa yang dibutuhkan supaya bisa terisi. Pemilik proyek bukan programmer. Dia membaca laporan, bukan kode. Penjelasan langsung ke akibatnya dulu, mekanismenya belakangan, dan istilah teknis selalu diberi padanan bahasa sehari-hari. Buktikan dulu sebuah file memang tidak terpakai sebelum menghapusnya. Bandingkan checksum atau isi barisnya dengan file penggantinya, lalu sebutkan apa buktinya. Memindahkan atau mengganti nama lebih disukai daripada menghapus. Aturan ini lahir karena satu backup pernah terhapus permanen dengan alasan "kelihatannya file tes". Cek Excel sebelum menyentuh file .xlsx mana pun. Excel mengunci file dan bisa menyimpan perubahan yang belum tersimpan. Kalau statusnya belum tersimpan, berhenti dan tanya pemilik. Jangan menutup Excel-nya sendiri. Katakan terus terang kalau ada yang salah. Pemilik proyek pernah menemukan sendiri file laporan yang rusak setelah dilaporkan aman. Tampilkan kegagalannya, tunjukkan buktinya, sebutkan penyebabnya. Daftar jebakan, semuanya pernah benar-benar terjadi Jebakan 1: file sumber menyimpan baris total di dalam rentang datanya. Daftar piutang di sheet finance diakhiri satu baris yang isinya jumlah dari kolom di atasnya. Menjumlahkan seluruh rentang begitu saja membuat angkanya dobel persis dua kali lipat. Solusinya bukan mengunci nomor baris, tapi mengenali polanya: baris data biasa hanya mengisi satu kolom, sedangkan baris total mengisi dua kolom sekaligus.
Contoh potongan file persona: aturan standing dan jebakan yang benar-benar pernah terjadi di proyek. Nama proyek dan file di sini fiktif.
Cara memasangnya ke proyek
Di Claude Code, letakkan SKILL.md di dalam folder proyek dengan susunan .claude/skills/nama-skill/SKILL.md. Bagian paling atas file diisi nama dan deskripsi kapan skill ini harus dipakai. Deskripsi ini yang menentukan kapan file tersebut dipanggil, jadi tulis situasinya sekonkret mungkin, bukan sekadar judul.
Isi badan SKILL.md-nya sendiri singkat: perintah membaca file persona sampai habis, urutan langkah yang harus diikuti, dan satu atau dua aturan paling penting yang diulang di situ supaya tetap selamat meskipun semua hal lain terlupa.
--- name: rekap-cashflow-team description: Dipakai saat membangun, merawat, atau memperbaiki aplikasi Rekap Cashflow Mingguan, dan saat membedah laporan mingguannya. Memuat 6 persona, 3 workflow wajib, daftar jebakan, dan aturan keamanan data sebelum satu file atau satu angka pun disentuh. --- Baca seluruh isi file di bawah ini sampai habis sebelum mengerjakan apa pun di proyek Rekap Cashflow, dan ikuti setiap aturannya persis, tanpa kecuali dan tanpa diringkas: E:\Proyek\rekap-cashflow\Documents\rekap-cashflow-team-persona.md File itu adalah satu-satunya sumber kebenaran untuk proyek ini: 6 persona dalam tiga squad, tiga workflow wajib, daftar jebakan yang benar-benar pernah terjadi di proyek ini, aturan keamanan data soal file Excel dan penghapusan file. Setelah membacanya, untuk tugas apa pun yang diminta: 1. Sebutkan squad dan persona mana yang aktif untuk tugas ini. 2. Jalankan workflow yang sesuai dengan jenis permintaannya, dan jangan pernah melewati Workflow C, yaitu gerbang verifikasi. 3. Cek permintaannya terhadap daftar jebakan sebelum menulis kode atau mempercayai sebuah angka. Sebagian besar kesalahan di proyek ini adalah pengulangan jebakan lama. 4. Untuk setiap angka keuangan yang dilaporkan, sebutkan apakah itu terverifikasi, dugaan, atau sengaja dikosongkan. 5. Di akhir jawaban, sebutkan persona dan workflow mana yang benar-benar dipakai. Dua aturan yang harus tetap hidup meski semua hal lain terlupa: kosong lebih baik daripada ditebak untuk angka keuangan, dan buktikan sebuah file memang tidak terpakai sebelum menghapusnya, karena satu penghapusan permanen di proyek ini sudah pernah menelan data asli. Kalau file itu berubah sejak terakhir dibaca, selalu ikuti isi terbarunya, bukan ingatan dari versi sebelumnya. Baca ulang setiap kali skill ini dipanggil.
Contoh isi SKILL.md. Pendek, karena tugasnya cuma menunjuk ke file persona.
Satu kalimat yang menurut saya paling berpengaruh ada di bagian akhir: perintah untuk selalu membaca ulang file persona dari disk setiap kali skill dipanggil, dan mengikuti isi terbarunya, bukan ingatan dari versi sebelumnya. Tanpa kalimat itu, file yang sudah saya perbarui bisa saja dijalankan memakai versi lama.
Kapan file ini harus diperbarui
Bagian ini yang jarang dibahas orang, padahal di sinilah nilainya. File aturan yang dibuat sekali lalu ditinggalkan akan pelan-pelan jadi salah, dan aturan yang salah lebih berbahaya daripada tidak ada aturan.
Saya memperbaruinya setiap kali salah satu dari ini terjadi:
- Muncul bug yang menipu. Masuk ke daftar jebakan, lengkap dengan gejalanya. Tujuannya supaya kesalahan yang sama tidak diulang enam minggu kemudian.
- Saya mengoreksi hasil kerjanya. Kalau saya sampai bilang “jangan begitu”, itu tanda ada aturan yang belum tertulis. Koreksi lisan hilang begitu sesi ditutup, aturan tertulis tidak.
- Alur kerjanya berubah. Misalnya format file dari orang lain berubah, atau ada langkah baru yang wajib dijalankan sebelum rilis.
- AI salah menebak maksud saya. Ini bukan salah dia, tapi tanda aturannya ambigu. Saya pertegas kalimatnya, bukan menambah aturan baru yang menumpuk.
- Ada keputusan yang saya setujui dan ingin dipakai lagi. Keputusan bagus yang tidak dicatat akan hilang, dan lama-lama AI jadi terlalu hati-hati karena yang tercatat cuma larangan.
Cara memperbaruinya juga ada triknya. Jangan menulis ulang seluruh file, karena Anda akan kehilangan alasan di balik aturan lama. Tambahkan atau pertajam bagian yang relevan saja, dan selalu sertakan alasannya dalam satu kalimat. Alasan itu yang nanti membantu menilai kasus-kasus di perbatasan.
Kesalahan yang saya buat di awal
Supaya Anda tidak mengulangi, ini yang sempat salah di percobaan pertama saya.
Aturannya terlalu umum, jadi tidak mengubah perilaku apa pun. Personanya terlalu banyak sampai tumpang tindih, dan akhirnya cuma jadi hiasan. Aturannya ditulis tanpa alasan, jadi ketika ada kasus yang tidak persis sama, saya sendiri bingung harus ikut yang mana. Dan yang paling sering, file itu dianggap bacaan latar, bukan instruksi yang harus benar-benar dijalankan, sampai saya menambahkan perintah eksplisit untuk membacanya ulang dan melaporkan bagian mana yang dipakai.
Contoh yang saya pakai di artikel ini
Semua contoh file di artikel ini saya buat fiktif dan sengaja disederhanakan. Proyek aslinya adalah aplikasi rekap cashflow mingguan yang saya bangun untuk kantor, jadi isi, angka, nama orang, dan struktur laporannya tidak mungkin saya tampilkan. Yang saya ambil polanya saja, dan polanya itu yang sebenarnya bisa dipakai ulang di proyek apa pun.
Blog yang sedang Anda baca ini juga jalan dengan cara yang sama. Ada satu file persona untuk tim redaksinya, lengkap dengan aturan gaya menulis, daftar hal yang membuat artikel ditolak, dan urutan pemeriksaan sebelum apa pun boleh tayang. Itu sebabnya gaya tulisan di sini tetap sama meskipun ditulis lintas sesi dan lintas minggu.
Kesimpulannya
Ini bukan teknik prompt. Ini lebih mirip menulis SOP untuk rekan kerja baru yang ingatannya hilang setiap hari, tapi kerjanya cepat dan tidak pernah bosan membaca ulang aturan.
Investasinya di depan memang terasa lambat. Saya menghabiskan satu sesi penuh hanya untuk menyusun aturan, tanpa satu baris kode pun jadi. Tapi setelah itu, setiap sesi berikutnya dimulai dari titik yang sama, dengan aturan yang sama, dan kesalahan lama yang sudah tercatat tidak terulang. Untuk proyek yang umurnya lebih dari seminggu, itu jauh lebih murah daripada menjelaskan ulang tiap hari.