Claude Skill: Panduan Membuat Skill yang Efektif

Sering merasa capek harus kasih instruksi yang itu-itu aja tiap pakai Claude? Nah, kamu bisa pakai fitur Skill biar cara kerja kamu tersimpan dan hasilnya jadi lebih konsisten.

Caranya gampang banget:

1. Bikin aturannya sekali aja.

2. Coba dulu sampai hasilnya pas.

3. Simpan, terus biarin Claude yang jalanin setiap kali kamu butuh bantuan yang serupa.

Praktis, kan? Nggak perlu ribet ngetik instruksi berulang-ulang lagi!

Persiapan sebelum membuat Claude Skill

Claude Skill atau Agent Skill adalah folder berisi instruksi, referensi, skrip, dan aset yang membantu Claude menangani pekerjaan tertentu secara berulang. Claude memeriksa Skill yang tersedia, lalu memuat Skill yang relevan dengan permintaan pengguna.

Claude Skill adalah paket instruksi yang mengajarkan Claude cara menyelesaikan tugas atau alur kerja tertentu secara konsisten.

Skill berbeda dari prompt sekali pakai. Prompt menjelaskan kebutuhan untuk satu percakapan, sedangkan Skill menyimpan prosedur agar dapat digunakan kembali pada tugas serupa.

Skill juga berbeda dari MCP. MCP memberi Claude akses ke alat atau layanan, sementara Skill menjelaskan cara memakai kemampuan tersebut untuk mencapai hasil yang diinginkan.

Sebelum membuat Skill, pilih satu pekerjaan yang memang sering diulang. Skill pertama sebaiknya tidak mencoba menangani seluruh operasi tim sekaligus.

Contoh ruang lingkup yang masuk akal:

• Menulis pembaruan proyek dengan format tetap

• Memeriksa artikel berdasarkan pedoman editorial

• Membuat dokumen yang mengikuti identitas merek

• Mengubah data mentah menjadi laporan mingguan

• Meninjau pull request dengan daftar pemeriksaan tertentu

• Menyiapkan agenda rapat dari catatan proyek

• Membuat spesifikasi handoff untuk desain

• Menjalankan pemeriksaan kualitas sebelum rilis

Siapkan dua atau tiga contoh permintaan nyata yang seharusnya memicu Skill. Tambahkan juga permintaan yang mirip tetapi seharusnya tidak memicunya.

Misalnya, Skill weekly-sales-report dapat memiliki contoh berikut:

Seharusnya memicu:

• “Buat laporan penjualan minggu ini.”

• “Ringkas kinerja penjualan regional.”

• “Siapkan weekly sales update untuk pimpinan.”

Seharusnya tidak memicu:

• “Tulis email untuk calon pelanggan.”

• “Buat strategi harga produk.”

• “Jelaskan cara menghitung margin kotor.”

Kamu juga perlu menentukan hasil yang dianggap benar. Tanpa kriteria ini, Skill mungkin aktif pada waktu yang tepat tetapi tetap menghasilkan dokumen yang tidak lengkap.

Tuliskan kriteria sederhana seperti:

1. Laporan memiliki ringkasan eksekutif.

2. Semua angka berasal dari data yang diberikan.

3. Perubahan dibanding minggu sebelumnya ditampilkan.

4. Risiko diberi tingkat prioritas.

5. Tidak ada data pelanggan yang ditampilkan tanpa izin.

6. Output mengikuti struktur dan gaya yang disetujui.

Untuk mulai, siapkan editor teks, sebuah folder kerja, dan akses ke Claude yang mendukung Skills. Jika Skill memakai skrip, siapkan juga runtime yang diperlukan seperti Python atau Node.js.

Pelajari contoh pada repositori resmi Agent Skills milik Anthropic sebelum menyusun struktur sendiri. Contoh nyata membantu menunjukkan seberapa rinci instruksi perlu ditulis tanpa membuat file utama terlalu panjang.

Step 1: Tentukan satu hasil yang harus dibuat

Mulai dari hasil, bukan dari fitur. Kalimat tujuan yang baik menjelaskan apa yang dihasilkan, kapan Skill digunakan, dan standar apa yang harus dipenuhi.

Gunakan pola berikut:

Skill ini membantu [jenis pengguna]
menghasilkan [hasil spesifik]
ketika [pemicu tugas]
dengan mengikuti [standar utama].

Contoh:

Skill ini membantu tim produk membuat pembaruan proyek mingguan
ketika pengguna meminta status proyek, ringkasan sprint, atau laporan risiko.
Hasil harus ringkas, memakai data yang tersedia, dan memisahkan
progres, rencana, masalah, serta keputusan yang dibutuhkan.

Jangan memulai dengan tujuan seperti “membantu pekerjaan pemasaran”. Ruang lingkup tersebut terlalu luas karena dapat mencakup riset, iklan, media sosial, analitik, desain, dan penulisan.

Baca juga Kimi K3: Model AI Open-Weight Terkuat Moonshot?

Pecah tujuan besar menjadi beberapa Skill. Pendekatan ini membuat pemicu lebih mudah dipahami dan hasil lebih mudah diuji.

Pilih tugas yang memiliki pola jelas. Jika proses selalu berubah berdasarkan situasi, tulis cabang keputusan di dalam Skill atau persempit ruang lingkupnya.

Setelah itu, petakan alur kerja manusia yang sudah berjalan. Jangan meminta Claude menciptakan proses baru jika tim sebenarnya telah memiliki prosedur yang terbukti efektif.

Gunakan pertanyaan berikut:

• Apa yang dilakukan terlebih dahulu?

• Data apa yang wajib tersedia?

• Kapan Claude harus meminta klarifikasi?

• Keputusan apa yang boleh dibuat otomatis?

• Bagian mana yang harus dikonfirmasi pengguna?

• Pemeriksaan apa yang dilakukan sebelum hasil diserahkan?

• Kesalahan apa yang sering terjadi?

• Kapan proses harus dihentikan?

Ubah jawabannya menjadi urutan tindakan. Sebuah Skill yang baik tidak hanya menjelaskan bentuk output, tetapi juga cara mencapai output tersebut.

Contoh alur untuk Skill laporan mingguan:

1. Identifikasi periode laporan.

2. Periksa sumber data yang tersedia.

3. Minta data yang belum ada dan benar-benar diperlukan.

4. Hitung perubahan utama.

5. Kelompokkan temuan berdasarkan dampak.

6. Tulis ringkasan untuk pembaca nonteknis.

7. Jalankan pemeriksaan angka.

8. Tandai asumsi dan data yang belum terverifikasi.

9. Sajikan laporan dalam format yang disetujui.

Batasi versi pertama pada satu hasil utama. Setelah versi tersebut stabil, kamu dapat menambahkan variasi output atau integrasi lain.

Step 2: Buat folder dan file SKILL.md

Setiap Skill memerlukan folder sendiri. Di dalamnya, file utama harus bernama SKILL.md dengan huruf kapital yang tepat.

Gunakan nama folder berbentuk kebab-case:

weekly-sales-report/
└── SKILL.md

Hindari spasi, huruf kapital, dan garis bawah pada nama folder.

weekly-sales-report     benar
Weekly Sales Report     salah
weekly_sales_report     salah
WeeklySalesReport       salah

Skill yang sederhana cukup memakai satu file. Skill yang lebih lengkap dapat menambahkan folder untuk skrip, referensi, dan aset.

weekly-sales-report/
├── SKILL.md
├── scripts/
│   ├── calculate_metrics.py
│   └── validate_input.py
├── references/
│   ├── metric-definitions.md
│   ├── writing-style.md
│   └── examples/
│       ├── strong-report.md
│       └── weak-report.md
└── assets/
    └── report-template.md

Setiap bagian memiliki fungsi berbeda:

• SKILL.md memuat metadata dan prosedur utama.

• scripts/ menyimpan kode untuk proses yang perlu hasil konsisten.

• references/ menyimpan penjelasan rinci yang hanya dibaca saat dibutuhkan.

• assets/ menyimpan templat, gambar, font, atau bahan keluaran.

Jangan memasukkan semua informasi ke dalam SKILL.md. Claude menggunakan pemuatan bertahap agar konteks tetap efisien.

Pada tingkat pertama, metadata membantu Claude menentukan apakah Skill relevan. Ketika cocok, Claude memuat isi SKILL.md. File referensi atau skrip baru digunakan jika petunjuk utama membutuhkannya.

Simpan aturan inti di SKILL.md, lalu pindahkan contoh panjang, dokumentasi teknis, dan data pendukung ke folder yang sesuai.

Struktur ini memudahkan pemeliharaan. Tim dapat memperbarui definisi metrik tanpa mengubah seluruh prosedur, atau mengganti templat tanpa menyentuh logika pemicu.

Jangan menambahkan file hanya agar folder terlihat lengkap. Skill untuk memformat pembaruan proyek mungkin cukup memakai SKILL.md dan satu templat.

Gunakan skrip ketika hasil dari instruksi bahasa biasa terlalu mudah berubah. Contohnya termasuk validasi format tanggal, pemeriksaan kolom wajib, perhitungan angka, pengubahan nama file, atau pengujian struktur output.

Instruksi seperti “pastikan semua angka benar” terlalu umum. Skrip validasi dapat memeriksa hal yang sama secara lebih pasti.

Step 3: Tulis metadata agar Skill aktif pada waktu yang tepat

Bagian paling atas SKILL.md berisi YAML frontmatter. Metadata ini membantu Claude memahami nama dan tujuan Skill sebelum memuat seluruh isinya.

Baca juga Claude Opus 5: Fitur, Harga, dan Keunggulan Terbaru

Format minimalnya seperti berikut:

---
name: weekly-sales-report
description: Membuat laporan penjualan mingguan dari data yang diberikan. Gunakan saat pengguna meminta laporan penjualan mingguan, ringkasan kinerja regional, perubahan pendapatan, atau weekly sales update.
---

Setelah penutup ---, tulis instruksi utama dalam Markdown.

Kolom name harus ringkas, memakai kebab-case, dan sesuai dengan nama folder. Hindari nama umum seperti helper, business, atau documents karena tidak menjelaskan kemampuan Skill.

Kolom description perlu menjawab dua hal:

1. Apa yang dilakukan Skill?

2. Kapan Skill harus digunakan?

Deskripsi yang terlalu pendek meningkatkan risiko Skill tidak aktif. Deskripsi yang terlalu luas dapat membuatnya aktif pada permintaan yang tidak sesuai.

Bandingkan contoh berikut:

# Terlalu umum
description: Membantu membuat laporan.

# Lebih jelas
description: Membuat laporan status proyek mingguan dengan bagian progres,
rencana, hambatan, risiko, dan keputusan. Gunakan saat pengguna meminta
weekly update, status sprint, ringkasan proyek, atau laporan untuk pemangku kepentingan.

Tambahkan istilah yang benar-benar dipakai oleh pengguna. Jika tim biasa mengatakan “3P update”, “weekly status”, atau “laporan sprint”, masukkan istilah tersebut secara natural.

Kamu dapat menambahkan batas agar Skill tidak terlalu sering aktif:

---
name: contract-summary
description: Merangkum kontrak bisnis dan menandai klausul yang perlu diperiksa. Gunakan untuk ringkasan kontrak, daftar kewajiban, tanggal penting, dan identifikasi klausul. Jangan gunakan untuk surat umum, kebijakan internal, atau saran hukum final.
---

Kalimat negatif tidak menggantikan deskripsi yang jelas, tetapi dapat membantu membedakan dua Skill dengan topik berdekatan.

Metadata opsional dapat menyimpan informasi versi, pembuat, atau kebutuhan lingkungan:

---
name: weekly-sales-report
description: Membuat laporan penjualan mingguan dari data CSV atau XLSX. Gunakan untuk weekly sales update, analisis regional, perubahan pendapatan, dan ringkasan risiko penjualan.
license: MIT
compatibility: Membutuhkan Python 3.11 untuk menjalankan skrip validasi.
metadata:
  author: Tim Revenue Operations
  version: 1.0.0
  category: reporting
---

Jangan menyimpan rahasia di frontmatter. API key, token, kata sandi, dan data pribadi tidak boleh dimasukkan ke dalam folder Skill yang akan dibagikan.

Setelah metadata ditulis, baca kembali dari sudut pandang sistem pencocokan. Jika hanya melihat nama dan deskripsi, apakah kamu dapat menentukan kapan Skill harus dipakai?

Step 4: Susun instruksi yang dapat dijalankan

Isi utama SKILL.md sebaiknya berbentuk prosedur. Gunakan kata kerja yang jelas seperti “periksa”, “hitung”, “kelompokkan”, “tulis”, dan “validasi”.

Contoh struktur dasar:

# Weekly Sales Report

## Tujuan

Buat laporan mingguan yang membantu pimpinan memahami perubahan,
penyebab utama, risiko, dan tindakan berikutnya.

## Input yang dibutuhkan

- Periode laporan
- Data penjualan saat ini
- Data periode pembanding
- Target penjualan
- Catatan perubahan wilayah atau produk

## Prosedur

1. Periksa apakah periode laporan sudah jelas.
2. Validasi kolom wajib pada data.
3. Hitung pendapatan, jumlah transaksi, dan perubahan terhadap pembanding.
4. Kelompokkan temuan berdasarkan wilayah dan produk.
5. Tulis ringkasan eksekutif maksimal 150 kata.
6. Tandai angka yang tidak dapat diverifikasi.
7. Jalankan pemeriksaan kualitas sebelum menyerahkan laporan.

## Format output

Gunakan urutan berikut:

1. Ringkasan eksekutif
2. Metrik utama
3. Perubahan penting
4. Risiko
5. Tindakan yang disarankan
6. Data yang perlu dikonfirmasi

Jelaskan kondisi yang mengharuskan Claude bertanya. Terlalu banyak pertanyaan memperlambat proses, tetapi menebak data penting dapat merusak hasil.

## Kapan meminta klarifikasi

Minta klarifikasi hanya jika:

- Periode laporan tidak diketahui.
- Tidak ada data sumber.
- Mata uang tidak dapat ditentukan.
- Dua sumber memberikan angka yang bertentangan.
- Output akan dibagikan kepada audiens eksternal tetapi status data belum jelas.

Jangan meminta klarifikasi untuk pilihan format kecil.
Gunakan format default yang ditetapkan di bawah.

Tambahkan aturan keputusan untuk situasi yang memiliki beberapa jalur.

## Pemilihan pembanding

- Jika tersedia data minggu sebelumnya, gunakan sebagai pembanding utama.
- Jika minggu sebelumnya tidak tersedia, gunakan rata-rata empat minggu terakhir.
- Jika keduanya tidak tersedia, tampilkan angka saat ini tanpa persentase perubahan.
- Jangan membuat data pembanding.

Instruksi yang baik juga menjelaskan apa yang tidak boleh dilakukan:

## Batasan

- Jangan membuat angka, pelanggan, testimonial, atau penyebab.
- Jangan menyimpulkan hubungan sebab akibat tanpa bukti.
- Jangan menampilkan data pribadi dalam ringkasan.
- Jangan mengubah mata uang tanpa kurs yang diberikan.
- Jangan menyebut asumsi sebagai fakta.

Hindari paragraf panjang yang mencampur banyak aturan. Claude lebih mudah mengikuti petunjuk yang dipisahkan berdasarkan tahap dan prioritas.

Untuk instruksi kritis, letakkan aturan dekat dengan tindakan terkait. Jika validasi data harus dilakukan sebelum analisis, tulis validasi sebagai langkah awal, bukan sebagai catatan di bagian bawah.

Gunakan contoh untuk menunjukkan kualitas, bukan menggantikan aturan. Satu contoh baik dan satu contoh buruk sering kali lebih berguna daripada sepuluh paragraf tentang gaya.

## Contoh ringkasan yang baik

Pendapatan minggu ini naik 8% dibanding minggu lalu.
Pertumbuhan terutama berasal dari wilayah Barat, sedangkan wilayah Timur
turun 3% setelah volume transaksi berkurang. Data diskon untuk dua akun
belum lengkap, sehingga margin bersih masih perlu dikonfirmasi.

## Contoh yang harus dihindari

Penjualan sangat bagus dan menunjukkan momentum luar biasa.
Tim harus terus bekerja keras agar hasil makin maksimal.

Contoh pertama memakai angka dan batas kepastian. Contoh kedua terdengar positif tetapi tidak memberi informasi yang dapat dipakai.

Step 5: Tambahkan referensi, templat, dan skrip seperlunya

Ketika SKILL.md mulai terlalu panjang, pindahkan detail ke file terpisah. Ini menjaga petunjuk inti tetap mudah dibaca dan mengurangi konteks yang dimuat tanpa kebutuhan.

Misalnya, definisi metrik dapat disimpan di references/metric-definitions.md:

# Definisi Metrik

## Revenue

Jumlah nilai transaksi selesai pada periode laporan.
Kecualikan transaksi dibatalkan dan pengembalian dana penuh.

## Conversion Rate

Jumlah transaksi selesai dibagi jumlah peluang yang memenuhi syarat.

## Average Order Value

Revenue dibagi jumlah transaksi selesai.

Lalu arahkan Claude ke file tersebut dari SKILL.md:

Sebelum menghitung metrik, baca `references/metric-definitions.md`.
Gunakan definisi tersebut secara konsisten dan jangan menggantinya
dengan definisi umum.

Tulis kapan file perlu dibaca. Jangan hanya menyebut bahwa folder referensi tersedia.

Tabel berikut dapat membantu menentukan lokasi informasi:

Templat membantu menjaga hasil tetap stabil. Contoh assets/report-template.md dapat berisi:

[Ringkasan maksimal 150 kata]

## Metrik Utama

| Metrik | Nilai | Perubahan | Target | Status |
|---|---:|---:|---:|---|

## Temuan Penting

### Pertumbuhan

[Temuan berdasarkan data]

### Penurunan

[Temuan berdasarkan data]

## Risiko

[Daftar risiko dan dampak]

## Tindakan

[Tindakan, pemilik, dan tenggat jika tersedia]

## Data yang Perlu Dikonfirmasi

[Asumsi, konflik, atau data yang hilang]

Untuk proses deterministik, buat skrip kecil. Contoh berikut memeriksa kolom wajib pada CSV:

# scripts/validate_input.py
import csv
import sys

REQUIRED_COLUMNS = {
    "date",
    "region",
    "product",
    "revenue",
    "transactions",
}

def validate_csv(filename):
    with open(filename, newline="", encoding="utf-8") as file:
        reader = csv. DictReader(file)
        columns = set(reader.fieldnames or [])
        missing = REQUIRED_COLUMNS - columns

        if missing:
            print("INVALID")
            print("Missing columns:", ", ".join(sorted(missing)))
            return 1

        print("VALID")
        return 0

if __name__ == "__main__":
    raise SystemExit(validate_csv(sys.argv[1]))

Jelaskan cara menjalankan skrip dan cara membaca hasilnya:

## Validasi input

Jalankan:

```bash
python scripts/validate_input.py path/to/data.csv

Jika hasilnya INVALID, hentikan analisis dan sebutkan kolom yang hilang. Jika hasilnya VALID, lanjutkan ke perhitungan metrik.

Skrip bukan tempat menyembunyikan tindakan yang tidak dijelaskan. Pengguna atau reviewer harus dapat memahami fungsi kode sebelum menjalankannya.

Jangan memasukkan dependensi besar jika logika sederhana dapat ditulis dengan pustaka bawaan. Semakin banyak dependensi, semakin besar risiko instalasi gagal.

Jika Skill memakai aset merek, jelaskan hak penggunaan dan sumbernya. Jangan membundel font, gambar, atau templat berlisensi tanpa izin.

## Step 6: Uji pemicu dan hasil secara terpisah

Pengujian Skill memiliki dua pertanyaan utama. Pertama, apakah Skill aktif pada permintaan yang tepat? Kedua, apakah Skill menghasilkan pekerjaan yang benar setelah aktif?

Jangan menggabungkan kedua pertanyaan itu dalam satu penilaian. Skill dengan instruksi bagus tetap gagal jika deskripsinya tidak memicu, sedangkan Skill yang mudah aktif dapat memberi hasil buruk jika prosedurnya lemah.

### Uji kapan Skill harus aktif

Siapkan tiga kelompok permintaan:

1. Permintaan yang jelas harus memicu
2. Parafrasa yang seharusnya tetap memicu
3. Permintaan yang tidak boleh memicu

Contoh set pengujian:

```text
HARUS MEMICU
- Buat laporan penjualan mingguan.
- Ringkas hasil penjualan untuk pimpinan.
- Siapkan weekly revenue update.

PARAFRASA YANG HARUS MEMICU
- Apa yang berubah pada penjualan minggu ini?
- Buatkan status regional dari data ini.
- Saya perlu ringkasan performa sales untuk rapat Senin.

TIDAK BOLEH MEMICU
- Tulis email tindak lanjut untuk prospek.
- Buat deskripsi pekerjaan sales manager.
- Jelaskan perbedaan revenue dan profit.

Jalankan pengujian beberapa kali. Pencocokan berbasis bahasa tidak selalu identik pada setiap susunan kata.

Catat hasil dalam tabel:

Jika Skill kurang sering aktif, perbaiki deskripsi dengan istilah pengguna yang lebih nyata. Jika terlalu sering aktif, persempit jenis tugas dan tambahkan batas yang jelas.

Uji kualitas output

Gunakan input yang sama untuk membandingkan hasil dengan dan tanpa Skill. Periksa struktur, ketepatan, konsistensi, jumlah koreksi, dan waktu yang diperlukan.

Buat rubrik sederhana:

Jangan hanya menguji kondisi ideal. Tambahkan data kosong, format salah, nilai ekstrem, file besar, konflik sumber, dan permintaan ambigu.

Contoh kasus tepi:

• CSV tidak memiliki kolom region

• Pendapatan bernilai negatif karena refund

• Dua file memakai mata uang berbeda

• Periode laporan melewati pergantian tahun

• Data hanya tersedia untuk tiga hari

• Nama wilayah tidak konsisten

• Pengguna meminta penyebab yang tidak tercatat

• File mengandung email pelanggan

Skill harus memberi respons yang aman dan berguna pada setiap kondisi. Jika sebuah situasi belum dapat ditangani, lebih baik berhenti dengan alasan jelas daripada melanjutkan memakai asumsi.

Bandingkan dengan baseline

Jalankan tugas tanpa Skill, lalu ulangi dengan Skill. Bandingkan:

• Berapa kali pengguna perlu menjelaskan ulang?

• Berapa banyak pertanyaan klarifikasi yang muncul?

• Apakah struktur hasil berubah?

• Berapa banyak kesalahan yang ditemukan?

• Apakah proses memakai alat yang benar?

• Berapa lama pemeriksaan manual diperlukan?

Tujuan Skill bukan sekadar menghasilkan teks yang lebih panjang. Skill harus mengurangi variasi yang tidak berguna dan membuat proses lebih dapat dipercaya.

Step 7: Periksa keamanan sebelum memasang atau membagikan Skill

Skill dapat menyertakan skrip dan sumber daya yang dijalankan saat diperlukan. Karena itu, perlakukan Skill pihak ketiga seperti kode yang akan dipasang di lingkungan kerja.

Jangan memilih Skill hanya karena jumlah instalasinya tinggi. Direktori seperti SkillsMP atau marketplace komunitas membantu menemukan opsi, tetapi pemeriksaan sumber tetap diperlukan karena koleksinya berasal dari banyak pembuat.

Sebelum memasang Skill pihak ketiga, periksa:

• Identitas pembuat dan riwayat repositori

• Isi lengkap SKILL.md

• Semua file dalam scripts/

• Dependensi yang diminta

• Perintah instalasi

• Akses jaringan

• Lokasi file yang dibaca atau ditulis

• Penggunaan variabel lingkungan

• Lisensi

• Frekuensi pembaruan

• Issue keamanan yang terbuka

Jangan menjalankan skrip dari Skill yang belum diperiksa, terutama jika meminta hak administrator, token pribadi, akses browser, atau akses ke seluruh direktori pengguna.

Cari pola berisiko seperti:

curl example.com/script.sh | bash

Perintah tersebut mengunduh dan menjalankan kode dalam satu langkah, sehingga isi yang dieksekusi lebih sulit ditinjau. Unduh file terlebih dahulu, periksa isinya, lalu jalankan hanya jika sumbernya dipercaya.

Waspadai perintah yang:

• Menghapus folder secara rekursif

• Mengunggah file ke server luar

• Membaca direktori kredensial

• Meminta API key di dalam dokumen

• Mematikan pemeriksaan keamanan

• Mengubah konfigurasi global tanpa kebutuhan

• Memasang banyak paket yang tidak terkait

• Menjalankan kode hasil unduhan tanpa verifikasi

Gunakan izin paling sempit. Jika Skill hanya perlu membaca satu folder proyek, jangan memberinya akses ke seluruh direktori pengguna.

Rahasia sebaiknya disimpan melalui mekanisme variabel lingkungan atau penyimpanan kredensial yang sesuai. Jangan menaruh token di SKILL.md, contoh, log, atau repositori.

Jika Skill membuat perubahan eksternal, bedakan tindakan baca dan tulis. Membaca daftar tugas memiliki risiko berbeda dari menghapus tugas atau mengirim pesan.

Tambahkan konfirmasi untuk tindakan berdampak tinggi:

## Tindakan yang memerlukan konfirmasi

Minta persetujuan sebelum:

- Mengirim pesan atau email
- Menghapus atau menimpa file
- Mengubah data produksi
- Membuat transaksi
- Menerbitkan konten
- Mengubah izin
- Menjalankan migrasi

Ketika membagikan Skill internal, lakukan review kode dan review proses. Orang yang memahami domain perlu menilai prosedur, sedangkan orang yang memahami keamanan perlu memeriksa skrip dan akses.

Panduan resmi pada halaman Claude Skills dapat menjadi titik awal untuk memahami cara Skills dikemas dan digunakan. Detail produk dapat berubah, jadi periksa dokumentasi terbaru sebelum menetapkan prosedur instalasi untuk seluruh tim.

Step 8: Pasang, pantau, dan perbarui Skill

Setelah Skill lulus pengujian dasar, pasang pada lingkungan yang sesuai. Mulai dari penggunaan pribadi atau kelompok kecil sebelum membagikannya ke seluruh organisasi.

Jalankan uji penerimaan dengan tugas nyata. Data uji sintetis penting, tetapi penggunaan sehari-hari sering menemukan istilah, format, dan kondisi yang tidak muncul saat pengembangan.

Catat setiap kegagalan berdasarkan jenisnya:

Skill adalah dokumen hidup. Perbarui ketika proses tim berubah, format sumber berganti, atau kegagalan baru ditemukan.

Gunakan versi agar perubahan dapat dilacak:

metadata:
  author: Tim Revenue Operations
  version: 1.1.0
  updated: 2026-07-27

Terapkan pola versi sederhana:

• Perubahan patch, seperti 1.0.1, untuk perbaikan kecil

• Perubahan minor, seperti 1.1.0, untuk kemampuan baru yang tetap kompatibel

• Perubahan mayor, seperti 2.0.0, untuk alur atau output yang berubah besar

Simpan Skill di Git jika dipakai oleh tim. Version control memungkinkan reviewer melihat perubahan, mengembalikan versi yang rusak, dan membandingkan hasil sebelum serta sesudah revisi.

Struktur repositori dapat dibuat seperti ini:

team-skills/
├── README.md
├── skills/
│   ├── weekly-sales-report/
│   │   ├── SKILL.md
│   │   ├── references/
│   │   └── scripts/
│   └── project-status-update/
│       ├── SKILL.md
│       └── assets/
├── tests/
│   ├── weekly-sales-report/
│   └── project-status-update/
└── CHANGELOG.md

README berada di tingkat repositori untuk pembaca manusia. Folder masing-masing Skill tetap berfokus pada file yang dibutuhkan untuk menjalankan Skill.

Dokumentasikan perubahan penting dalam changelog:

## 1.1.0

- Menambahkan dukungan data multiwilayah.
- Menambahkan pemeriksaan mata uang.
- Memperjelas pemicu "weekly revenue update".
- Menghentikan analisis jika periode tidak tersedia.
- Menambahkan konfirmasi sebelum ekspor eksternal.

Tentukan pemilik Skill. Tanpa pemilik, aturan dapat menjadi usang sementara pengguna tetap menganggapnya benar.

Pemilik bertanggung jawab untuk:

• Meninjau feedback

• Memperbarui proses

• Memeriksa dependensi

• Menangani masalah keamanan

• Menjaga contoh tetap relevan

• Menyetujui rilis baru

• Menghapus aturan yang tidak berlaku

Jika Skill digunakan lintas tim, tetapkan proses perubahan. Perubahan kecil pada definisi metrik atau format laporan dapat memengaruhi banyak hasil.

Publikasikan versi baru secara bertahap. Uji pada beberapa pengguna, bandingkan hasil dengan versi lama, lalu perluas penggunaan setelah tidak ada regresi penting.

Kesalahan umum saat membuat Claude Skill

Memulai dengan ruang lingkup terlalu besar

Kesalahan paling umum adalah membuat satu Skill untuk menangani seluruh fungsi kerja. Instruksinya kemudian dipenuhi banyak cabang, pemicunya menjadi kabur, dan hasilnya sulit diuji.

Perbaikan: pilih satu hasil yang memiliki awal dan akhir jelas. Buat Skill terpisah untuk riset, penulisan, review, dan penerbitan jika setiap proses memiliki aturan sendiri.

Skill kecil dapat digunakan bersama. Beberapa Skill yang terarah biasanya lebih mudah dirawat daripada satu Skill besar dengan ratusan aturan.

Menulis deskripsi tanpa kondisi pemicu

Deskripsi seperti “membantu pekerjaan proyek” tidak memberi cukup petunjuk tentang kapan Skill harus dimuat. Claude mungkin tidak mengaktifkannya atau justru menggunakannya untuk terlalu banyak permintaan.

Perbaikan: sebutkan hasil, konteks, istilah pengguna, dan batas ruang lingkup.

description: Meninjau pull request TypeScript untuk menemukan masalah
ketepatan tipe, penanganan error, duplikasi, dan ketidaksesuaian dengan
pola repositori. Gunakan saat pengguna meminta review PR, review diff,
atau pemeriksaan perubahan TypeScript.

Uji deskripsi dengan parafrasa. Jangan hanya memakai kata yang sama persis dengan nama Skill.

Menulis prinsip tanpa tindakan

Instruksi seperti “buat laporan berkualitas tinggi” atau “ikuti praktik terbaik” tidak menjelaskan tindakan yang harus dilakukan. Hasil akhirnya bergantung pada interpretasi umum dan dapat berubah antarpercobaan.

Perbaikan: ubah prinsip menjadi langkah dan kriteria.

Alih-alih:

Pastikan laporan mudah dipahami.

Gunakan:

Tulis ringkasan eksekutif maksimal 150 kata.
Sebutkan tiga perubahan terbesar berdasarkan dampak.
Jelaskan istilah teknis saat pertama kali digunakan.
Pisahkan fakta, asumsi, dan rekomendasi.

Kualitas yang dapat diperiksa lebih berguna daripada kata sifat.

Memasukkan seluruh pengetahuan ke SKILL.md

File utama yang sangat panjang membuat aturan penting sulit ditemukan. Konteks juga dapat terisi oleh penjelasan yang tidak dibutuhkan untuk tugas saat ini.

Perbaikan: gunakan pemuatan bertahap. Simpan alur inti di SKILL.md, lalu pindahkan dokumentasi, contoh, dan spesifikasi panjang ke references/.

Berikan petunjuk yang jelas tentang kapan referensi dibaca. Folder rapi tidak membantu jika instruksi utama tidak pernah mengarah ke file tersebut.

Mengandalkan bahasa untuk pemeriksaan yang harus pasti

Instruksi bahasa cocok untuk penilaian yang membutuhkan konteks. Namun, perhitungan, validasi skema, dan pemeriksaan format lebih aman dilakukan dengan kode.

Perbaikan: gunakan skrip kecil untuk langkah deterministik. Tulis input, perintah, hasil yang diharapkan, dan tindakan jika skrip gagal.

Jangan berlebihan. Skrip tidak diperlukan untuk setiap aturan gaya atau keputusan editorial.

Hanya menguji happy path

Skill dapat terlihat berhasil ketika input lengkap dan bersih, tetapi gagal saat data kosong, format berubah, atau sumber bertentangan. Kondisi seperti itu justru sering terjadi dalam pekerjaan nyata.

Perbaikan: buat pengujian untuk input rusak, data hilang, permintaan ambigu, dan tindakan berisiko. Pastikan Skill tahu kapan harus berhenti dan kapan harus meminta klarifikasi.

Pengujian negatif juga penting. Verifikasi bahwa Skill tidak aktif untuk tugas yang hanya memiliki kata serupa.

Menginstal Skill komunitas tanpa pemeriksaan

Direktori komunitas memudahkan pencarian, tetapi popularitas bukan jaminan keamanan atau kualitas. Sebuah Skill dapat berisi skrip, dependensi, dan petunjuk yang memberi akses luas.

Perbaikan: baca semua file, periksa riwayat repositori, tinjau dependensi, dan jalankan di lingkungan terbatas. Prioritaskan Skill dari sumber resmi atau pembuat yang dapat diverifikasi.

Jangan menyalin perintah dari artikel pihak ketiga tanpa membuka sumber aslinya. Jumlah Skill, cara instalasi, dan kompatibilitas dapat berubah cepat.

Tidak menetapkan batas tindakan

Skill yang terhubung ke alat eksternal dapat mengirim, menghapus, membeli, menerbitkan, atau mengubah data. Instruksi yang tidak membedakan tindakan aman dan berdampak tinggi meningkatkan risiko kesalahan.

Perbaikan: tulis daftar tindakan yang memerlukan konfirmasi. Gunakan izin paling sempit dan pisahkan tahap persiapan dari eksekusi.

Contohnya, Skill dapat menyiapkan draf email tanpa izin tambahan. Pengiriman email tetap memerlukan persetujuan pengguna.

Menganggap contoh sebagai aturan lengkap

Satu contoh dapat membantu Claude meniru bentuk tertentu, tetapi contoh tidak mencakup semua kondisi. Jika hanya mengandalkan contoh, hasil mungkin mengikuti rincian yang kebetulan ada di sana.

Perbaikan: tulis aturan terlebih dahulu, lalu gunakan contoh untuk memperjelas. Jelaskan bagian mana yang tetap dan bagian mana yang boleh berubah.

Jangan memakai data sensitif dalam contoh. Gunakan data sintetis yang tetap mencerminkan struktur nyata.

Membagikan Skill tanpa versi dan pemilik

Skill yang tidak memiliki versi sulit dilacak ketika hasil berubah. Skill tanpa pemilik juga mudah tertinggal dari proses terbaru.

Perbaikan: simpan metadata versi, changelog, pemilik, dan tanggal peninjauan. Gunakan repositori bersama agar perubahan dapat direview.

Tentukan kapan Skill perlu dihentikan. Proses yang sudah tidak berlaku sebaiknya diarsipkan agar tidak terus memengaruhi pekerjaan.

Mengejar jumlah Skill, bukan manfaat

Marketplace dapat menampilkan ribuan atau jutaan entri dari berbagai repositori. Mengaktifkan banyak Skill sekaligus tidak otomatis membuat hasil lebih baik.

Terlalu banyak Skill yang tumpang tindih dapat memperbesar kemungkinan pemicu salah. Pengguna juga kesulitan mengetahui Skill mana yang memengaruhi hasil.

Perbaikan: mulai dengan tiga sampai lima Skill yang menangani pekerjaan paling sering. Ukur manfaatnya sebelum menambah koleksi.

Nilai Skill berdasarkan perubahan nyata:

• Apakah waktu kerja berkurang?

• Apakah hasil lebih konsisten?

• Apakah kesalahan berulang menurun?

• Apakah anggota baru lebih cepat mengikuti proses?

• Apakah pengguna perlu memberi lebih sedikit koreksi?

• Apakah tindakan berisiko lebih terkendali?

Sebuah Skill sederhana yang dipakai setiap minggu lebih bernilai daripada puluhan Skill yang tidak pernah aktif.

Setelah menyelesaikan struktur dasar, lakukan satu tindakan berikut: pilih tugas yang kamu ulang setiap minggu, buat folder kebab-case dengan SKILL.md, lalu tulis deskripsi yang menjelaskan apa yang dikerjakan dan kapan Skill harus digunakan.

Buat lembar evaluasi untuk setiap versi Skill

Pengujian akan lebih berguna jika hasilnya dicatat dengan format yang sama. Buat satu lembar evaluasi untuk setiap versi, lalu jalankan permintaan uji yang identik sebelum dan sesudah perubahan.

Gunakan tabel sederhana berikut:

Jangan hanya menandai lulus atau gagal. Simpan contoh output, penyebab masalah, dan perubahan yang dilakukan pada SKILL.md. Catatan ini membantu membedakan perbaikan nyata dari hasil yang kebetulan terlihat lebih baik pada satu percobaan.

Untuk Skill yang dipakai tim, minta dua jenis reviewer. Pemilik proses memeriksa ketepatan alur, sedangkan pengguna baru menilai apakah hasil dapat dipahami tanpa penjelasan tambahan.

Gunakan contoh dari repositori resmi Anthropic Skills sebagai pembanding struktur, bukan sebagai templat yang harus disalin utuh. Setiap Skill tetap perlu mengikuti istilah, risiko, dan prosedur milik tim sendiri.

Periksa juga dokumentasi resmi Agent Skills saat cara pemuatan, kompatibilitas, atau distribusi berubah.

Tambahkan pemeriksaan berikut ke setiap rilis:

• Pemicu langsung dan parafrasa sudah diuji.

• Permintaan tidak terkait tidak mengaktifkan Skill.

• Data hilang tidak diganti dengan asumsi.

• Skrip berhasil dijalankan di lingkungan target.

• Tindakan berdampak tinggi meminta konfirmasi.

• Contoh output tidak memuat informasi sensitif.

• Nomor versi dan changelog sudah diperbarui.

Kesimpulan

Claude Skill mengubah prosedur yang berulang menjadi kemampuan yang dapat digunakan kembali. Hasil terbaik datang dari ruang lingkup yang sempit, deskripsi pemicu yang jelas, instruksi yang dapat dijalankan, serta pemisahan rapi antara SKILL.md, referensi, aset, dan skrip.

Skill tetap perlu diuji pada permintaan langsung, parafrasa, input bermasalah, dan topik yang tidak terkait. Pemeriksaan keamanan, pencatatan versi, serta pemilik yang jelas membantu menjaga Skill tetap akurat ketika proses kerja berubah.

Pelajari dokumentasi resmi Agent Skills, lalu pilih satu tugas mingguan yang paling sering kamu jelaskan ulang. Buat versi pertama yang kecil, uji dengan pekerjaan nyata, dan perbaiki berdasarkan kegagalan yang benar-benar ditemukan.

Referensi

Claude. (2026). Skills.

GitHub. (2026). Anthropics/Skills: Public repository for Agent Skills.

Claude. (2026). Introducing Agent Skills.

Artificial Corner. (2026). We Tried 100 Claude Skills: These Are the Best.

SkillsMP. (2026). Agent Skills Marketplace: Codex and Claude Skills.

GitHub. (2026). Alirezarezvani/Claude-Skills: 345 Claude Code Skills and Agent Skills.

Resources. (2026). The Complete Guide to Building Skills for Claude.

Medium. (2026). 10 Must-Have Skills for Claude and Any Coding Agent in 2026.

Claude Marketplaces. (2026). Claude Skills Directory: Browse 23,400+ Claude Code Skills.

Anthropic. (2026). Anthropic Courses.

BrowserAct. (2026). 20 Best Claude Skills in 2026: The List That Actually Helps.