Skill Claude saya mengulang rekomendasi yang sudah dikerjakan

Skill review Google Ads saya mengeluarkan 8 action item dalam satu siklus. Bulan berikutnya sebagian item itu muncul lagi, kata per kata, padahal sudah dikerjakan.

Skill-nya tidak rusak. Ia tidak punya cara mengetahui apa yang terjadi pada putaran sebelumnya.

Jendela konteks yang lebih besar tidak menyelesaikan ini. Yang saya pasang adalah satu file teks yang menyimpan setiap keputusan beserta kondisi yang membatalkannya, dibaca di awal putaran berikutnya dan ditulis di akhir putaran yang sama. Formatnya ada di bawah, cukup lengkap untuk Anda salin.

Yang hilang bukan konteks, tapi alasan

Diagnosis yang biasa dipakai adalah agent kekurangan konteks. Saya rasa itu salah alamat. Repo saya bisa dibaca utuh kapan saja, dan jendela konteks model hari ini jauh lebih besar dari yang saya butuhkan.

Yang tidak tersimpan di mana pun adalah alasan. Repo menyimpan hasil, git menyimpan perubahannya.

Tidak satu pun dari keduanya menyimpan kenapa sebuah keputusan diambil, dan apa yang seharusnya membatalkannya.

Gejalanya muncul sebagai pertanyaan yang tidak bisa saya jawab sendiri. Kalimat yang membuat saya membuat file ini tercatat apa adanya di entry pertamanya:

“Kenapa dulu Landing Page ini saya pause?”

Halamannya ada. Statusnya ada. Tanggalnya ada.

Alasannya hilang, dan tanpa alasan saya tidak bisa menilai apakah keputusan itu masih benar.

Loop yang tidak bisa gagal bukan loop

Sebagian besar yang disebut feedback loop berhenti di mencatat hasil. Itu tidak memperbaiki apa pun. Loop baru bekerja kalau putaran berikutnya punya cara menyatakan bahwa putaran sebelumnya salah.

Karena itu setiap entry wajib punya field batal kalau. Isinya kondisi konkret yang bisa dicek. Entry tanpa kondisi pembatalan adalah keputusan yang tidak pernah bisa salah, dan keputusan seperti itu tidak berguna.

Ini format entry yang saya pakai:

## [YYYY-MM-DD] <jenis> | <judul singkat>
id: <prefix>-<nnn>
alasan: <kenapa keputusan ini diambil, dengan angka/fakta kalau ada>
ekspektasi: <apa yang seharusnya terjadi kalau keputusan ini benar, dan kapan terlihat>
tinjau: <YYYY-MM>
batal kalau: <kondisi konkret yang membatalkan keputusan ini>
status: aktif | selesai | dibatalkan | diganti oleh <id>

Dua aturan menempel pada format itu, dan keduanya keras.

File ini append-only. Entry baru masuk di bawah. Entry lama tidak pernah disunting atau dihapus.

Satu-satunya field yang boleh berubah pada entry lama adalah status.

Keputusan yang berubah ditulis sebagai entry baru yang merujuk id lama. Entry lama dibiarkan berdiri apa adanya.

Kalau riwayat boleh ditimpa, yang tersisa cuma versi terakhir. Versi terakhir tidak bisa dipakai memeriksa cara saya mengambil keputusan.

Buktinya: rekomendasi saya sendiri yang dibatalkan

Review Google Ads periode Mei sampai Juli 2026 memberi verdict BOCOR ke satu landing page partner di akun Edavos. Angkanya mendukung: 0 konversi dari 5,295 impresi, belanja Rp 37,655. Rekomendasi saya waktu itu adalah mengeluarkan halaman itu dari dynamic ad target.

Yang terjadi berikutnya berbeda dari rekomendasi itu. Halaman dipindah ke campaign Brand.

Rata-rata conversion rate akun itu 12,85%. Halaman yang saya rekomendasikan matikan berjalan hampir dua kali lipat rata-rata akunnya sendiri.

Review Agustus membaca log di awal, menemukan rekomendasi Mei sampai Juli, dan membatalkannya. Entry pembatalannya berbunyi begini:

## [2026-09-01] koreksi | Rekomendasi mengeluarkan /partner-tp-link-jakarta/ dari DSA dibatalkan
id: edv-007
alasan: ... Yang salah bukan halamannya, tapi campaign tempat ia dipasang.
        Pelajaran yang digeneralisasi: verdict BOCOR pada level landing page
        tidak sah kalau campaign dan intent yang mengarah ke halaman itu
        belum diperiksa.
ekspektasi: Halaman tetap jadi target DSA di 06 | Brand. Review berikutnya
        memeriksa campaign sebelum mem-verdict sebuah landing page.
batal kalau: Conv rate halaman ini turun di bawah rata-rata akun (12,85%)
        selama dua periode berturut.
status: aktif

Perhatikan baris ekspektasi. Pembatalan satu rekomendasi cuma separuh isinya. Sisanya aturan baca yang ikut lahir, yaitu memeriksa campaign sebelum mem-verdict halaman.

Satu kesalahan berubah jadi urutan pemeriksaan yang dipakai review sesudahnya.

Dan pembatalan itu sendiri sudah punya kondisi pembatalnya. Kalau conversion rate halaman itu jatuh di bawah rata-rata akun dua periode berturut, entry ini ikut gugur.

Instruksinya tetap, yang berubah file yang dibacanya

Pola self-improvement yang sering dibagikan bentuknya begini. Agent mengerjakan tugas, manusia memberi umpan balik, lalu agent menulis ulang skill-nya sendiri berdasarkan umpan balik itu.

Sistem saya tidak menyentuh skill sama sekali. Skill review Ads bulan ini identik dengan yang bulan lalu. Yang berubah adalah file yang dibacanya.

Bedanya punya konsekuensi teknis. Agent yang menulis ulang instruksinya sendiri tiap putaran melakukan mutasi tanpa jejak. Kalau perbaikannya salah, tidak ada yang bisa dibalik, karena versi yang salah sudah menimpa versi yang benar.

Memisahkan memori dari instruksi menghindari itu. Instruksi tetap stabil dan bisa dibaca sebagai satu hal. Memori tumbuh sebagai riwayat yang bisa diperiksa, dan tiap barisnya membawa kondisi yang bisa membunuhnya.

Loop yang mahal dibaca akan berhenti dibaca

Ada batas yang muncul begitu sistem ini berjalan beberapa bulan. Log dibaca di awal tiap pekerjaan, jadi kalau isinya tumbuh tanpa batas, biaya membacanya naik terus.

Ada efek kedua yang lebih halus. Entry yang sudah dipromosikan jadi aturan tetap akan terbaca dua kali, dari file aturan dan dari log. Aturan yang terbaca dua kali dari dua tempat justru dipatuhi lebih longgar.

Karena itu log aktif hanya berisi entry berstatus aktif. Begitu sebuah entry selesai atau dipromosikan jadi aturan, ia pindah ke file arsip. Pemindahan adalah satu-satunya perkecualian aturan append-only, dan hanya boleh memindahkan, tidak boleh mengubah isi.

Arsipnya tidak pernah dibaca rutin. Ia dibuka hanya kalau ada yang bertanya kenapa sebuah aturan ada.

Per 6-Sep-26, log yang saya jalankan berisi 38, 15, dan 7 entry aktif untuk tiga domain berbeda. Semuanya masih di ukuran yang murah dibaca di awal sesi.

Kalau mau menyalin

Ambil format entry di atas apa adanya. Satu file per domain pekerjaan.

Tiga hal yang menentukan apakah ini bekerja atau cuma menambah beban tulis.

batal kalau wajib berisi kondisi yang bisa dicek. File dibaca di awal pekerjaan dan ditulis di akhir pekerjaan yang sama. Entry yang sudah jadi aturan dipindah keluar supaya yang aktif tetap murah dibaca.

Kalau setelah tiga siklus file itu tidak pernah dibaca di luar sesi penulisannya, matikan. Itu kondisi pembatal yang saya tulis untuk log saya sendiri di entry pertamanya.