Bedah Produk Keren: Apakah openai/skills & Portable Agent Capabilities Layak Diadopsi untuk Stack Production Anda?
Ringkasan: openai/skills adalah repositori (yang kini sudah deprecated) dari OpenAI yang memelopori konsep Portable Agent Capabilities—sebuah standar terbuka untuk memaketkan instruksi, skrip, dan resource menjadi skill modular yang bisa ditemukan dan dieksekusi oleh AI agent seperti Codex. Bagi systems engineer yang sedang membangun arsitektur multi-agent atau sistem tool-calling, repositori ini memberikan blueprint historis yang sangat berharga tentang bagaimana memisahkan logic dari reasoning engine melalui struktur direktori yang deklaratif dan isolasi konteks yang ketat.
Halo semuanya, kembali lagi dengan saya, Doddi Priyambodo, di segmen Cool Products bicarait.com. Hari ini kita akan melakukan teardown pada sebuah repositori yang mungkin secara teknis sudah dilabeli deprecated oleh pembuatnya, namun secara arsitektural menyimpan fondasi dari hampir semua sistem AI agent modern yang kita gunakan saat ini.
Jika kalian pernah membangun sistem berbasis LLM (Large Language Models) yang berinteraksi dengan dunia luar—entah itu memanggil API eksternal, membaca database, atau mengeksekusi script lokal—kalian pasti tahu betapa berantakannya kode yang dihasilkan jika kita tidak memiliki standar. Kita sering kali terjebak dalam spaghetti code berisi if-else statements yang panjang hanya untuk melakukan routing ke tool yang tepat. Di sinilah openai/skills masuk sebagai sebuah studi kasus yang sangat menarik tentang Portable Agent Capabilities. Mari kita bedah bagaimana OpenAI awalnya mendesain sistem plugin dan skill mereka, dan pelajaran engineering apa yang bisa kita ambil untuk stack produksi kita sendiri.
Apa Itu openai/skills & Portable Agent Capabilities & Mengapa Sedang Trending?
Sebelum kita masuk ke dalam kode dan arsitektur, kita harus memahami konteks historis dan masalah fundamental yang coba dipecahkan oleh repositori ini. Di era awal Codex (model AI dari OpenAI yang menjadi cikal bakal GitHub Copilot dan kemampuan coding ChatGPT), para engineer menyadari satu hal: model bahasa yang pintar tidak akan banyak berguna jika ia terisolasi di dalam sandbox teks. Ia butuh tangan dan kaki untuk berinteraksi dengan environment.
Masalahnya, bagaimana cara kita memberikan "tangan dan kaki" ini dengan cara yang scalable? Pendekatan naifnya adalah dengan melakukan hardcode setiap fungsi ke dalam prompt atau backend logic. Namun, pendekatan ini memiliki kelemahan fatal:
- Context Bloat: Memasukkan deskripsi dari puluhan tool ke dalam system prompt akan menghabiskan context window yang berharga (dan mahal).
- Tight Coupling: Logic dari tool terikat erat dengan reasoning engine. Jika kita ingin memperbarui cara kerja sebuah tool, kita harus menyentuh core system dari AI agent tersebut.
- Lack of Portability: Tool yang ditulis untuk satu spesifik agent harness tidak bisa digunakan ulang oleh agent lain.
Untuk mengatasi ini, OpenAI merilis openai/skills. Repositori ini mendefinisikan Agent Skills sebagai sekumpulan folder yang berisi instruksi, skrip, dan resource yang dapat ditemukan (discoverable) dan digunakan oleh AI agent untuk melakukan tugas-tugas spesifik. Filosofi utamanya sangat kental dengan prinsip software engineering klasik: "Write once, use everywhere."
Meskipun di bagian paling atas README-nya terdapat peringatan [!IMPORTANT] bahwa repositori ini sudah deprecated dan pengguna diarahkan untuk menggunakan repositori OpenAI Plugins atau panduan Build plugins terbaru, konsep dasar yang diperkenalkan di sini—yaitu Agent Skills open standard (yang bahkan memiliki domain sendiri di agentskills.io)—adalah cikal bakal dari apa yang sekarang kita kenal sebagai function calling dan Model Context Protocol (MCP).
Repositori ini sempat menjadi tren dan sangat diperhatikan oleh komunitas developer karena ia menawarkan cara yang terstruktur untuk mendistribusikan kemampuan AI. Codex menggunakan skills ini untuk memaketkan kapabilitas sehingga tim dan individu dapat menyelesaikan tugas secara berulang (repeatable way). Alih-alih menulis script Python yang kompleks untuk mengintegrasikan GitHub API dengan LLM, developer cukup menginstal sebuah skill yang sudah dipaketkan dengan rapi. Ini adalah bentuk awal dari package manager khusus untuk AI agent, sebuah konsep yang masih terus disempurnakan oleh industri hingga hari ini.
Bagi saya sebagai seorang systems engineer, melihat repositori ini seperti melihat fosil dari dinosaurus pertama yang berevolusi menjadi burung. Ia menunjukkan transisi dari monolithic prompts menuju modular, declarative tool routing.
Di Balik Layar: Arsitektur & Keputusan Desain
Mari kita bongkar kap mesinnya. Bagaimana sebenarnya openai/skills bekerja dalam mengelola Portable Agent Capabilities? Arsitektur utamanya bertumpu pada struktur sistem file (file-system based registry) dan sebuah CLI harness yang bertindak sebagai installer sekaligus router.
Berikut adalah diagram arsitektur yang merepresentasikan bagaimana skill didistribusikan, diinstal, dan diisolasi di dalam environment Codex:
flowchart LR
subgraph Remote Registry
GH[github.com/openai/skills]
GH_Curated[skills/.curated/]
GH_Exp[skills/.experimental/]
end
subgraph Local Environment
CLI[CLI Harness / User]
Installer[$skill-installer]
subgraph Local Skill Directory
Sys[.system/]
Cur[.curated/]
Exp[.experimental/]
end
Codex[Codex Engine]
end
CLI -- "Executes command" --> Installer
Installer -- "Fetches from URL/Name" --> GH
GH_Curated -. "Downloads" .-> Cur
GH_Exp -. "Downloads" .-> Exp
Sys -- "Auto-loaded" --> Codex
Cur -- "Loaded on restart" --> Codex
Exp -- "Loaded on restart" --> Codex
Codex -- "Discovers & Executes" --> Local_Skills((Agent Skills))
1. Declarative Tool Routing via Directory Structure
Keputusan desain pertama yang paling mencolok adalah penggunaan folder sebagai unit dasar dari sebuah skill. Dalam dokumentasinya, disebutkan bahwa Agent Skills adalah "folders of instructions, scripts, and resources". Ini adalah pendekatan yang sangat deklaratif.
Alih-alih mendaftarkan skill di dalam sebuah database relasional atau file konfigurasi JSON raksasa, sistem ini menggunakan struktur direktori sebagai source of truth. Ketika Codex berjalan, ia akan memindai (scan) direktori tertentu untuk menemukan skill apa saja yang tersedia. Pendekatan ini sangat brilian dalam kesederhanaannya. Ia memungkinkan developer untuk menambah, menghapus, atau memodifikasi skill hanya dengan operasi file system standar (seperti cp, mv, atau rm), tanpa perlu berinteraksi dengan API registri yang kompleks.
2. Tiered Trust Model & Context Isolation
Jika kita melihat struktur foldernya, OpenAI membagi skills ke dalam tiga tier atau tingkatan yang sangat jelas:
.system: Skills yang berada di dalam folder ini secara otomatis diinstal di versi terbaru Codex. Ini adalah core capabilities yang dianggap esensial dan aman..curated: Skills yang telah dikurasi dan diverifikasi, namun bersifat opsional. Pengguna harus menginstalnya secara eksplisit..experimental: Sandbox untuk skills yang masih dalam tahap pengembangan atau belum sepenuhnya stabil.
Pemisahan ini bukan sekadar kosmetik, melainkan sebuah implementasi dari Tiered Trust Model dan Context Isolation. Dalam sistem multi-agent produksi, kita tidak ingin sebuah agent memiliki akses ke semua tool secara bersamaan. Memberikan akses ke tool eksperimental (.experimental) pada agent yang menangani data sensitif di production adalah sebuah mimpi buruk keamanan (security nightmare).
Dengan memisahkan skills ke dalam folder-folder ini, sistem harness dari Codex dapat melakukan isolasi konteks. Agent hanya akan di-inject dengan instruksi dan kapabilitas dari skills yang relevan dengan tier yang diizinkan. Ini secara drastis mengurangi risiko halusinasi LLM (karena context window tidak dipenuhi oleh deskripsi tool yang tidak relevan) dan membatasi blast radius jika terjadi kesalahan eksekusi pada skill yang eksperimental.
3. The $skill-installer Abstraction
Untuk menjembatani antara remote registry (GitHub) dan local environment, arsitektur ini memperkenalkan komponen $skill-installer. Ini adalah sebuah abstraksi yang bertindak layaknya npm atau pip, namun khusus untuk Agent Skills. Installer ini menangani kompleksitas resolusi nama (misalnya, memetakan nama skill ke folder .curated) dan pengunduhan resource dari URL GitHub secara langsung.
Satu detail arsitektural yang penting untuk dicatat dari dokumentasi adalah: "After installing a skill, restart Codex to pick up new skills."
Ini mengindikasikan bahwa sistem ini melakukan eager loading pada saat startup. Codex membaca direktori skills, mem-parsing instruksi di dalamnya, dan memuatnya ke dalam memori (atau system prompt internal) saat inisialisasi. Keputusan desain ini mengorbankan fleksibilitas hot-swapping (kemampuan menambah skill tanpa downtime) demi kesederhanaan implementasi dan performa runtime yang lebih stabil, karena state dari tools yang tersedia sudah immutable selama proses berjalan.
Quickstart Praktis & Bedah Kode
Mari kita lihat bagaimana Developer Experience (DX) dari sistem ini di dunia nyata. Meskipun repositori ini sudah deprecated, perintah-perintah CLI yang didokumentasikan memberikan gambaran yang sangat jelas tentang bagaimana sebuah package manager untuk AI agent seharusnya beroperasi.
Proses instalasi sangat bergantung pada CLI internal yang disebut $skill-installer yang berjalan di dalam environment Codex.
Skenario 1: Menginstal Curated Skill
Untuk skills yang sudah masuk ke dalam kategori .curated, proses instalasinya sangat seamless. Sistem secara default akan mencari nama skill tersebut di dalam direktori skills/.curated.
Misalnya, jika kita ingin menginstal skill untuk menangani komentar di GitHub, kita cukup menjalankan perintah berikut di dalam terminal/harness Codex:
$skill-installer gh-address-comments
Di balik layar, perintah ini akan mengambil folder gh-address-comments dari repositori kurasi dan meletakkannya di direktori lokal yang tepat agar bisa diakses oleh agent.
Skenario 2: Menginstal Experimental Skill via Path
Bagaimana jika kita sedang mengembangkan skill baru atau ingin mencoba skill dari komunitas yang belum masuk kurasi? Kita bisa mengarahkan installer ke folder .experimental. Dokumentasi menunjukkan pendekatan natural language yang menarik untuk CLI ini (mengingat ini adalah CLI di dalam environment AI):
$skill-installer install the create-plan skill from the .experimental folder
Perintah di atas akan mencari skill bernama create-plan secara spesifik di dalam path .experimental. Ini menunjukkan fleksibilitas routing di mana developer bisa secara eksplisit menimpa (override) default path pencarian.
Skenario 3: Menginstal Remote Skill via URL GitHub
Ini adalah fitur yang menurut saya paling powerful dari arsitektur Portable Agent Capabilities. Jika kita ingin mendistribusikan skill tanpa harus melakukan pull request ke repositori utama OpenAI, kita bisa langsung memberikan URL direktori GitHub yang spesifik.
$skill-installer install https://github.com/openai/skills/tree/main/skills/.experimental/create-plan
Fitur ini memungkinkan desentralisasi ekosistem skill. Siapa pun bisa membuat repositori GitHub mereka sendiri, mematuhi Agent Skills open standard, dan membiarkan pengguna Codex menginstal skill tersebut langsung dari URL. Ini sangat mirip dengan cara Go (golang) menangani dependency management berbasis URL repositori.
Post-Installation & Licensing
Satu hal krusial yang ditekankan dalam dokumentasi adalah langkah setelah instalasi:
"After installing a skill, restart Codex to pick up new skills."
Seperti yang saya bahas di bagian arsitektur, ini berarti Anda harus me-restart service atau instance Codex Anda agar agent menyadari keberadaan skill yang baru diunduh.
Selain itu, karena skills ini bersifat modular dan bisa datang dari berbagai sumber, manajemen lisensi ditangani di level per-skill. Dokumentasi menyebutkan:
"The license of an individual skill can be found directly inside the skill's directory inside the LICENSE.txt file."
Ini adalah praktik engineering yang sangat baik. Alih-alih menerapkan satu lisensi monolitik untuk seluruh ekosistem, setiap folder skill memiliki LICENSE.txt sendiri. Ini memungkinkan perusahaan enterprise untuk mencampur skills yang bersifat open-source (MIT/Apache) dengan skills internal yang bersifat proprietary di dalam satu environment tanpa melanggar compliance.
Analisis Jujur Saya: Kapan Harus Menggunakannya (Pro & Kontra)
Sebagai seorang engineer yang sehari-hari berurusan dengan orkestrasi LLM dan integrasi sistem, melihat kembali openai/skills memberikan perspektif yang unik. Meskipun Anda tidak seharusnya menggunakan repositori ini untuk production saat ini (karena sudah digantikan oleh ekosistem openai/plugins dan function calling modern), konsep Portable Agent Capabilities yang ada di dalamnya masih sangat relevan untuk dievaluasi.
Berikut adalah analisis jujur saya mengenai kekuatan dan kelemahan dari pendekatan arsitektur ini.
Pro: Kekuatan Arsitektur "Folder-as-a-Skill"
- Isolasi dan Enkapsulasi yang Sempurna: Saya sangat menyukai pendekatan di mana satu skill sama dengan satu folder. Ini berarti prompt instruksi, script eksekusi (Python/Bash), dan metadata (seperti
LICENSE.txt) hidup berdampingan di satu tempat. Jika saya ingin menghapus sebuah skill, saya cukup menghapus foldernya. Tidak ada database yang harus di-cleanup, tidak ada registry yang out-of-sync. Ini membuat proses debugging menjadi sangat mudah.
- Desentralisasi Distribusi: Kemampuan
$skill-installer untuk mengunduh langsung dari URL GitHub (https://github.com/openai/skills/tree/main/skills/.experimental/create-plan) adalah fitur yang sangat developer-friendly. Ini menghilangkan bottleneck dari centralized app store. Tim internal di perusahaan Anda bisa memiliki repositori GitLab/GitHub private yang berisi skills internal, dan agent bisa langsung menginstalnya dari sana.
- Tiered Governance yang Jelas: Pembagian
.system, .curated, dan .experimental adalah pola desain yang harus ditiru oleh semua framework AI agent modern. Ini memberikan kontrol yang jelas bagi platform engineer untuk menentukan tool mana yang aman dijalankan secara otomatis dan mana yang butuh persetujuan eksplisit.
Kontra: Trade-offs dan Keterbatasan
- Kurangnya Hot-Reloading: Kebutuhan untuk melakukan "restart Codex to pick up new skills" adalah sebuah kelemahan besar untuk sistem terdistribusi modern. Dalam arsitektur microservices atau serverless yang always-on, kita menginginkan kemampuan untuk meng-inject atau mencabut tool dari agent secara dinamis (runtime) tanpa harus me-restart engine utamanya. Pendekatan eager loading ini tidak scalable jika Anda memiliki ribuan skills yang berubah-ubah.
- Ketergantungan pada File System: Menggunakan sistem file lokal sebagai registry memang sederhana, namun ini menjadi masalah ketika kita men-deploy agent di lingkungan containerized (seperti Kubernetes) yang bersifat ephemeral (sementara). Jika pod mati, skills yang diinstal via
$skill-installer di direktori lokal akan hilang kecuali kita mem- mount persistent volume, yang mana menambah kompleksitas infrastruktur.
- Status Deprecated: Tentu saja, kelemahan terbesarnya adalah repositori ini sudah ditinggalkan. OpenAI telah beralih ke standar Plugins dan API Function Calling yang lebih terintegrasi langsung di level model, bukan di level harness eksternal.
Verdict: Di Mana Konsep Ini Cocok dalam Stack Anda?
Jika Anda bertanya kepada saya, "Doddi, apakah saya harus meng-clone repo ini?" Jawaban singkatnya adalah: Tidak. Ikuti saran dari OpenAI dan gunakan panduan Build plugins atau standar Model Context Protocol (MCP) terbaru jika Anda ingin membangun tool untuk LLM saat ini.
Namun, jika Anda sedang merancang framework internal untuk perusahaan Anda—misalnya Anda sedang membangun custom orchestrator menggunakan LangChain, LlamaIndex, atau Go—Anda wajib mempelajari pola desain dari repositori ini.
Saya akan menerapkan konsep dari openai/skills ketika saya perlu membangun sistem multi-agent di mana agent yang berbeda membutuhkan set tools yang berbeda pula. Alih-alih membuat satu god-object yang berisi ratusan tools, saya akan mengadopsi struktur direktori .curated dan .experimental ini untuk memanajemen tools internal tim saya. Konsep Portable Agent Capabilities—di mana tool didefinisikan secara deklaratif, terisolasi, dan portabel antar agent—adalah holy grail dari rekayasa perangkat lunak AI. Repositori ini mungkin sudah mati, tetapi filosofi arsitekturnya akan terus hidup di setiap sistem AI agentic yang kita bangun di masa depan.
Primary References
