# 10 Keterampilan Agen Terbaik untuk Codex untuk Meningkatkan Alur Kerja Anda
> Temukan keterampilan Codex terbaik untuk merencanakan proyek, men-debug pipeline CI yang gagal, menguji aplikasi, mengimplementasikan desain, menerapkan proyek web, dan menyederhanakan alur kerja pengembangan sehari-hari.
- Canonical: https://nanoskill.ai/id/blog/best-agent-skills-for-codex
- Markdown: https://nanoskill.ai/id/blog/best-agent-skills-for-codex.md
- Author: Jeff Page
- Published: 2026-06-26T09:09:24.794Z
- Updated: 2026-07-25T04:38:34.299Z
- Language: id
## Pendahuluan
Codex sudah dapat menulis kode, menjelaskan repositori yang tidak dikenal, memperbaiki bug, dan membantu pengembang bergerak lebih cepat. Namun bagi sebagian besar tim, hambatan sebenarnya bukanlah menghasilkan beberapa baris kode.
Melainkan segala sesuatu di sekitar kode.
Merencanakan fitur sebelum implementasi. Memahami CI run yang gagal. Menanggapi komentar pull request. Menguji alur pengguna di browser nyata. Membersihkan dataset. Menulis dokumentasi. Menyiapkan proyek untuk deployment.Inilah alur kerja berulang yang diam-diam menghabiskan waktu berjam-jam setiap minggu. Di situlah Keterampilan Agen menjadi berguna.
Keterampilan Agen memberi Codex cara yang dapat diulang untuk menangani jenis tugas tertentu. Alih-alih menjelaskan ulang persyaratan yang sama di setiap prompt, Anda dapat melengkapi Codex dengan instruksi terstruktur, sumber daya pendukung, dan alur kerja khusus tugas. Hasilnya bukan hanya output yang lebih cepat, tetapi pekerjaan yang lebih konsisten di seluruh perencanaan, pengembangan, pengujian, peninjauan, dan pengiriman.
Dengan keterampilan yang tepat, Codex menjadi lebih dari sekadar asisten koding. Codex dapat bekerja lebih seperti rekan tim yang fokus yang mengetahui bagaimana tim Anda merencanakan fitur, memeriksa kualitas, menganalisis data, dan mengirimkan proyek.
Dalam panduan ini, kita akan melihat Keterampilan Agen terbaik untuk Codex pada tahun 2026, termasuk keterampilan untuk perencanaan produk, alur kerja GitHub, pengujian browser, analisis data, tinjauan keamanan, desain-ke-kode, deployment, dan dokumentasi.Tujuannya bukan untuk menginstal setiap keterampilan yang Anda temukan. Melainkan untuk mengidentifikasi yang paling menghilangkan hambatan berulang dari alur kerja Anda.
## **Sekilas: Keterampilan Agen Terbaik untuk Codex**
Berikut adalah sekilas tentang Keterampilan Agen terbaik untuk Codex dan alur kerja yang paling berguna untuknya.
### Perbandingan Singkat: Keterampilan Agen Terbaik untuk Codex
| Keterampilan | Terbaik Untuk | Apa yang Membantu Codex Lakukan | Apa yang Anda Butuhkan |
| --- | --- | --- | --- |
| Tentukan Tujuan | Kriteria keberhasilan yang jelas | Mengubah permintaan yang tidak jelas menjadi tujuan yang terukur, batasan ruang lingkup, dan langkah verifikasi | Tugas dengan persyaratan yang tidak jelas atau beberapa kemungkinan hasil |
| gh-fix-ci | Memperbaiki pemeriksaan CI yang gagal | Menyelidiki kegagalan GitHub Actions, meninjau log, dan mengusulkan rencana perbaikan yang terfokus | Akses GitHub CLI dan repositori yang menggunakan GitHub Actions |
| gh-address-comments | Umpan balik ulasan PR | Mengumpulkan komentar ulasan, merangkum perubahan yang diminta, dan membantu menangani umpan balik yang dipilih | Pull request GitHub terbuka dan akses GitHub CLI |
| Playwright | Pengujian browser dan debugging UI | Membuka browser nyata, menguji alur pengguna, mengisi formulir, mengklik tombol, dan menangkap tangkapan layar | Proyek web plus lingkungan Node.js dan npm yang berfungsi |
| Praktik Terbaik Keamanan | Pengkodean aman secara default | Meninjau kode untuk risiko keamanan umum dan merekomendasikan pola implementasi yang lebih aman | Basis kode yang didukung, seperti Python, JavaScript/TypeScript, atau Go |
| Implementasi Desain Figma | Alur kerja Figma-ke-kode | Mengonversi tata letak, komponen, dan token desain Figma menjadi panduan implementasi frontend | Akses Figma MCP dan file, frame, atau node yang dipilih |
| Jupyter Notebook | Analisis data dan eksperimen | Membuat dan menyusun notebook untuk penelitian, analisis, tutorial, dan alur kerja yang dapat direproduksi | Dataset, eksperimen, atau alur kerja analisis |
| Pembuat CLI | Alat internal yang dapat digunakan kembali | Membangun alat baris perintah yang tahan lama untuk tugas berulang, API, dan otomatisasi internal | Alur kerja berulang yang layak diubah menjadi alat bersama |
| Vercel Deploy | Pengiriman deployment pratinjau | Menerbitkan proyek web dan menghasilkan URL pratinjau yang dapat dibagikan untuk pengujian dan umpan balik | Proyek web yang dapat di-deploy dan akses Vercel |
| Dokumen OpenAI | Membangun dengan produk OpenAI | Menggunakan dokumentasi resmi OpenAI untuk API, model, SDK, migrasi, dan alur kerja Codex | Tugas pengembangan terkait OpenAI |
### Pilihan Singkat berdasarkan Kasus Penggunaan
- **Mulai di sini jika persyaratan Anda masih samar:**Tentukan Tujuan
- **Mulai di sini jika alur kerja GitHub memperlambat Anda:**gh-fix-ci atau gh-address-comments
- **Mulai di sini jika Anda membangun produk web:**Playwright dan Vercel Deploy
- **Mulai di sini jika Anda bekerja sama dengan desainer:**Implementasi Desain Figma
- **Mulai di sini jika Anda menganalisis data riset atau bisnis:**Jupyter Notebook
- **Mulai di sini jika tim Anda mengulangi tugas manual yang sama:**Pembuat CLI
- **Mulai di sini jika Anda membangun fitur AI dengan OpenAI:**Dokumen OpenAI
- **Mulai di sini jika Anda menginginkan kebiasaan pengembangan yang lebih aman:**Praktik Terbaik Keamanan
Pilihan terbaik bergantung pada titik mana alur kerja Anda paling melambat. Jika Anda sedang membangun produk baru, mulailah dengan keterampilan perencanaan, pengujian, dan penerapan. Jika Anda bekerja di GitHub setiap hari, prioritaskan alur kerja CI, pull request, dan keamanan. Jika pekerjaan Anda melibatkan riset atau data pertumbuhan, keterampilan analisis data dan dokumentasi mungkin memberikan nilai lebih.
## **Keterampilan Agen Codex Terbaik: Ulasan Mendetail**
### **Kriteria Evaluasi Kami**
Kami mengevaluasi keterampilan Codex ini berdasarkan lima faktor praktis:
- **Dampak alur kerja:**Apakah keterampilan tersebut menghilangkan hambatan yang berarti dari pekerjaan pengembangan nyata?
- **Hambatan penyiapan:**Berapa banyak konfigurasi, autentikasi, atau perkakas eksternal yang dibutuhkan?
- **Kontrol dan keamanan:**Apakah keterampilan tersebut menjaga pengguna tetap terkendali sebelum melakukan perubahan kode atau penerapan?
- **Kejelasan cakupan:**Apakah jelas kapan keterampilan tersebut harus digunakan dan kapan tidak?
- **Dapat digunakan kembali:**Dapatkah alur kerja tersebut membantu di berbagai proyek, repositori, atau tim?
Ini adalah penilaian editorial berdasarkan alur kerja, prasyarat, dan kasus penggunaan yang didokumentasikan dari masing-masing keterampilan. Ini bukan skor tolok ukur atau jaminan kualitas keluaran.
### **Tentukan Tujuan: Terbaik untuk Kriteria Keberhasilan yang Jelas**
](https://file.nanoskill.ai/define-goal.png)
**Apa yang dilakukannya:**
Tentukan Tujuan membantu Codex mengubah permintaan yang luas menjadi definisi keberhasilan yang konkret sebelum implementasi dimulai. Alih-alih memperlakukan permintaan seperti “tingkatkan alur pendaftaran” sebagai tugas pengkodean sederhana, ini mendorong pengguna dan agen untuk mengklarifikasi apa yang perlu diubah, apa yang di luar cakupan, bagaimana hasilnya akan diuji, dan kondisi apa yang menunjukkan bahwa pekerjaan telah selesai.
**Mengapa ini menonjol:**
Banyak tugas pengembangan gagal karena target tidak pernah didefinisikan dengan jelas. Kode mungkin berfungsi, tetapi mungkin menyelesaikan masalah yang salah, melewatkan kasus ekstrem yang penting, atau menciptakan putaran revisi lainnya. Tentukan Tujuan memberi Codex titik awal yang lebih kuat dengan memindahkan percakapan dari aktivitas yang samar ke hasil yang terukur.
Ini sangat berguna ketika sebuah tugas melibatkan banyak pemangku kepentingan, persyaratan produk yang tidak jelas, target kinerja, pekerjaan migrasi, atau laporan bug yang perlu diterjemahkan ke dalam kriteria penerimaan yang dapat diuji. Dengan menentukan garis akhir sebelum pengkodean dimulai, tim dapat mengurangi komunikasi bolak-balik yang tidak perlu dan memberi Codex pagar pengaman yang lebih jelas untuk pekerjaan ke depan
**Contoh Tugas:**
“Tingkatkan alur pendaftaran untuk pengguna baru. Tentukan tujuan yang terukur, klarifikasi tindakan pengguna target, identifikasi apa yang termasuk dalam cakupan dan di luar cakupan, usulkan kriteria penerimaan, dan jelaskan bagaimana hasil akhir harus diverifikasi sebelum implementasi dimulai.”
**Terbaik untuk:**
Tim produk, pengembang, dan pimpinan teknis yang menangani permintaan fitur yang ambigu, perbaikan bug, tugas migrasi, atau pekerjaan yang sensitif terhadap kualitas
### **gh-fix-ci: Terbaik untuk Memperbaiki Pemeriksaan CI yang Gagal**
](https://file.nanoskill.ai/gh-fix-ci-skill.png)
**Apa yang dilakukannya:**
gh-fix-ci membantu Codex menyelidiki pemeriksaan GitHub Actions yang gagal pada pull request. Ini dapat memeriksa status alur kerja, meninjau log kegagalan, mengidentifikasi penyebab paling mungkin dari masalah, dan mengusulkan rencana perbaikan yang terfokus sebelum perubahan dilakukan.
**Mengapa ini menonjol:**
Kegagalan CI adalah salah satu sumber hambatan paling umum dalam pengembangan perangkat lunak modern. Seorang pengembang mungkin perlu berpindah-pindah antara log GitHub, keluaran pengujian lokal, file dependensi, perubahan pull request, dan konfigurasi alur kerja hanya untuk memahami mengapa build gagal. gh-fix-ci memberi Codex cara terstruktur untuk mengumpulkan konteks tersebut dan mempersempit masalah.
Keterampilan ini sangat berharga karena memisahkan diagnosis dari implementasi. Daripada langsung membuat perubahan besar, Codex dapat terlebih dahulu menjelaskan apa yang gagal, mengapa kemungkinan besar gagal, dan apa yang harus diperiksa selanjutnya. Ini membuat alur kerja lebih transparan dan memberi pengembang rute yang lebih cepat dari status CI merah ke perbaikan yang terverifikasi
**Contoh Tugas:**
“Periksa pemeriksaan GitHub Actions yang gagal pada pull request ini. Ringkas kemungkinan penyebab utama, identifikasi file atau langkah alur kerja yang terpengaruh, dan usulkan rencana perbaikan aman terkecil sebelum membuat perubahan kode.”
**Paling cocok untuk:**
Tim yang menggunakan GitHub Actions untuk pengujian, build, linting, pemeriksaan tipe, dan validasi pull request.
### **gh-menangani-komentar: Paling Cocok untuk Umpan Balik Tinjauan PR**
](https://file.nanoskill.ai/gh-address-comments-skill.png)
**Apa yang dilakukannya:**
gh-menangani-komentar membantu Codex mengumpulkan dan mengatur umpan balik tinjauan pull request. Ini dapat mengidentifikasi utas tinjauan, meringkas apa yang dibutuhkan setiap komentar, mengelompokkan permintaan terkait, dan membantu pengguna memutuskan komentar mana yang harus menghasilkan perubahan kode.
**Mengapa ini menonjol:**
Tinjauan kode jarang sulit karena satu komentar. Ini menjadi memakan waktu ketika umpan balik tersebar di beberapa peninjau, file, utas, dan diskusi tindak lanjut. Pengembang sering kali perlu membaca ulang komentar secara manual, memutuskan mana yang memerlukan tindakan, memahami maksud di balik setiap permintaan, dan melacak apa yang sudah ditangani.
Keterampilan ini mengubah proses yang terfragmentasi menjadi alur kerja yang lebih mudah dikelola. Alih-alih memperlakukan setiap komentar tinjauan sebagai sama mendesaknya, Codex dapat membantu meringkas umpan balik, memunculkan item yang dapat ditindaklanjuti, dan membuat proses revisi lebih disengaja. Ini sangat berguna untuk pull request yang lebih besar, tim yang bergerak cepat, dan pengembang yang ingin mengurangi peralihan konteks sambil tetap merespons umpan balik peninjau dengan hati-hati
**Contoh tugas:**
“Tinjau semua komentar yang belum terselesaikan pada pull request saat ini. Kelompokkan umpan balik terkait, ringkas apa yang diminta setiap peninjau, identifikasi komentar mana yang memerlukan perubahan kode, dan minta saya untuk mengonfirmasi item yang harus Anda tangani sebelum mengedit cabang.”
**Paling cocok untuk:**
Pengembang yang bekerja di repositori GitHub kolaboratif dengan pull request yang sering dan umpan balik multi-peninjau.
### **Penulis Naskah: Paling Cocok untuk Pengujian Peramban dan Debugging UI**
](https://file.nanoskill.ai/playwright-skill)
**Apa yang dilakukannya:**
Penulis Naskah memberi Codex kemampuan untuk berinteraksi dengan peramban sungguhan dari terminal. Ini dapat membuka halaman, menavigasi alur pengguna, mengisi formulir, mengklik tombol, memeriksa keadaan halaman, menangkap tangkapan layar, dan membantu mereproduksi masalah antarmuka yang sulit dipahami hanya dari kode.
**Mengapa ini menonjol:**
Sebuah fitur dapat melewati pengujian unit dan masih gagal dalam pengalaman produk sebenarnya. Formulir mungkin mengirim secara tidak benar, modal mungkin tidak menutup, tombol mungkin tersembunyi di layar yang lebih kecil, atau halaman mungkin rusak hanya setelah urutan klik tertentu. Ini adalah jenis masalah yang menjadi jelas ketika seseorang berinteraksi dengan produk seperti yang dilakukan pengguna.
Penulis Naskah membantu Codex melampaui penalaran tingkat repositori dan memvalidasi perilaku yang terlihat di lingkungan peramban sungguhan. Itu membuatnya berharga untuk debugging regresi UI, memeriksa alur orientasi, memvalidasi pembayaran atau jalur pendaftaran, dan mengonfirmasi bahwa fitur berfungsi dari perspektif pengguna, bukan hanya dalam kode.
**Contoh tugas:**
“Jalankan aplikasi lokal dan uji alur pendaftaran di peramban sungguhan. Buat akun pengujian, lengkapi bidang yang diperlukan, verifikasi bahwa layar konfirmasi muncul, dan tangkap tangkapan layar serta jejak jika ada langkah yang gagal.”
**Paling cocok untuk:**
Pengembang frontend, tim SaaS, alur kerja QA, dan siapa pun yang membangun produk berbasis peramban.
### **Praktik Terbaik Keamanan: Paling Cocok untuk Pengkodean Aman secara Default**
](https://file.nanoskill.ai/security-best-practices)
**Apa yang dilakukannya:**
Praktik Terbaik Keamanan membantu Codex meninjau kode untuk risiko keamanan umum dan merekomendasikan pola implementasi yang lebih aman. Ini dapat memandu agen untuk berpikir lebih hati-hati tentang validasi input, penanganan rahasia, autentikasi, izin, default yang tidak aman, dan kerentanan tingkat aplikasi yang umum.
**Mengapa ini menonjol:**
Masalah keamanan sering kali dimulai dengan keputusan pengembangan yang tampak biasa: pemeriksaan otorisasi yang hilang, variabel lingkungan yang terekspos, validasi input yang lemah, aturan izin yang terlalu luas, atau penanganan data pengguna yang tidak aman. Masalah ini mudah terlewatkan ketika tim berfokus pada pengiriman fitur dengan cepat.
Kemampuan ini membantu membawa pemikiran keamanan lebih awal ke dalam proses pengembangan. Daripada memperlakukan keamanan sebagai daftar periksa tahap akhir, Codex dapat menggunakan pola implementasi yang lebih aman saat kode sedang ditulis atau ditinjau. Ini sangat berguna untuk tim kecil yang tidak memiliki insinyur keamanan khusus yang meninjau setiap pull request tetapi tetap membutuhkan kebiasaan yang lebih kuat seputar pengembangan yang aman secara default.
**Contoh tugas:**
“Tinjau alur autentikasi dan pembaruan profil pengguna di aplikasi ini untuk risiko keamanan umum. Periksa validasi input, otorisasi, penanganan rahasia, manajemen sesi, dan default yang tidak aman. Rekomendasikan perubahan aman secara default dengan contoh di tingkat kode.”
**Terbaik untuk:**
Startup, pengembang full-stack, pembangun API, dan tim yang bekerja pada aplikasi yang berhadapan dengan pelanggan.
### **Implementasi Desain Figma: Terbaik untuk Alur Kerja Figma ke Kode**
](https://file.nanoskill.ai/figma-implement-design)
**Apa yang dilakukan:**
Implementasi Desain Figma membantu Codex menerjemahkan komponen Figma, layar, tata letak, token desain, dan referensi visual menjadi kode frontend yang siap produksi. Ini memberikan konteks desain terstruktur kepada agen sehingga keputusan implementasi didasarkan pada desain aktual daripada interpretasi visual kasar.
**Mengapa ini menonjol:**
Serah terima desain adalah salah satu sumber gesekan terbesar antara desain produk dan pengembangan frontend. Pengembang perlu memahami spasi, tipografi, perilaku responsif, ikonografi, komponen, status, dan konvensi sistem desain yang ada. Tanpa konteks yang jelas, implementasi dapat menyimpang dari desain yang dimaksud atau memperkenalkan pola UI yang tidak konsisten.
Kemampuan ini membuat serah terima lebih sistematis. Ini mendorong Codex untuk menggunakan kembali komponen dan token desain yang ada jika memungkinkan, mengikuti pola visual lebih dekat, dan memvalidasi keluaran akhir terhadap desain asli. Untuk tim yang bekerja di Figma setiap hari, ini dapat mempersingkat jalur dari persetujuan desain ke implementasi yang lebih halus dan konsisten.
**Contoh tugas:**
“Gunakan bingkai Figma yang dipilih untuk mengimplementasikan halaman dasbor ini di proyek frontend yang ada. Gunakan kembali pustaka komponen dan token desain saat ini jika memungkinkan, cocokkan tata letak dan tipografi sedekat mungkin, dukung perilaku responsif, dan bandingkan halaman akhir dengan desain Figma.”
**Terbaik untuk:**
Tim produk, pengembang frontend, dan desainer yang bekerja dengan sistem desain berbasis Figma.
### **Jupyter Notebook: Terbaik untuk Analisis Data dan Eksperimen**
](https://file.nanoskill.ai/jupyter-notebook)
**Apa yang dilakukan:**
Jupyter Notebook membantu Codex membuat, mengedit, mengatur, dan merapikan ulang notebook untuk analisis data, eksperimen, tutorial, dan alur kerja penelitian yang dapat direproduksi. Ini dapat mendukung struktur notebook yang lebih jelas dengan penjelasan markdown yang dapat dibaca, sel kode yang logis, dan langkah analisis yang lebih disengaja.
**Mengapa ini menonjol:**
Sebuah notebook tidak berguna hanya karena dapat dijalankan. Notebook yang kuat juga harus mudah dipahami, direproduksi, dan diperluas oleh orang lain. Dalam praktiknya, banyak notebook menjadi sulit diikuti karena kode, catatan, eksperimen sementara, dan hasil tercampur tanpa struktur yang jelas.
Kemampuan ini membantu Codex membangun notebook yang lebih dari sekadar buku coretan sekali pakai. Ini dapat mendukung analisis eksplorasi yang lebih bersih, eksperimen yang lebih mudah dipahami, dan notebook gaya tutorial yang lebih baik untuk pengajaran atau berbagi. Itu membuatnya berharga bagi peneliti, analis, tim pertumbuhan, dan siapa pun yang perlu mengubah pekerjaan data menjadi artefak yang dapat digunakan kembali daripada skrip sekali pakai.
**Contoh tugas:**
“Buat notebook Jupyter yang bersih yang menganalisis dataset CSV ini. Sertakan pembersihan data, statistik deskriptif, visualisasi, temuan utama, dan penjelasan markdown untuk setiap langkah. Struktur notebook sehingga peneliti lain dapat menjalankannya dari atas ke bawah.”
**Terbaik untuk:**
Peneliti, analis, pendidik, praktisi machine learning, dan tim yang bekerja dengan eksperimen atau dataset terstruktur.
### **CLI Creator: Terbaik untuk Alat Internal yang Dapat Digunakan Kembali**
](https://file.nanoskill.ai/cli-creator)
**Apa yang dilakukannya:**
CLI Creator membantu Codex membangun alat baris perintah yang tahan lama untuk alur kerja berulang. Alat ini dapat mendukung interaksi API, otomatisasi lokal, operasi internal, pengambilan data, tugas administratif, dan tindakan berulang yang jika tidak akan memerlukan pekerjaan manual melalui browser atau skrip sekali pakai.
**Mengapa ini menonjol:**
Banyak tim berulang kali melakukan tugas yang sama: memeriksa log, mengekspor data, mengunggah file, melakukan kueri sistem internal, menyinkronkan informasi, atau memicu tindakan operasional yang aman. Awalnya, tugas-tugas ini sering ditangani melalui skrip ad hoc atau serangkaian langkah manual tanpa dokumentasi. Seiring waktu, hal itu menciptakan gesekan, inkonsistensi, dan ketergantungan yang tidak perlu pada anggota tim individu.
CLI Creator membantu mengubah pekerjaan berulang menjadi produk internal yang lebih bersih. Daripada memecahkan masalah yang sama setiap minggu, tim dapat membuat antarmuka baris perintah yang dapat digunakan kembali dengan perintah yang lebih jelas, output yang dapat diprediksi, penanganan autentikasi yang lebih aman, dan dokumentasi yang dapat diikuti orang lain. Ini adalah salah satu keterampilan terkuat untuk mengubah Codex dari asisten satu kali menjadi mitra pembangun alat.
**Contoh tugas:**
“Bangun alat CLI yang dapat digunakan kembali yang mengambil catatan pelanggan dari API internal kami berdasarkan alamat email. Sertakan perintah yang jelas, teks bantuan, output JSON, autentikasi berbasis variabel lingkungan, penanganan kesalahan, dan`--dry-run`mode untuk setiap operasi tulis.”
**Terbaik untuk:**
Tim teknik, tim platform, tim operasi, dan pengembang dengan alur kerja internal berulang.
### **Vercel Deploy: Terbaik untuk Mengirimkan Pratinjau Deployment**
](https://file.nanoskill.ai/vercel-deploy-skill)
**Apa yang dilakukannya:**
Vercel Deploy membantu Codex menerbitkan proyek web ke Vercel dan menghasilkan pratinjau deployment yang dapat dibagikan. Ini memberi pengguna URL langsung yang dapat dibuka, ditinjau, diuji, dan dibagikan sebelum proyek dirilis ke produksi.
**Mengapa ini menonjol:**
Sebuah proyek menjadi lebih mudah dievaluasi saat orang dapat berinteraksi dengannya di browser. Pengembangan lokal berguna untuk membangun, tetapi pratinjau deployment memungkinkan rekan tim, klien, desainer, pemangku kepentingan, dan pengguna awal melihat hasilnya dalam konteks.
Keterampilan ini memperpendek jarak antara “kode berfungsi di mesin saya” dan “orang lain dapat mengujinya.” Itu membuatnya sangat berguna untuk portofolio, laman landas, prototipe, dasbor internal, MVP, dan eksperimen SaaS awal. Ini juga mendukung ritme rilis yang lebih aman dengan berfokus pada pratinjau deployment, di mana tim dapat mengumpulkan umpan balik dan menangkap masalah sebelum melanjutkan ke peluncuran produksi penuh
**Contoh tugas:**
“Deploy proyek web saat ini ke Vercel sebagai pratinjau deployment. Verifikasi bahwa build berhasil, kembalikan URL pratinjau, dan jangan buat atau modifikasi deployment produksi.”
**Terbaik untuk:**
Peretas indie, pelajar, tim startup, pengembang produk, dan siapa pun yang membutuhkan tautan pratinjau yang cepat dan dapat dibagikan.
### **OpenAI Docs: Terbaik untuk Membangun dengan Produk OpenAI**
](https://file.nanoskill.ai/openai-docs)
**Apa yang dilakukannya:**
OpenAI Docs membantu Codex menggunakan dokumentasi resmi OpenAI saat bekerja dengan API, model, SDK, migrasi, Agen, dan alur kerja terkait Codex dari OpenAI. Ini mendorong keputusan implementasi yang didasarkan pada dokumentasi pihak pertama terkini daripada tutorial usang atau contoh tidak resmi.
**Mengapa ini menonjol:**
Pengembangan AI berubah dengan cepat. Kemampuan model, parameter API, pola SDK, panduan migrasi, dan rekomendasi produk dapat berkembang lebih cepat daripada banyak tutorial pihak ketiga yang diperbarui. Itu menciptakan risiko nyata bagi pengembang yang menyalin contoh dari posting blog lama atau cuplikan komunitas tanpa memeriksa apakah informasi tersebut masih terkini.
Keterampilan ini memberikan Codex sumber kebenaran yang lebih andal saat bekerja dengan produk OpenAI. Ini sangat berguna untuk pertanyaan implementasi yang bergantung pada dokumentasi terkini, seperti memilih pola API yang tepat, memahami fitur yang didukung, menangani perubahan migrasi, atau mengikuti panduan terbaru untuk Codex dan alur kerja agen.
**Contoh tugas:**
“Hanya dengan menggunakan dokumentasi resmi OpenAI, rekomendasikan pendekatan implementasi terbaik saat ini untuk menambahkan tanya jawab berbasis dokumen ke aplikasi ini. Bandingkan opsi API yang relevan, sebutkan langkah-langkah pengaturan yang diperlukan, jelaskan parameter utama, dan berikan contoh TypeScript minimal.”
**Cocok untuk:**
Pengembang yang membangun dengan API OpenAI, model OpenAI, Agen, Codex, atau fitur produk berbasis AI.
## **Contoh Alur Kerja Keterampilan Codex**
Keterampilan Agen lebih mudah dievaluasi ketika Anda dapat melihat bagaimana mereka mengubah tugas nyata. Daripada hanya mendaftar fitur, contoh berikut menunjukkan apa yang terjadi ketika Codex menerima permintaan produk yang samar dan menggunakan keterampilan terstruktur untuk mengubahnya menjadi hasil yang lebih jelas dan lebih dapat diverifikasi.
### **Alur Kerja 1: Mengubah “Tingkatkan Orientasi” Menjadi Tujuan Produk yang Terukur**
**Skenario:**
Tim SaaS menyadari bahwa banyak pengguna baru membuat akun tetapi pergi sebelum menyelesaikan penyiapan ruang kerja. Permintaan awalnya sederhana: “Tingkatkan alur orientasi.” Namun, permintaan tersebut tidak menentukan metrik target, tenggat waktu, cakupan, atau cara yang jelas untuk membuktikan bahwa pekerjaan berhasil.
**Keterampilan yang digunakan:**
Tentukan Tujuan
**Prompt yang digunakan:**
“Tingkatkan alur orientasi untuk pengguna baru. Tentukan tujuan yang terukur, klarifikasi tindakan pengguna yang menjadi target, identifikasi apa yang termasuk dalam cakupan dan di luar cakupan, usulkan kriteria penerimaan, dan jelaskan bagaimana hasil akhir harus diverifikasi sebelum implementasi dimulai.”
Alih-alih langsung menyarankan perubahan UI atau menulis kode, Codex pertama-tama merumuskan ulang permintaan tersebut sebagai tujuan produk. Codex menetapkan target 30 hari, menetapkan metrik dasar, menetapkan kriteria keberhasilan yang terukur, dan mengidentifikasi bukti yang diperlukan untuk memverifikasi apakah pekerjaan tersebut benar-benar meningkatkan pengalaman orientasi.
](https://file.nanoskill.ai/define-goal-sample1)
Permintaan awal tidak berisi definisi keberhasilan yang terukur. Setelah menerapkan Tentukan Tujuan, Codex mengubahnya menjadi hasil yang spesifik: meningkatkan penyelesaian orientasi dari 42% menjadi setidaknya 55%, sambil mengurangi waktu penyelesaian rata-rata dari 6 menit 30 detik menjadi 5 menit atau kurang.
Ini adalah nilai utama dari keterampilan ini. Ini memindahkan tugas dari “membuat sesuatu menjadi lebih baik” ke tujuan yang dapat diuji, diukur, dan ditinjau setelah rilis.
Codex juga menambahkan empat elemen yang sering hilang dari permintaan yang didefinisikan secara longgar:
- **Kriteria keberhasilan yang jelas:**apa yang harus dicapai tim sebelum pekerjaan dapat dianggap berhasil.
- **Cakupan yang ditentukan:**bagian mana dari pengalaman orientasi yang harus ditingkatkan terlebih dahulu.
- **Bukti verifikasi:**analitik pasca-rilis yang diperlukan untuk mengonfirmasi hasil.
- **Kondisi berhenti-dan-tanya:**situasi di mana Codex harus meminta klarifikasi daripada membuat asumsi.
](https://file.nanoskill.ai/define-goal-sample2)
Bagian penting dari alur kerja ini adalah bahwa Codex tidak menandai tujuan sebagai selesai. Codex dengan benar mengidentifikasi bahwa tujuan tetap terhambat sampai dua hal terjadi: alur orientasi yang direvisi dirilis, dan analitik pasca-rilis mengonfirmasi metrik target menggunakan definisi kejadian dasar yang sama.
Perbedaan itu penting. Keterampilan ini dapat menentukan tujuan, menyiapkan rencana validasi, dan membuat artefak pendukung, tetapi tidak boleh mengklaim keberhasilan tanpa bukti dunia nyata.
**Mengapa alur kerja ini penting:**
Tentukan Tujuan paling berguna ketika sebuah tugas dimulai dengan permintaan yang ambigu, banyak pemangku kepentingan, atau kriteria keberhasilan yang tidak jelas. Ini memberi Codex titik awal yang lebih terdisiplin dan membantu tim menyetujui apa arti “selesai” sebenarnya sebelum implementasi dimulai.
### **Alur Kerja 2: Dari Pemeriksaan CI yang Gagal ke Rencana Perbaikan yang Terfokus**
**Skenario:**
Sebuah pull request gagal dalam pemeriksaan tes otomatis setelah perubahan kode kecil. Pengembang dapat melihat bahwa status CI merah, tetapi masih perlu menentukan apa yang sebenarnya gagal, apakah masalah berasal dari kode atau tes, dan apa perbaikan aman terkecil yang seharusnya.
Dalam contoh ini, tes yang gagal mengharapkan fungsi add(2, 2) mengembalikan 5, sedangkan hasil sebenarnya adalah`4`. Pertanyaan pentingnya bukan hanya bagaimana membuat pemeriksaan lulus. Melainkan apakah implementasinya salah, ekspektasi tesnya salah, atau kegagalan menunjukkan masalah yang lebih luas.
**Skill yang digunakan:**
gh-perbaiki-ci
**Contoh prompt:**
“Periksa pemeriksaan GitHub Actions yang gagal untuk pull request pada cabang saat ini. Ringkas konteks kegagalan, identifikasi akar penyebab yang mungkin, dan usulkan rencana perbaikan aman terkecil. Jangan edit kode atau jalankan ulang alur kerja sampai saya secara eksplisit menyetujui rencana tersebut.”
Daripada langsung mengubah kode, gh-perbaiki-ci menyusun tugas sebagai alur kerja diagnostik yang terkendali. Codex pertama-tama meninjau pemeriksaan yang gagal dan konteks yang tersedia, mengidentifikasi penyebab kegagalan yang mungkin, dan mengusulkan rencana perbaikan minimal. Hanya setelah pengguna mengkonfirmasi rencana tersebut, Codex harus melakukan perubahan, menjalankan tes yang relevan, dan memverifikasi bahwa pemeriksaan pull request kembali hijau.
](https://file.nanoskill.ai/gh-fix-ci-sample)
_Gambar 3. Alur kerja ilustratif berdasarkan Skill gh-perbaiki-ci: Codex bergerak dari pemeriksaan GitHub Actions yang gagal ke rencana perbaikan yang terfokus dan dapat ditinjau._
Dalam contoh ini, sinyal kegagalan jelas. Codex akan menggunakan konteks kegagalan tersebut untuk membedakan antara implementasi yang salah dan tes yang salah. Di sini, fungsi add yang mengembalikan 4 adalah benar. Akar penyebabnya adalah ekspektasi tes, yang secara salah mengharapkan hasilnya 5.
Rencana perbaikan yang dihasilkan sengaja dibuat minimal:
1. Ubah nilai yang diharapkan dalam tes dari 5 menjadi 4.
2. Jalankan tes yang relevan secara lokal.
3. Dorong perubahan yang disetujui dan periksa ulang status pull request.
Langkah terpenting adalah**gerbang persetujuan**. gh-perbaiki-ci tidak dirancang untuk memperlakukan setiap pemeriksaan yang gagal sebagai izin untuk mengedit kode secara otomatis. Ini memisahkan diagnosis dari implementasi: Codex menjelaskan kemungkinan masalah, menyajikan rencana perbaikan yang terfokus, dan menunggu persetujuan pengguna secara eksplisit sebelum memodifikasi cabang.
Setelah disetujui, kondisi akhir yang diharapkan mudah: tes yang dikoreksi lulus secara lokal, dan pemeriksaan pull request kembali hijau.
Alur kerja ini berguna karena membuat perbaikan CI lebih transparan dan kurang reaktif. Daripada meminta Codex untuk “memperbaiki kesalahan” dan berharap yang terbaik, pengembang dapat meninjau analisis kegagalan, mengkonfirmasi ruang lingkup perubahan yang diusulkan, dan menyimpan catatan yang jelas tentang bagaimana masalah diselesaikan.
**Mengapa alur kerja ini penting:**
gh-perbaiki-ci paling berharga untuk tim yang menggunakan GitHub Actions sebagai bagian dari alur kerja pull request mereka. Ini membantu Codex mengubah pemeriksaan yang gagal menjadi urutan terstruktur dari diagnosis, persetujuan, implementasi, dan verifikasi—daripada upaya kotak hitam untuk membuat status CI lulus.
### **Alur Kerja 3: Menguji dan Memverifikasi Alur Pendaftaran yang Rusak di Browser**
**Skenario:**
Halaman pendaftaran mungkin terlihat benar dalam tinjauan kode namun tetap gagal pada saat yang paling penting: ketika pengguna nyata mencoba menyelesaikan alur. Formulir dapat menerima masukan, tombol dapat tampak dapat diklik, dan frontend mungkin tidak menunjukkan kesalahan yang jelas—namun status konfirmasi yang diharapkan mungkin tidak pernah muncul setelah pengiriman.
Dalam skenario ilustratif ini, pengguna membuka halaman pendaftaran ruang kerja, memasukkan nama lengkap, email kerja, dan nama ruang kerja, lalu mengklik**Buat ruang kerja**. Hasil yang diharapkan adalah pesan konfirmasi yang terlihat:**“Ruang kerja dibuat.”**Sebaliknya, alur tampak dikirim tetapi tidak menampilkan status konfirmasi apa pun.
**Alur kerja yang digunakan:**
Pengujian browser dengan Playwright
**Contoh prompt:**
“Buka alur pendaftaran ruang kerja di browser, lengkapi formulir dengan detail yang valid, klik Buat ruang kerja, dan verifikasi bahwa pesan konfirmasi yang terlihat muncul. Jika alur gagal, tangkap bukti browser yang relevan, identifikasi penyebab yang mungkin, dan usulkan perbaikan aman terkecil sebelum mengedit kode.”
Tidak seperti tinjauan kode saja, pengujian peramban memeriksa apa yang benar-benar dialami pengguna. Alur kerja dimulai dengan mereproduksi jalur dari pemuatan halaman hingga pengiriman formulir, lalu membandingkan hasil yang terlihat dengan hasil yang diharapkan dari sisi pengguna.
](https://file.nanoskill.ai/playwright-sample)
_Gambar 4. Alur kerja ilustratif berbasis Playwright: Codex bergerak dari alur pendaftaran yang rusak menuju bukti peramban, persetujuan, dan hasil alur pengguna yang terverifikasi._
Kegagalan awal bukanlah pesan “ada yang salah” yang tidak jelas. Pengujian peramban memiliki ekspektasi yang jelas dari sisi pengguna: setelah pengguna mengirimkan detail pendaftaran yang valid, halaman seharusnya menampilkan pesan konfirmasi**“Ruang kerja dibuat.”**
Namun, hasil yang diamati adalah tidak munculnya status konfirmasi setelah pengiriman. Hal ini memberi Codex kondisi kegagalan spesifik untuk diselidiki alih-alih instruksi umum untuk “perbaiki halaman pendaftaran.”
Perbedaan itu penting. Masalahnya belum tentu bahwa bidang formulir rusak atau data pengguna tidak valid. Sebaliknya, alur kerja menunjukkan bahwa aplikasi menerima masukan valid tetapi gagal merender status sukses setelah pengiriman.
Dari sana, Codex dapat menyusun investigasi menjadi urutan terkendali: periksa status peramban, tinjau bukti kegagalan, identifikasi perilaku UI yang kemungkinan hilang, dan usulkan rencana perbaikan minimal. Dalam kasus ini, perbaikan yang diusulkan sengaja sempit: render status**“Ruang kerja dibuat”**konfirmasi yang terlihat setelah pengiriman formulir yang valid, sambil membiarkan tata letak halaman dan perilaku validasi yang ada tidak berubah.
](https://file.nanoskill.ai/playwright-sample2)
_Gambar 5. Alur kerja pengujian peramban enam langkah: buka alur, reproduksi masalah, periksa bukti peramban, usulkan perbaikan, dapatkan persetujuan, dan verifikasi status akhir yang diharapkan._
Langkah kuncinya adalah gerbang persetujuan. Pengujian peramban seharusnya tidak secara otomatis menjadi pengeditan kode yang tidak terkendali. Codex dapat mengidentifikasi kegagalan dan merekomendasikan perubahan terkecil, tetapi harus menunggu persetujuan pengguna sebelum memodifikasi implementasi.
Setelah perbaikan yang disetujui diterapkan, status akhir yang diharapkan jelas: alur pendaftaran menampilkan pesan konfirmasi, dan pengujian peramban mengembalikan hasil lolos. Ini menciptakan putaran pengembangan yang lebih andal daripada sekadar meminta agen untuk “perbaiki halaman pendaftaran” tanpa bukti apa yang gagal atau konfirmasi bahwa alur pengguna sekarang berfungsi.
Contoh ini adalah alur kerja ilustratif berdasarkan pengujian peramban gaya Playwright. Ini tidak mewakili aplikasi produksi atau uji coba langsung yang telah selesai.
**Mengapa alur kerja ini penting:**
Alur kerja berbasis Playwright sangat berharga bagi tim frontend, produk SaaS, dan proyek apa pun yang pengalaman pengguna yang terlihat sama pentingnya dengan kode itu sendiri. Alur kerja ini membantu Codex memvalidasi interaksi nyata—seperti klik, pengiriman formulir, navigasi, dan status konfirmasi—daripada hanya mengandalkan pemeriksaan kode statis. Hasilnya adalah alur kerja yang menghubungkan keputusan implementasi dengan apa yang benar-benar dilihat dan dilakukan pengguna di peramban.
## **FAQ Tentang Keterampilan Codex**
### **Apa itu Keterampilan Codex?**
Keterampilan Codex adalah alur kerja yang dapat digunakan kembali yang membantu Codex menangani jenis tugas tertentu secara lebih konsisten. Sebuah keterampilan dapat mencakup instruksi, skrip opsional, bahan referensi, dan aset yang memandu Codex melalui proses yang dapat diulang.
Misalnya, satu keterampilan dapat membantu Codex menyelidiki pemeriksaan CI yang gagal, sementara yang lain dapat membantu mengubah permintaan produk yang tidak jelas menjadi tujuan yang terukur. Daripada mengulangi prompt panjang yang sama di setiap percakapan baru, Anda dapat menggunakan keterampilan untuk mempertahankan alur kerja, format output yang disukai, dan aturan penting.
### **Bagaimana cara menginstal Keterampilan Codex?**
Untuk keterampilan yang dikurasi, buka Codex dan gunakan penginstal bawaan.
Misalnya, Anda dapat mengetik:
**$skill-installer gh-fix-ci**
Codex kemudian dapat menginstal keterampilan yang dipilih ke pengaturan lokal Anda. Jika keterampilan tidak segera muncul setelah instalasi, mulai ulang Codex dan coba panggil lagi.
Anda juga dapat meminta penginstal untuk membantu menemukan keterampilan yang relevan. Misalnya:
**$skill-installer**
**Rekomendasikan keterampilan untuk pengujian peramban dan alur kerja GitHub.**
Setelah terinstal, Anda dapat secara eksplisit memanggil skill dengan mengetikkan namanya dengan tanda dolar, misalnya**$gh-fix-ci**atau**$define-goal**.
### **Bisakah saya membuat Skill Codex saya sendiri?**
Ya. Bahkan, skill kustom seringkali lebih berharga daripada koleksi besar skill generik.
Skill kustom yang berguna biasanya dimulai dengan alur kerja yang sudah Anda ulangi. Ini bisa berupa daftar periksa rilis, format tinjauan kode, rutinitas QA browser, proses dokumentasi, atau tugas pelaporan internal.
Codex menyertakan alur kerja Pembuat Skill yang dapat membantu mengubah utas, dokumen, skrip, daftar periksa, atau contoh keluaran yang berguna menjadi skill yang dapat digunakan kembali. Skill kustom biasanya dimulai dengan file`SKILL.md`yang diperlukan dan dapat mencakup referensi, skrip, atau template opsional.
Waktu terbaik untuk membuat skill adalah setelah Anda menyelesaikan suatu tugas sekali dan tahu persis seperti apa hasil yang baik.
### **Apa perbedaan antara Skill Codex dan AGENTS.md?**
Sebuah`AGENTS.md`berisi panduan proyek yang persisten. File ini memberi tahu Codex bagaimana harus bersikap setiap kali bekerja di repositori atau folder tertentu.
Misalnya, sebuah`AGENTS.md`mungkin mengatakan:
- Jalankan rangkaian pengujian sebelum membuka pull request.
- Jangan menambahkan dependensi baru tanpa persetujuan.
- Ikuti pustaka komponen yang ada.
- Dokumentasikan perubahan API publik.
Skill berbeda. Ini adalah alur kerja yang dapat digunakan kembali untuk jenis tugas tertentu.
Misalnya:
- Gunakan gh-fix-ci ketika pemeriksaan GitHub Actions gagal.
- Gunakan skill pengujian browser saat memvalidasi alur pendaftaran.
- Gunakan skill dokumentasi saat menyiapkan catatan rilis.
Cara mudah untuk mengingat perbedaannya adalah:
### **AGENTS.md mendefinisikan aturan tetap. Skill mendefinisikan pekerjaan yang dapat diulang.**
### **Skill Codex mana yang harus dicoba oleh pemula terlebih dahulu?**
Mulailah dengan skill yang memecahkan masalah yang paling sering diulang dalam alur kerja Anda saat ini.
Jika tugas Anda sering dimulai dengan persyaratan yang tidak jelas, mulailah dengan**Tentukan Tujuan**. Ini membantu mengubah permintaan yang luas menjadi hasil yang terukur, batasan lingkup, dan kriteria verifikasi.
Jika Anda menghabiskan banyak waktu di pull request GitHub, coba**gh-fix-ci**atau**gh-address-comments**.
Jika Anda membangun produk web, alur kerja pengujian browser seperti**Playwright**berguna karena membantu memvalidasi apa yang sebenarnya dilihat dan dilakukan pengguna.
Jika Anda bekerja dengan API atau model OpenAI,**Dokumentasi OpenAI**dapat membantu Codex mengandalkan dokumentasi pihak pertama yang terkini daripada contoh yang usang.
Skill pertama terbaik biasanya bukan yang paling canggih. Ini adalah skill yang menghilangkan sumber gesekan berulang dari pekerjaan Anda.
### **Apakah Skill Codex aman untuk diinstal?**
Skill harus diperlakukan seperti otomatisasi atau alat pengembang yang dapat digunakan kembali lainnya: instal dari sumber tepercaya, periksa apa yang dirancang untuk dilakukan, dan pahami akses apa yang diperlukan.
Sebelum menggunakan skill pada proyek nyata, periksa apakah skill tersebut dapat:
- Menjalankan perintah di lingkungan lokal Anda
- Mengakses alat eksternal atau layanan yang terhubung
- Memodifikasi file
- Membuat commit atau pull request
- Memicu deployment
- Membaca dokumentasi proyek atau konfigurasi terkait rahasia
Untuk eksperimen berisiko rendah, mulailah di folder demo atau repositori pengujian terpisah. Saat skill mengusulkan perubahan yang berarti, tinjau rencana sebelum menyetujui edit file, perubahan kode, commit, atau deployment.