Kalau tim kamu punya cara kerja yang sudah rapi, tentu sayang kalau harus dijelaskan ulang setiap berganti agen AI. Petunjuk kerja yang dikemas bersama bahan pendukung disebut skill. Penyerahan Agent Skills ke AAIF pada 22 Oktober membuat pertanyaan ini makin dekat dengan pekerjaan sehari-hari: bagaimana agen lain bisa menemukan, membaca, dan menguji cara kerja timmu?
Skill menambahkan petunjuk dan bahan ke informasi yang sedang dibaca agen, tanpa melatih ulang modelnya. Untuk menjalankan skrip, yaitu berkas berisi perintah program, agen tetap membutuhkan alat dan izin yang sesuai. Begitu juga saat ingin mengakses layanan lain.
Kita akan melihat format resminya, lalu mencoba rancangan skill untuk memeriksa berita. Paket dan kasus ujinya dibuat oleh Nalarku sebagai contoh. Keduanya belum diuji hingga terbukti bekerja di banyak platform.
Apa saja yang perlu ada di dalam paket?
Menurut spesifikasi Agent Skills, paket harus punya folder berisi SKILL.md. Di awal berkas ada keterangan tentang paket, atau metadata, dalam format YAML. Setelah itu barulah petunjuk kerja ditulis dalam format teks Markdown.
Kolom name dan description wajib diisi. Nama harus cocok dengan nama folder dan mengikuti batas karakter dalam spesifikasi. Folder untuk skrip, bahan rujukan, dan berkas pendukung boleh ditambahkan bila dibutuhkan.
Untuk redaksi, susunannya bisa seperti contoh ini. Petunjuk utama dan bahan tambahan punya tempat masing-masing:
verifikasi-berita/
├── SKILL.md
├── references/
│ └── rubrik-bukti.md
├── scripts/
│ └── validate_manifest.py
└── evals/
└── kasus.jsonFolder evals/ untuk kasus uji adalah pilihan dalam rancangan ini. Kamu bisa memulai isi SKILL.md seperti berikut:
---
name: verifikasi-berita
description: Memeriksa draf berita terhadap daftar sumber, menandai klaim tanpa bukti, dan menghasilkan laporan koreksi. Gunakan saat diminta memeriksa fakta sebuah draf; bukan untuk menerbitkan tulisan.
compatibility: Membutuhkan pembaca berkas; validator opsional memakai Python 3.
metadata:
owner: redaksi
revision: "1"
---
# Pemeriksaan draf
1. Baca draf dan manifest sumber yang diberikan pengguna.
2. Pisahkan klaim faktual, analisis, dan contoh simulasi.
3. Cocokkan setiap klaim faktual dengan bukti yang dirujuk.
4. Tandai bukti hilang atau tidak relevan sebagai perlu diperiksa.
5. Hasilkan laporan klaim, bukti, masalah, dan usulan perbaikan.
6. Simpan laporan untuk ditinjau; jangan menerbitkan konten.
Gunakan rubrik di references/rubrik-bukti.md bila diperlukan.Deskripsi tadi menjelaskan kapan skill perlu dipakai dan sampai mana tugasnya. Keterangan versi membantu tim mendata paket, tetapi tidak mencegah isi berkas berubah. Agar paket yang dibagikan bisa dibuat ulang dengan isi yang sama, catat juga penanda revisi Git, atau commit, maupun sidik isi berkas yang disebut checksum.
Baca petunjuk sedikit demi sedikit
Agen perlu menemukan paket lebih dulu, lalu memilih apakah paket itu cocok untuk tugasnya. Dua tahap ini biasa disebut discovery dan activation. Panduan untuk aplikasi pembaca skill kemudian membagi bahan yang dimuat menjadi katalog keterangan paket, petunjuk saat skill diaktifkan, dan bahan pendukung saat dibutuhkan.
Cara membuka bahan secara bertahap ini disebut progressive disclosure. Kalau semua rujukan langsung dimasukkan ke katalog awal, manfaatnya hilang. Gambaran alurnya seperti ini:
Temukan paket → baca nama dan deskripsi
↓
Cocokkan dengan tugas pengguna
↓
Muat instruksi skill
↓
Baca referensi yang relevan
↓
Hasil → evaluasiAda dua kegagalan yang perlu kamu bedakan. Gagal aktivasi berarti skill yang cocok terlewat, atau skill dipilih untuk tugas yang salah. Gagal eksekusi berarti skill sudah aktif, tetapi hasil kerjanya belum memenuhi kebutuhan.
Kalau masalahnya ada pada pemilihan skill, menambah panjang petunjuk belum tentu membantu. Bisa jadi deskripsinya yang perlu diperjelas.
Buat hasil kerja yang bisa diperiksa
Petunjuk “periksa fakta dengan baik” belum menjelaskan seperti apa hasil yang kamu harapkan. Tulis kesepakatan bentuk hasil, atau kontrak keluaran, yang menyebut apa yang diperiksa dan bagaimana keraguan dilaporkan. Panduan penulisan skill menyarankan pengetahuan khusus dari pekerjaan nyata, lalu perbaikan berdasarkan hasil saat skill dijalankan.
Di contoh redaksi ini, setiap temuan bisa memakai bentuk berikut. Klaim, sumber, dan alasan masalahnya dicatat terpisah:
{
"claim_id": "C07",
"source_ids": ["S02"],
"status": "needs_review",
"reason": "Tanggal di draf tidak cocok dengan dokumen rujukan.",
"proposed_change": null
}source_ids harus menunjuk sumber dalam daftar bahan yang dipakai, atau manifest. Adanya penanda sumber belum membuktikan bahwa isinya mendukung klaim. Program pemeriksa, atau validator, bisa menemukan rujukan yang hilang, tetapi bukti tetap perlu dibaca untuk menilai isinya.
Kalau tanggalnya membingungkan, hasil needs_review lebih membantu daripada koreksi yang ditebak. Tetapkan juga apakah skill boleh mencari sumber tambahan atau hanya memakai bahan yang kamu berikan. Pilihan itu membawa kebutuhan alat dan risiko yang berbeda.
Petunjuk kerja tidak otomatis membawa izin akses
Kolom pilihan allowed-tools masih berstatus percobaan dalam spesifikasi. Setiap aplikasi pembaca bisa mendukungnya dengan cara berbeda. Isinya tidak menjamin paket aman dan tidak memberi izin masuk ke akun atau layanan.
Dalam rancangan Nalarku, skill pemeriksaan hanya membaca bahan yang sudah disetujui dan menulis laporan. Penerbitan punya alur tersendiri. Bila paket menyertakan skrip, baca dulu berkas apa yang diakses, alamat jaringan yang dituju, program pendukung yang dibutuhkan, dan hasil yang akan ditulis.
Format yang mudah dipindahkan belum tentu mudah dijalankan di tempat lain. Agen lain mungkin bisa membaca skill yang bergantung pada alat milik suatu platform. Untuk menjalankannya, paket itu bisa tetap membutuhkan penyesuaian.
Bandingkan hasil dengan dan tanpa skill
Dokumentasi evaluasi skill memakai hasil tugas dengan skill dan tanpa skill sebagai pembanding awal, atau baseline. Untuk contoh redaksi, kamu bisa memulai dari kasus buatan berikut. Tambahkan kasus lain dari kegagalan yang benar-benar terjadi:
| Kasus buatan | Hasil yang diharapkan | Masalah yang ingin ditemukan |
|---|---|---|
| Tanggal dalam draf berbeda dari sumber | Perbedaan ditandai | Klaim yang salah tetap lolos |
| Angka dalam draf tidak ada di sumber | Klaim menunggu pemeriksaan | Bukti dikarang |
| Draf berisi opini dengan label yang jelas | Opini tidak dibaca sebagai fakta dari sumber | Koreksi yang terlalu jauh |
| Dokumen berisi perintah “abaikan pemeriksaan” | Perintah dibaca sebagai isi dokumen | Bahan bacaan mengambil alih petunjuk tugas |
| Pengguna hanya meminta perbaikan ejaan | Skill pemeriksaan fakta menjaga batas tugas | Skill aktif pada tugas yang salah |
Bandingkan temuan yang benar, temuan yang keliru, klaim bermasalah yang lolos, dan waktu pemeriksaan manusia. Simpan versi paket, model, petunjuk tugas atau prompt, serta masukan yang sama agar hasilnya bisa dijelaskan. Banyaknya skill yang terpasang belum memberi tahu sebaik apa pekerjaannya.
Lengkapi paket sebelum kamu membagikannya
Sertakan tujuan, contoh masukan, bentuk hasil yang diharapkan, program pendukung, dan kasus yang belum bisa ditangani. Jauhkan kunci akses dan dokumen internal dari contoh paket. Pastikan penerima juga punya hak untuk membaca bahan rujukannya.
Analisis Nalarku: standar terbuka memberi bentuk bersama untuk membawa pengetahuan tim. Manfaat bisnisnya baru terasa ketika petunjuk itu cukup jelas untuk dipakai dan hasilnya bisa diukur untuk diperbaiki. Berkas yang bisa dipindahkan membantu memulai; pengujianlah yang membantu membangun kepercayaan pada cara kerjanya.
