Tujuh dari 12 Claude Skill yang Saya Hapus Ternyata Cuma Data

Tujuh dari 12 Claude skill yang saya hapus ternyata cuma data

Pada 28 Agustus 2026 saya menghapus 12 skill dalam satu commit. Skill itu file teks berisi instruksi untuk satu pekerjaan berulang.

Tujuh di antaranya ternyata bukan skill sama sekali. Isinya data, dan tidak ada satu pun yang menyuruh mengerjakan sesuatu.

Nama-namanya about-me, edavos-brand, edavos-icp, daud-rumah-context, dan tiga lainnya.

Tesnya murah dan bisa dijalankan siapa pun yang punya folder instruksi, mau isinya skill AI, runbook, atau SOP tim. Buka daftar file Anda, lalu tanyakan satu per satu kapan terakhir kali file itu dipanggil dengan namanya. Yang tidak pernah dipanggil sendiri adalah bahan, dan bahan tidak perlu diduplikasi.

Saya melewatkan pembedaan itu selama dua bulan. Harganya terbaca di grafik di bawah.

Yang terekam mulai 24 Juli 2026, dan hari itu isinya 18 skill

Saya menyimpan instruksi kerja saya sebagai file teks, satu file untuk satu pekerjaan berulang. Contohnya review Google Ads bulanan atau rekap kartu kredit. Claude membaca file itu lalu mengerjakan isinya, dan saya menyebutnya skill.

Skill tidak menyimpan datanya sendiri. Isinya menunjuk ke file lain lewat alamat, misalnya perintah membaca Saham/registry.md. Selama alamatnya benar, semuanya jalan.

Saya mulai menulis skill sekitar Juni 2026. Angka periode itu tidak ada, karena waktu itu saya belum menyimpan apa pun di git. Yang terekam baru dimulai 24 Juli 2026.

Sisanya tercatat sendiri. Ada routine yang commit isi folder kerja saya tiap sore hari kerja, dan jumlah skill ikut ditulis di pesan commit-nya. Saya tidak pernah berniat menjadikan itu alat ukur.

Dari 35 ke 19 dalam empat hari. Turun 46%.

Saya pikir saya sedang membangun sistem. Sebagian besar yang saya bangun ternyata salinan.

Satu perubahan path pada 28 Agustus 2026 mematikan 16 skill

Pada 28 Agustus 2026 saya mengubah alamat itu. Satu file indeks saya pecah jadi empat, satu untuk tiap folder, dan beberapa file ikut berganti nama. Pekerjaannya sepele.

Setelah itu 16 skill saya menunjuk ke alamat yang sudah tidak ada.

Sampai hari itu saya menjalankan dua tempat sekaligus. Skill-nya tinggal di dalam aplikasi Claude, datanya di folder yang saya kelola dengan git sejak akhir Juli. Selama keduanya jarang bersinggungan, pengaturan itu terasa aman.

Yang harus diperbaiki jauh lebih banyak dari 16 baris. Satu skill bernama saham-monthly-review menyebut path lama itu di sembilan tempat, dan ads-google-review menyebutnya di sebelas tempat.

Saya tidak pernah menghitungnya sampai hari itu.

Yang membuat saya berhenti adalah cara memperbaikinya. Jalur resmi yang tersedia waktu itu adalah membuka menu Customize, lalu menempelkan isi 15 skill satu per satu, satu jendela untuk tiap skill.

Saya kerjakan dua, lalu berhenti. Saya sadar sedang menambal akibat, sementara penyebabnya masih utuh.

Penumpukannya sendiri punya sebab yang sederhana. Tiap kali muncul kebutuhan baru, membuat skill baru terasa seperti langkah yang benar, dan ongkosnya nol di hari itu.

Yang tidak kelihatan adalah ongkos yang dibayar kemudian. Tiap kali satu hal berubah, saya harus mencarinya di semua tempat yang pernah menyalinnya, sementara daftar tempat itu tidak pernah saya buat. Selama lima minggu saya menambah tanpa sekali pun menghitung.

Satu file dirujuk sepuluh skill dan tidak pernah dipanggil sendiri

Ada satu file yang membuat polanya kelihatan. Namanya daud-writing-style, isinya aturan menulis untuk konten saya. Sepuluh skill lain merujuknya, dan tidak pernah ada yang memanggilnya sendiri.

Kalau tidak pernah ada yang memanggilnya dengan nama, itu file.

Fakta yang dirujuk sepuluh tempat tetap satu file dengan sepuluh penunjuk. Ubah faktanya sekali, sepuluh penunjuk ikut benar dengan sendirinya. Instruksi yang dirujuk sepuluh tempat adalah sepuluh salinan yang menunggu saling berbeda.

Saya membayar ongkos yang kedua untuk sesuatu yang seharusnya masuk kategori pertama. Tiap kali satu path berubah, saya menyunting sepuluh tempat, dan tiap suntingan punya peluang meleset sendiri.

Itu juga menjelaskan kenapa kerusakan 28 Agustus 2026 terasa besar padahal perubahannya kecil. Yang berhenti bekerja adalah salinannya, bukan faktanya.

Tempat 12 skill itu diisi registry per folder

Isinya pindah jadi file data di dua folder, Daud/ dan Edavos/. Tiap folder dapat satu file registry yang menjawab satu pertanyaan saja: file itu di mana.

Peta di akar repo menyusut dari 62 baris ke 44. Isinya tinggal daftar folder dan lima aturan yang berlaku lintas domain. Saya tahan panjangnya karena file itu terbaca di tiap sesi, jadi tiap baris di situ dibayar berulang kali.

Perubahan yang dulu berarti menempelkan 15 jendela sekarang berarti satu perintah di Claude Code yang menyentuh semua file sekaligus. Itu bagian yang membuat saya pindah. Yang membuat sistemnya lebih baik adalah hal lain, dan saya butuh empat hari untuk memisahkan keduanya.

Dua hal lain menyusul dalam tiga hari berikutnya, dan keduanya soal ingatan.

Tiap domain dapat satu decision log permanen. File itu dibaca sebelum kerja dimulai, dan ditulis di sesi yang sama saat saya mengoreksi hasilnya. Sebelum ada file itu, koreksi yang sama saya ulangi tiap bulan karena tidak ada tempat yang menyimpannya.

Tiap routine terjadwal juga dapat bagian Riwayat di file instruksinya sendiri. Bagian itu dibaca di awal run dan ditulis di akhir run yang sama.

Routine bulanan saya jalan tanpa saya di depan layar. Tanpa riwayat, tiap eksekusi mendiagnosis ulang masalah yang sama dari nol.

Contohnya begini. Pada 5 Agustus 2026 proses instalasi di server saya terlihat menggantung, jadi saya hentikan. Ternyata proses itu memang lambat dan sedang berjalan normal.

Yang saya hentikan meninggalkan folder rusak. Akibatnya baru muncul dua belas hari kemudian, saat layanan mati total dan saya kehilangan waktu berjam-jam untuk menyimpulkan ulang hal yang sudah pernah saya simpulkan. Sekarang penjelasan itu tertulis di file routine-nya, di bagian yang wajib dibaca sebelum run berikutnya dimulai.

Skrip audit yang berumur satu jam menghasilkan empat laporan palsu

Indeks yang dipelihara manusia punya satu kelemahan yang tidak bisa dihapus. Dia tidak bisa memberi tahu kalau dirinya sudah basi.

File baru yang tidak saya daftarkan akan diam-diam tidak pernah terbaca. Tidak ada yang error, tidak ada yang gagal, dan saya baru sadar berbulan-bulan kemudian saat ada jawaban yang terasa ganjil.

Jadi pada 1 September 2026 saya menulis skrip audit. Kerjanya membandingkan isi tiap folder dengan registry-nya, lalu melaporkan file yang tidak tercatat dan entry yang menunjuk file yang sudah tidak ada.

Run pertamanya menemukan empat masalah. Keempatnya salah.

Dua di antaranya file yang memang sengaja saya hapus minggu sebelumnya, lengkap dengan catatan penghapusannya di registry. Satu file arsip yang belum dibuat. Satu lagi nama file yang saya tulis sebagai singkatan, sebaris dengan file lain di folder yang sama.

Empat itu angka kecil, dan justru itu yang membuat saya berhenti. Skrip yang baru berumur satu jam sudah menghasilkan empat laporan palsu. Kalau saya biarkan, laporan bulan depan akan berisi campuran temuan asli dan gangguan, dan saya akan berhenti membacanya sebelum sempat tahu mana yang mana.

Saya perbaiki skripnya hari itu juga, dan alasannya sekarang tertulis di file routine-nya. Audit yang berisik akan saya abaikan setelah dua bulan, jadi laporan palsu lebih mahal daripada temuan yang lolos.

Audit itu sekarang berjalan sendiri tiap tanggal 1, siang hari. Bagian ini belum selesai. Saya baru menjalankannya sekali, dan audit bulanan yang sesungguhnya baru berjalan 1 Oktober 2026.

Pencarian semantik kalah selama saya masih hafal isi foldernya

Pertanyaan yang wajar muncul di titik ini adalah kenapa saya tidak pakai pencarian semantik saja, supaya tidak perlu mendaftarkan file satu per satu. Saya pertimbangkan dan tidak jadi. Alasannya di luar kerumitan memasangnya.

Masalahnya beda. Pencarian semantik menyelesaikan masalah korpus besar yang tidak terstruktur, milik orang yang tidak hafal isinya. Punya saya berisi puluhan file, strukturnya saya sendiri yang buat, dan saya hafal peta besarnya.

Pencarian bukan hambatan saya.

Ada ongkos berjalan yang juga sering dilewat. Indeks semacam itu harus dibangun ulang tiap kali isinya berubah, dan isi folder saya berubah hampir tiap sesi. Decision log ditulis ulang tiap kali saya mengoreksi hasil kerja, karena memang begitu rancangannya.

Artinya saya menambah satu proses yang harus selalu sinkron, plus satu cara gagal yang baru. Indeks yang tertinggal satu versi akan menjawab dengan percaya diri memakai data lama, dan tidak ada yang error.

Yang saya rugikan berikutnya adalah presisi. Pencarian berdasarkan kemiripan makna akan menarik potongan dari tiga domain berbeda sekaligus, dan model yang membacanya tidak tahu mana yang berhak menang. Sistem yang sekarang tidak punya kegagalan seperti itu: satu registry menunjuk satu file, dan file itu dibaca utuh beserta konteksnya.

Ada satu hal yang memang hilang, dan saya catat supaya tidak lupa. Saya tidak bisa mencari sesuatu yang saya sendiri tidak tahu tersimpan di mana.

Selama saya masih hafal, indeks yang ditulis eksplisit menang. Begitu saya mulai lupa, perhitungannya berubah.

Cara mengukur apakah konsolidasi seperti ini berhasil

Saya menulis ini lima hari setelah penghapusan, jadi saya belum tahu hasilnya. Yang bisa saya lakukan sekarang adalah menetapkan apa yang akan membatalkan keputusan ini.

Angka 30 itu sendiri tidak masalah. Yang masalah adalah artinya, yaitu saya cuma mengulang siklus penumpukan tanpa memutus kebiasaan yang menyebabkannya.

Tanda pertama paling saya percaya, karena alat ukurnya sudah jalan sebelum taruhannya dibuat. Routine yang commit tiap sore hari kerja itu menulis jumlah skill di tiap pesan commit tanpa saya kerjakan apa-apa. Angka Desember 2026 tinggal saya baca dari pesan commit-nya.

Langkah pertamanya cuma satu, dan sudah disebut di awal. Buka daftar file instruksi Anda, lalu tandai mana yang tidak pernah dipanggil dengan namanya sendiri. Yang tertandai itu pindahkan jadi file data, dan tinggalkan satu penunjuk di tempat lamanya.

Catatan pembaruan

Bagian ini saya isi saat tiap taruhan di atas jatuh tempo, supaya artikelnya bisa dinilai dari hasilnya, bukan dari niatnya.

• Oktober 2026. Audit bulanan pertama. Belum diisi.
• Desember 2026. Jumlah skill dan dua tanda lainnya. Belum diisi.