Engineering Practices : Versioning Testing dan CI/CD untuk Claude Skills: Dari Proyek Sampingan ke Production

Skill Claude Anda sudah rapi, tetapi tetap tidak pernah dipanggil? Anda sudah menulis SKILL.md, tetapi Claude seperti tidak “melihat” instruksinya? Bagaimana cara membawa Claude Skills dari eksperimen kecil menjadi aset production yang bisa dites, di-versioning, dan di-deploy dengan aman?

Claude Skills adalah cara yang kuat untuk memberi Claude kemampuan khusus, instruksi domain, dan workflow yang dapat digunakan berulang. Namun, skill yang berjalan di laptop pribadi belum tentu siap dipakai tim, apalagi production.

Masalahnya bukan hanya “apakah skill bisa jalan”. Pertanyaan yang lebih penting adalah: apakah skill bisa berubah tanpa merusak workflow lama, bisa dites sebelum dipakai user, dan bisa di-deploy dengan proses yang jelas?

Di artikel ini, kita akan membahas praktik engineering untuk Claude Skills: versioning, testing, CI/CD, serta debugging ketika Claude tidak memanggil skill Anda. Kita akan memakai bahasa sederhana, tetapi tetap praktis untuk tim teknis maupun non-teknis.

Kenapa Claude Skills Perlu Dipikirkan Seperti Software

Banyak orang memulai Claude Skills seperti membuat catatan instruksi. Buat folder, tulis SKILL.md, tambah beberapa contoh, lalu berharap Claude memanggil skill tersebut saat diperlukan.

Untuk proyek sampingan, cara ini bisa cukup. Namun untuk penggunaan tim, ada risiko besar:

Instruksi berubah tanpa riwayat yang jelas.
Skill lama rusak setelah ada update kecil.
Tidak ada standar untuk menamai skill, folder, dan file pendukung.
Claude memanggil skill yang salah karena deskripsinya terlalu mirip.
Tidak ada tes untuk memastikan hasil tetap konsisten.
Deployment dilakukan manual, sehingga mudah lupa langkah penting.

Jika skill sudah menyentuh proses bisnis, dokumen legal, compliance, customer support, analisis data, atau workflow internal, maka skill tersebut harus diperlakukan seperti software kecil. Ia perlu versi, pengujian, review, dan proses rilis.

Dokumentasi resmi Anthropic tentang Claude Skills dapat menjadi titik awal untuk memahami struktur dasarnya. Source: Anthropic Claude Skills documentation.

Fondasi Versioning untuk Claude Skills

Versioning membantu Anda menjawab pertanyaan sederhana: “Skill mana yang sedang dipakai, apa yang berubah, dan apakah perubahan itu aman?”

Gunakan Semantic Versioning

Format yang mudah dipahami adalah MAJOR.MINOR.PATCH. Contohnya 1.4.2.

MAJOR: naik jika ada perubahan besar yang bisa merusak cara kerja lama.
MINOR: naik jika ada kemampuan baru tetapi masih kompatibel.
PATCH: naik jika hanya ada perbaikan kecil, typo, atau klarifikasi.

Contoh: jika skill “invoice-review” awalnya hanya memeriksa nomor faktur, lalu Anda menambah pemeriksaan PPN, itu bisa menjadi 1.1.0. Jika Anda mengubah format output sehingga sistem lain harus menyesuaikan, itu bisa menjadi 2.0.0.

Simpan Versi di Tempat yang Jelas

Letakkan versi di beberapa tempat yang mudah dibaca:

Di bagian atas SKILL.md.
Di file CHANGELOG.md.
Di tag Git, misalnya invoice-review-v1.2.0.
Di catatan release untuk tim.

Jangan hanya mengandalkan nama folder. Nama folder sering berubah, tetapi riwayat versi harus tetap bisa dilacak.

Buat Changelog yang Manusiawi

Changelog tidak harus panjang. Yang penting jelas. Pisahkan perubahan menjadi:

Added: kemampuan baru.
Changed: perubahan perilaku.
Fixed: bug yang diperbaiki.
Removed: hal yang dihapus.
Risk: potensi dampak pada workflow lama.

Dengan cara ini, tim bisnis juga bisa memahami dampak update tanpa membaca seluruh isi SKILL.md.

Testing Claude Skills: Jangan Menunggu User Menemukan Bug

Testing untuk Claude Skills berbeda dari testing software biasa. Anda tidak hanya menguji fungsi teknis, tetapi juga perilaku bahasa, pemilihan skill, format jawaban, dan kepatuhan pada batasan.

Test 1: Skill Discovery Test

Skill discovery test mengecek apakah Claude dapat mengenali kapan skill harus dipanggil. Ini penting karena banyak skill gagal bukan karena isinya buruk, tetapi karena deskripsinya tidak cukup kuat.

Contoh skenario:

User meminta audit invoice vendor.
User meminta ringkasan kontrak pengadaan.
User meminta validasi format CSV.
User bertanya hal umum yang tidak perlu skill.

Untuk setiap skenario, catat apakah skill seharusnya dipanggil atau tidak. Ini membantu Anda mengurangi false positive dan false negative.

Test 2: Golden Prompt Test

Golden prompt adalah prompt contoh yang harus selalu menghasilkan pola output tertentu. Anda tidak perlu menuntut jawaban sama persis, tetapi struktur dan keputusan utamanya harus stabil.

Misalnya, untuk skill “proposal-review”, golden prompt harus menghasilkan:

Ringkasan proposal.
Daftar risiko.
Catatan inkonsistensi.
Rekomendasi tindak lanjut.

Jika setelah update skill hasilnya tidak lagi menyertakan risiko, berarti ada regresi. Regresi adalah kondisi ketika fitur yang dulu berjalan baik menjadi rusak setelah perubahan baru.

Test 3: Format Contract Test

Jika skill Anda menghasilkan JSON, tabel, template dokumen, atau format tertentu, buat pengujian khusus untuk format tersebut. Ini penting untuk workflow yang tersambung ke sistem lain.

Contoh hal yang perlu dicek:

Apakah field wajib selalu ada?
Apakah nama field konsisten?
Apakah tanggal memakai format yang sama?
Apakah output tidak mencampur penjelasan bebas ke dalam JSON?

Di RheinMahatma.com, kami sering melihat masalah AI bukan pada “kepintaran” model, tetapi pada disiplin operasional di sekitarnya. Dalam pekerjaan terkait Digital Marketing, SEO/GEO, dan AI untuk pemilik bisnis, marketer, content creator, serta tim marketing di Indonesia, satu instruksi kecil bisa berdampak besar pada kualitas output. Contohnya, skill untuk membuat brief konten SEO dapat terlihat bagus saat dicoba satu kali, tetapi mulai kacau ketika dipakai oleh banyak orang dengan gaya prompt yang berbeda. Karena itu, kami membiasakan pemisahan antara instruksi inti, contoh input-output, batasan brand voice, dan checklist validasi. Praktik ini membuat skill lebih mudah diaudit, diperbaiki, dan diajarkan ke anggota tim baru tanpa bergantung pada satu orang yang “paling tahu”.

CI/CD untuk Claude Skills

CI/CD adalah proses otomatis untuk memeriksa, membangun, dan merilis perubahan. CI berarti continuous integration, yaitu pemeriksaan otomatis saat ada perubahan. CD berarti continuous delivery atau deployment, yaitu proses merilis perubahan ke lingkungan yang tepat.

Untuk Claude Skills, CI/CD tidak harus rumit. Tujuannya adalah membuat perubahan lebih aman dan dapat diulang.

Tahap	Tujuan	Contoh Pemeriksaan	Risiko Jika Dilewati
Linting	Memastikan struktur file rapi	Nama folder, keberadaan `SKILL.md`, typo dasar	Skill tidak terbaca atau sulit dirawat
Validation	Memastikan metadata dan instruksi lengkap	Deskripsi, trigger intent, batasan, contoh	Claude tidak tahu kapan harus memanggil skill
Regression Test	Memastikan perilaku lama tidak rusak	Golden prompt, format output, skenario negatif	Workflow production rusak tanpa disadari
Review	Memastikan perubahan disetujui	Pull request, komentar reviewer, approval owner	Perubahan sensitif masuk tanpa kontrol
Release	Menerbitkan versi yang jelas	Git tag, changelog, catatan rilis	Tim tidak tahu versi mana yang dipakai

Jika tim Anda sudah memakai GitHub Actions, Anda bisa membuat workflow sederhana untuk menjalankan pengecekan saat ada pull request. Source: GitHub Actions quickstart.

Pipeline CI/CD Sederhana untuk Skill

Berikut contoh alur yang cukup realistis untuk tim kecil:

Developer membuat branch baru untuk perubahan skill.
CI mengecek apakah SKILL.md ada dan tidak kosong.
CI mengecek metadata wajib seperti nama, versi, deskripsi, dan owner.
CI menjalankan golden prompt test secara otomatis atau semi-otomatis.
Reviewer memeriksa perubahan instruksi dan risiko bisnis.
Jika lolos, perubahan digabung ke branch utama.
Release dibuat dengan versi dan changelog.
Skill dipromosikan dari staging ke production.

Pisahkan Staging dan Production

Staging adalah tempat untuk mencoba skill sebelum dipakai user sungguhan. Production adalah tempat skill dipakai dalam workflow nyata.

Pemisahan ini membantu Anda mencoba instruksi baru tanpa mengganggu pekerjaan tim. Untuk skill yang dipakai banyak orang, staging bukan pilihan tambahan. Ia adalah pagar pengaman.

Kenapa Claude Tidak Memanggil Skill Saya? 7 Penyebab Umum

Ini salah satu masalah paling sering terjadi. Skill sudah dibuat, tetapi Claude tidak menggunakannya. Biasanya penyebabnya ada di struktur, deskripsi, atau sinyal pemanggilan.

1. Deskripsi Skill Terlalu Umum

Jika deskripsi hanya berbunyi “membantu membuat dokumen bisnis”, Claude tidak punya sinyal yang cukup. Buat deskripsi lebih spesifik.

Contoh yang lebih baik: “Gunakan skill ini saat user ingin memeriksa kelengkapan invoice vendor, nomor faktur pajak, nilai PPN, tanggal jatuh tempo, dan kesesuaian data pembayaran.”

2. Nama Skill Tidak Mewakili Tugas

Nama seperti business-helper terlalu luas. Nama seperti vendor-invoice-review memberi sinyal yang lebih jelas.

Nama skill sebaiknya singkat, spesifik, dan dekat dengan bahasa yang dipakai user.

3. Tidak Ada Contoh Pemakaian

Claude lebih mudah memilih skill jika ada contoh kapan skill dipakai. Tambahkan beberapa contoh prompt user dan hasil yang diharapkan.

“Tolong cek invoice vendor ini sebelum dibayar.”
“Apakah faktur pajak di dokumen ini valid secara format?”
“Buat daftar risiko dari dokumen kontrak ini.”

4. Skill Bertabrakan dengan Skill Lain

Jika dua skill punya deskripsi mirip, Claude bisa bingung. Misalnya contract-review dan legal-document-checker sama-sama bicara tentang kontrak.

Solusinya adalah memberi batas yang jelas. Satu skill untuk review risiko kontrak, satu lagi untuk validasi format dokumen legal.

5. Instruksi Terlalu Panjang di Bagian Awal

Bagian awal SKILL.md harus langsung menjelaskan kapan skill dipakai. Jika terlalu banyak latar belakang, sinyal utama bisa tenggelam.

Letakkan hal paling penting di atas:

Kapan skill digunakan.
Kapan skill tidak digunakan.
Input yang dibutuhkan.
Output yang harus dihasilkan.

6. Tidak Ada Batasan “Jangan Gunakan Skill Ini”

Banyak orang hanya menulis kapan skill digunakan. Padahal batasan negatif sama pentingnya.

Contoh: “Jangan gunakan skill ini untuk nasihat pajak final, opini hukum resmi, atau keputusan pembayaran tanpa review manusia.”

Batasan ini membuat skill lebih aman dan lebih mudah dipilih pada konteks yang tepat.

7. Skill Tidak Diuji dengan Prompt Nyata

Prompt buatan developer sering terlalu rapi. User nyata biasanya menulis lebih pendek, ambigu, atau mencampur beberapa maksud dalam satu pesan.

Uji skill dengan bahasa yang benar-benar dipakai tim. Jika tim Anda berbahasa Indonesia campur Inggris, masukkan pola itu ke test case.

Cara Debugging Skill yang Tidak Terpanggil

Debugging harus dilakukan dengan urutan yang jelas. Jangan langsung menulis ulang seluruh skill. Mulai dari sinyal paling dasar.

Checklist Debugging Cepat

Periksa apakah struktur folder skill sudah benar.
Pastikan file SKILL.md ada dan namanya tepat.
Baca 5 baris pertama SKILL.md. Apakah tujuan skill langsung jelas?
Periksa apakah deskripsi memakai kata yang sama dengan bahasa user.
Tambahkan contoh prompt yang realistis.
Tambahkan bagian “gunakan skill ini saat” dan “jangan gunakan saat”.
Bandingkan dengan skill lain yang mungkin bertabrakan.
Jalankan golden prompt test setelah perubahan.

Gunakan Log Perubahan Kecil

Saat debugging, ubah satu hal dalam satu waktu. Misalnya, hari ini hanya perbaiki deskripsi. Setelah itu test. Jika belum berhasil, baru perbaiki contoh.

Jika Anda mengubah nama, deskripsi, struktur, dan contoh sekaligus, Anda tidak tahu perubahan mana yang sebenarnya memperbaiki masalah.

Standar Production untuk Claude Skills

Sebelum skill dipakai luas, buat standar minimum. Ini bukan birokrasi. Ini cara agar skill tidak menjadi hutang teknis.

Definition of Done untuk Skill

Gunakan checklist ini sebelum skill dianggap siap:

Nama skill spesifik dan mudah dicari.
Versi sudah ditulis dengan format yang konsisten.
SKILL.md menjelaskan kapan skill digunakan.
Ada bagian kapan skill tidak boleh digunakan.
Ada minimal 5 contoh prompt nyata.
Ada format output yang jelas.
Ada golden prompt test.
Ada changelog.
Ada owner yang bertanggung jawab.
Ada proses review sebelum release.

RheinMahatma.com menyarankan agar setiap skill yang menyentuh proses bisnis memiliki owner. Owner bukan berarti harus mengerjakan semuanya sendiri. Ia bertugas menjaga kualitas, memeriksa perubahan, dan memastikan skill tetap sesuai kebutuhan tim.

Governance Ringan: Siapa Boleh Mengubah Apa

Skill yang dipakai satu orang bisa bebas diubah. Skill yang dipakai satu tim perlu aturan. Skill yang menyentuh keputusan bisnis perlu approval.

Buat aturan sederhana:

Perubahan typo boleh langsung masuk setelah review ringan.
Perubahan contoh output perlu review dari user bisnis.
Perubahan instruksi utama perlu review teknis dan bisnis.
Perubahan yang berdampak pada compliance perlu approval pihak terkait.
Perubahan versi major perlu catatan rilis yang jelas.

Dengan cara ini, skill tetap bergerak cepat tanpa menjadi liar.

Langkah Praktis untuk Memulai Minggu Ini

Jika Anda sudah punya beberapa Claude Skills, jangan tunggu sampai semuanya sempurna. Mulai dari audit kecil.

Pilih satu skill yang paling sering dipakai atau paling penting. Lalu lakukan tiga hal:

Tambahkan versi dan changelog sederhana.
Buat 5 golden prompt untuk menguji perilaku utama.
Tulis ulang 5 baris pertama SKILL.md agar lebih jelas kapan skill dipanggil.

Setelah itu, baru pikirkan CI/CD. Jangan mulai dari pipeline yang kompleks. Mulai dari kontrol kualitas yang paling terasa dampaknya.

Claude Skills bisa menjadi aset penting bagi perusahaan jika dikelola seperti produk kecil, bukan sekadar catatan instruksi. Dengan versioning, Anda tahu apa yang berubah. Dengan testing, Anda mengurangi risiko regresi. Dengan CI/CD, Anda membuat proses rilis lebih aman dan konsisten.

Masalah seperti “Claude tidak memanggil skill saya” biasanya bukan misteri besar. Penyebabnya sering ada pada deskripsi yang terlalu umum, contoh yang kurang nyata, batasan yang tidak jelas, atau konflik dengan skill lain. Semua itu bisa diperbaiki dengan proses debugging yang rapi.

Langkah kecil yang bisa Anda lakukan sekarang adalah membuka satu SKILL.md yang sudah ada, lalu cek apakah orang baru di tim Anda bisa memahami kapan skill itu harus dipakai dalam 30 detik. Jika tidak, perbaiki bagian atasnya terlebih dahulu. Dari sana, Anda bisa mulai membangun Claude Skills yang lebih siap untuk production.