Setiap tim engineering memikul lapisan pekerjaan berulang yang tidak pernah direncanakan siapa pun, tetapi ditanggung semua orang. Ada yang menyusun ringkasan standup. Ada yang membaca setiap laporan bug yang masuk lalu mengarahkannya. Ada yang merangkum laporan status hari Jumat dari enam tab berisi data yang berserakan. Tidak ada satu pun yang sulit. Semuanya adalah kerja melelahkan: mudah diprediksi, berulang, dan diam-diam mahal, karena pekerjaan itu jatuh ke tangan siapa pun yang menyadarinya lebih dulu.
Inilah jenis pekerjaan yang ditangani AI Agent dengan baik, asalkan ada sesuatu yang menjalankan Agent pada momen yang tepat tanpa perlu ada orang mengetikkan prompt. Mekanisme pemicu itulah yang disediakan oleh Automations di Sharkly. Automation adalah definisi milik sebuah Space untuk pekerjaan Agent atau Crew yang berulang: instruksi tertulis, penanggung jawab eksekusi, satu atau beberapa pemicu, dan riwayat eksekusi yang bisa Anda periksa.
Intinya bukan mengotomatiskan penilaian. Sharkly sendiri menyatakannya dengan gamblang: otomatisasi berhenti di titik yang membutuhkan pertimbangan tim. Automation bisa menyusun draf ringkasan standup, melakukan pembacaan awal atas sebuah bug, dan merangkum laporan mingguan. Namun tetap manusia yang memutuskan apa yang akan dilakukan tim terhadap semuanya itu. Jika Anda baru mengenal Sharkly, mulailah dari apa itu Sharkly lalu kembali ke sini.
TL;DR
Automation di Sharkly adalah aturan milik sebuah Space yang menjalankan Agent atau Crew dengan serangkaian instruksi tetap setiap kali pemicunya aktif. Ada empat jenis pemicu: jadwal (cron lima kolom dengan zona waktu), perubahan status task, komentar yang memuat frasa tertentu, dan URL webhook rahasia untuk layanan eksternal, plus tombol Run now untuk pengujian manual. Setiap eksekusi tercatat di riwayat eksekusi beserta sumber, hasil, dan alasan kegagalannya, dan Automation dapat dijeda lalu dilanjutkan saat Anda merevisinya. Gunakan Automations untuk pekerjaan berulang yang sudah terdefinisi baik: ringkasan standup, triase bug tahap pertama, laporan berkala. Agent yang membaca dan menyusun draf; manusia yang meninjau hasilnya dan mengambil keputusan.
Apa itu Automation, dan apa yang bukan
Automation menyimpan definisi kecil yang lengkap untuk satu pekerjaan berulang: nama dan instruksi yang menjelaskan tujuan, langkah, batasan, dan hasil yang diharapkan; Space yang memilikinya; penanggung jawab, yaitu Agent atau Crew yang mengerjakan pekerjaan tersebut; prioritas; status Active atau Paused; satu atau beberapa pemicu; serta riwayat eksekusi yang mencatat sumber, hasil, eksekusi Agent, dan alasan kegagalan setiap eksekusi.
Ada dua batasan yang mungkin mengejutkan Anda.
Pertama, Automation tidak membuat Task untuk setiap eksekusi. Ia langsung menjalankan Agent atau Crew. Eksekusinya, output-nya, dan kegagalan apa pun tercatat di riwayat eksekusi Automation, bukan di daftar task Anda, sehingga papan Anda tidak dipenuhi Task buatan mesin setiap pagi pukul sembilan.
Kedua, Automation bukanlah kanvas workflow milik Sharkly. Sebuah Space memiliki dua permukaan otomatisasi: Automations, yaitu satu aturan seperti yang dijelaskan di sini, dan Automation workflow, yaitu kanvas berisi node pemicu dan aksi yang dapat memanggil konektor pihak ketiga. Gunakan Automation ketika satu Agent atau Crew harus menjalankan satu set instruksi sebagai respons atas peristiwa yang dapat diprediksi. Gunakan workflow ketika Anda memerlukan aksi multi-langkah atau lintas aplikasi sebelum Agent dilibatkan.
Karena penanggung jawabnya adalah Agent Sharkly yang utuh, semua yang sudah Anda konfigurasikan pada Agent tersebut tetap berlaku: instruksinya, Runtime, Skills, repositori, dan pengaturan eksekusinya. Jika Anda belum membuatnya, Agents di Sharkly membahas bagaimana konfigurasi kerja yang tersimpan bisa menjadi sesuatu yang dapat digunakan ulang oleh tim. Pada dasarnya, Automation adalah jadwal tetap dengan Agent tersebut.
Empat jenis pemicu
Satu Automation dapat memiliki beberapa pemicu, masing-masing dapat diaktifkan atau dinonaktifkan secara independen. Satu definisi bisa melayani beberapa titik masuk: instruksi triase yang sama dapat dipicu oleh perubahan status dan oleh slash command, tanpa perlu menggandakan apa pun.
| Pemicu | Aktif ketika | Paling cocok untuk | Yang perlu diperhatikan |
|---|---|---|---|
| Jadwal | Sebuah ekspresi cron cocok, pada zona waktu yang dipilih | Pemeriksaan berkala, ringkasan, pengingat, pemeliharaan | Pilihan zona waktu; eksekusi tetap berjalan meski tidak ada yang berubah |
| Perubahan status Task | Sebuah task berpindah ke salah satu status Organization yang dipilih | Antrean penerimaan, tindak lanjut review, triase | Pencocokan berlaku di seluruh Organization, tidak difilter per Space |
| Frasa komentar | Komentar sebuah task memuat frasa yang dikonfigurasi, tanpa membedakan huruf besar/kecil | Perintah sesuai permintaan seperti /triage dari dalam diskusi | Juga memantau seluruh Organization; pilih frasa yang khas |
| Webhook | Layanan eksternal mengirim POST ke URL rahasia | Hasil CI, event GitHub, alert dari sistem lain | URL bersifat rahasia bearer; simpan dan rotasi dengan hati-hati |
Jadwal menggunakan ekspresi cron lima kolom standar dan sebuah zona waktu, dengan preset umum untuk per jam, harian, hari kerja, dan mingguan. Ini adalah pemicu untuk pekerjaan yang harus terjadi karena hari ini Selasa, bukan karena ada sesuatu yang berubah.
Perubahan status Task menjalankan Automation ketika sebuah task berpindah ke salah satu status Organization yang dipilih. Satu detail penting: status adalah definisi Organization yang dapat digunakan ulang, dan pencocokan event saat ini berlaku di seluruh Organization. Jika beberapa Space memakai status "Needs Triage" yang sama, transisi yang cocok di salah satu Space dapat menjalankan Automation Anda. Susun instruksinya agar Agent memverifikasi task pemicu sebelum bertindak.
Frasa komentar memulai eksekusi ketika komentar sebuah task memuat frasa yang dikonfigurasi. Pencocokan tidak membedakan huruf besar/kecil, diperiksa di bagian mana pun dalam komentar, dan juga memantau seluruh Organization. Saran dokumentasinya: pilih slash command yang khas seperti /triage-bug daripada "check", dan pastikan instruksinya memvalidasi task pemicu.
Webhook membuat URL rahasia yang menerima POST dari layanan eksternal. URL lengkapnya ditampilkan saat pemicu dibuat atau dibuat ulang dan tidak dapat dilihat lagi setelahnya, karena secara default URL itu sendiri berfungsi sebagai rahasia bearer. Jika Anda mengonfigurasi signing secret, permintaan juga harus lolos verifikasi tanda tangan, pola yang sama seperti yang digunakan GitHub untuk webhook-nya sendiri. Jauhkan rahasia ini dari source control, dan buat ulang jika sampai terekspos. Untuk melakukan scripting pada Sharkly di luar webhook, lihat Sharkly CLI dan API.
Satu cara lain untuk memulai eksekusi sebenarnya bukan pemicu sama sekali: Run now menjalankan Automation secara langsung, yaitu cara untuk menguji instruksi dan ketersediaan penanggung jawab sebelum mempercayakan pekerjaan itu kepada keempat pemicu.
Apa yang sebenarnya dijalankan oleh Automation
Ketika pemicu aktif, Sharkly menjalankan Agent atau Crew yang ditugaskan dengan instruksi dari Automation tersebut. Instruksi itulah keseluruhan kontraknya, sehingga dokumentasinya sangat spesifik tentang apa yang harus dicantumkan: hasil yang ingin dicapai, input yang harus diperiksa, langkah-langkah yang harus diikuti, di mana hasilnya dicatat, perubahan apa yang diizinkan, dan kapan manusia harus meninjau atau memutuskan.
Poin terakhir itu perlu ditekankan. Automation yang ditulis dengan baik menyebutkan sendiri titik berhentinya. "Buat draf ringkasan dan catat; jangan ubah status task" adalah instruksi yang lebih baik daripada instruksi yang lebih panjang namun membuat batas kewenangannya kabur. Panduan penerapan dari dokumentasi juga sama jelasnya: mulailah dari pekerjaan yang dapat diamati dan dapat dibalik, lalu tinjau beberapa eksekusi sebelum memperluas cakupannya.
Tiga pekerjaan rutin yang layak diotomatiskan lebih dulu
Masing-masing contoh berikut tetap berada pada tingkat kedetailan yang didukung produk: Agent membaca, menyusun draf, dan mencatat; manusia tetap memegang keputusan.
Ringkasan standup harian. Pemicu: jadwal, preset hari kerja, sesuai zona waktu tim. Penanggung jawab: Agent pelaporan yang punya akses baca ke konteks terkait. Instruksi: periksa task pada Sprint yang sedang berjalan, catat apa yang bergerak, apa yang terblokir, dan apa yang menunggu review, lalu catat ringkasan singkat di tempat yang dibaca tim, tanpa mengubah task apa pun. Agent mengerjakan bagian standup yang tidak disukai siapa pun, yaitu merangkai gambaran besarnya, dan standup pun berubah menjadi percakapan tentang dua hal yang butuh penilaian. Jika tim Anda menjalankan ritmenya lewat Sharkly, Sprints menyediakan struktur yang diperiksa Agent.
Triase bug tahap pertama. Pemicu: pemicu status task pada status penerimaan bug Anda, atau pemicu komentar pada frasa khas seperti /triage, atau keduanya. Penanggung jawab: Agent triase yang repositorinya mencakup kode terkait. Instruksi: pastikan task pemicunya benar-benar bug di Space yang dimaksud, baca laporannya, periksa area terkait di codebase, lalu catat bagian apa yang tampaknya tersentuh bug, apakah laporannya sudah cukup untuk ditindaklanjuti, dan usulan prioritas beserta alasannya. Beri rekomendasi; jangan memutuskan. Langkah verifikasi bukan sekadar pelengkap: karena pencocokan status dan komentar berlaku di seluruh Organization, instruksi Anda adalah filter cakupannya. Hasilnya, setiap bug mendapat pembacaan awal yang sama telitinya dalam hitungan menit setelah masuk. Pembagian kerja yang sama juga berlaku ketika pekerjaan datang dari luar Sharkly; lihat bagaimana tiket Jira menjadi pekerjaan seorang Agent.
Laporan berkala. Pemicu: jadwal, preset mingguan. Penanggung jawab: Agent pelaporan sejenis, dengan instruksi yang mencakup rentang waktu lebih panjang: rangkum apa yang selesai, apa yang meleset, dan apa yang terblokir. Bedanya dengan kasus standup hanya pada cakupan dan audiensnya, dan justru itulah alasan pekerjaan ini cocok masuk Automation. Laporan yang selalu ada setiap Jumat dengan kualitas yang konsisten mengalahkan laporan yang lebih bagus tetapi hanya ada saat seseorang punya waktu.
Dari ketiga contoh itu, perhatikan apa yang tidak pernah muncul dalam instruksinya: terima, setujui, rilis, tutup, putuskan.
Riwayat eksekusi, kesehatan, serta jeda dan lanjutkan
Automation yang tidak bisa Anda periksa adalah otomatisasi yang tidak bisa Anda percayai, karena itu setiap eksekusi dicatat. Riwayat eksekusi melaporkan tiap eksekusi sebagai Running, Completed, Failed, atau Skipped, dan detail eksekusinya memungkinkan Anda membuka payload pemicu, eksekusi Agent, output, serta alasan kegagalan yang tercatat. Di atas daftar eksekusi individual, ada sinyal kesehatan yang merangkum kondisi terbaru yang berguna: never tested, running, healthy, skipped, atau needs attention.
Satu catatan batasan perlu ditebalkan di kepala Anda: status Completed menggambarkan eksekusi Automation-nya, bukan jaminan bahwa semua hasil di hilirnya benar. Completed berarti mesinnya bekerja. Apakah ringkasannya akurat atau keputusan triasenya tepat tetap harus dinilai manusia.
Fitur jeda dan lanjutkan hadir tepat untuk momen-momen yang Anda bayangkan. Jeda Automation untuk menghentikan eksekusi baru yang dipicu, sementara Anda merevisi instruksi, pemicu, atau penanggung jawabnya, lalu lanjutkan saat konfigurasinya sudah siap; definisi dan riwayatnya tetap utuh di antaranya. Menghapus adalah satu-satunya cara untuk membuangnya, jadi simpan opsi itu untuk definisi yang riwayat eksekusinya sudah tidak Anda butuhkan. Dan sebelum mengarsipkan sebuah Agent, periksa apakah masih ada Automation yang bergantung padanya.
Sebelum mengandalkan Automation apa pun, dokumentasinya menyarankan daftar periksa singkat: jalankan secara manual dengan Run now, pastikan Agent atau Crew punya akses yang dibutuhkan, periksa eksekusinya beserta outputnya, uji setiap pemicu secara terpisah, gunakan status yang sempit atau frasa komentar yang khas, dan jauhkan rahasia webhook dari source control.
Di mana otomatisasi berhenti
Mudah untuk menyimpulkan bahwa tujuannya adalah pipeline tanpa pengawasan. Bukan itu, dan desain produknya sendiri mengatakan demikian. Automation tidak menyetujui output-nya sendiri, dan setiap eksekusinya dicatat untuk ditinjau.
Jadi aturan keputusan yang jujur adalah ini. Gunakan Automation ketika pekerjaan yang terdefinisi baik dan sama harus dimulai berulang kali atau sebagai respons atas peristiwa yang dapat diprediksi, dan ketika draf pertama yang konsisten lebih baik daripada draf bagus yang hanya sesekali ada. Tugaskan Task langsung ke Agent ketika pekerjaannya bersifat sekali jalan, dan biarkan pekerjaan sepenuhnya di tangan manusia ketika inti pekerjaannya adalah penilaian itu sendiri: keputusan prioritas di bawah tekanan yang saling bertentangan, keputusan penerimaan, apa pun yang membuat "salah secara konsisten" lebih buruk daripada "lambat sesekali".
Mulailah dari yang kecil dan membosankan. Lakukan penyiapan, buat satu Agent pelaporan, tulis satu Automation dengan jadwal hari kerja dan instruksi yang diakhiri "jangan ubah task apa pun", lalu jalankan secara manual sekali. Baca output-nya. Jika berguna, biarkan jadwal yang mengambil alih. Dokumentasi membahas Automations dan kanvas workflow lebih mendalam.
FAQ
Jenis pemicu apa saja yang didukung Automation di Sharkly?
Empat: jadwal yang menggunakan ekspresi cron lima kolom beserta zona waktu, pemicu status task yang aktif ketika sebuah task berpindah ke status Organization yang dipilih, pemicu komentar yang aktif pada frasa yang dikonfigurasi, dan pemicu webhook yang menerima POST di URL rahasia. Satu Automation dapat menggabungkan beberapa pemicu, masing-masing dapat diaktifkan atau dinonaktifkan secara independen, dan Run now memulai eksekusi secara manual untuk pengujian.
Apakah Automation membuat Task setiap kali dijalankan?
Tidak. Automation saat ini langsung menjalankan Agent atau Crew dan tidak membuat Task untuk setiap eksekusi. Eksekusinya, output-nya, dan alasan kegagalan apa pun dicatat di riwayat eksekusi Automation. Jika Anda ingin hasilnya berada di tempat yang dibaca tim, sebutkan hal itu dalam instruksinya.
Apa bedanya Automation dengan Automation workflow?
Keduanya adalah dua permukaan terpisah di dalam sebuah Space. Automation adalah satu aturan: kapan mulai, Agent atau Crew mana yang berjalan, dan instruksi apa yang diikutinya. Automation workflow adalah kanvas berisi node pemicu dan aksi yang dapat memanggil aplikasi pihak ketiga melalui konektor. Gunakan aturan tunggal untuk pemeriksaan berkala dan perintah komentar; gunakan kanvas untuk alur multi-langkah yang melibatkan beberapa aplikasi.
Bisakah Automation menangani triase bug sendiri?
Ia bisa menangani tahap pertama: memverifikasi task pemicu, membaca laporan, memeriksa kode terkait, dan mencatat temuan beserta usulan prioritas. Keputusan triasenya tetap di tangan manusia, dan instruksinya harus menyatakan itu secara eksplisit. Dokumentasi menyarankan memulai dengan pekerjaan yang dapat diamati dan dapat dibalik, lalu meninjau beberapa eksekusi sebelum memperluas cakupannya.
Apa yang terjadi jika eksekusi Automation gagal?
Eksekusi tersebut dicatat sebagai Failed di riwayat eksekusi beserta alasan kegagalannya jika tersedia, dan sinyal kesehatannya berubah menjadi needs attention. Buka detail eksekusi untuk memeriksa payload pemicu, eksekusi Agent, dan output, perbaiki instruksi, pemicu, atau penanggung jawabnya, lalu gunakan Run now untuk memverifikasi perbaikan itu sebelum kembali mempercayai pemicunya.
