Tiketnya sudah ditulis. Ada judul, deskripsi, kriteria penerimaan, dan tempatnya di sprint. Satu-satunya hal yang menghalanginya dari sebuah diff adalah seseorang yang membuka terminal, menempelkan tiket ke coding agent, mengawasi prosesnya, lalu menyalin hasilnya kembali ke Jira secara manual. Pekerjaan dan catatan pekerjaan itu hidup di dua jendela berbeda, dan menyinkronkannya bisa menghabiskan sepanjang sore seseorang.
Menetapkan tiket Jira ke AI agent berarti menutup celah itu: issue menjadi unit pekerjaan yang bisa diambil agent, dieksekusi terhadap repositori Anda, dan dikembalikan sebagai perubahan yang bisa ditinjau, tanpa harus keluar dari tracker yang sudah dijalankan tim Anda. Anda tidak perlu memindahkan tim dari Jira. Anda hanya menambahkan lapisan tempat tiket itu benar-benar bisa dikerjakan.
Lapisan itu adalah Sharkly, platform command dan manajemen Agent serba-ada. Sharkly terhubung ke Jira, mengubah issue menjadi Task yang bisa ditugaskan, meneruskannya ke coding agent Anda (Claude Code, Codex, Gemini, dan berbagai tool command-line lain), menjalankan masing-masing secara terisolasi, lalu mengembalikan hasilnya ke Task. Panduan ini menelusuri seluruh siklusnya: tiket masuk, Agent ditugaskan, pekerjaan berjalan di worktree terisolasi, pull request dan diskusi kembali tercatat.
Siklusnya dalam satu kalimat
Task Sharkly adalah catatan bersama untuk sebuah unit pekerjaan, dan saat Anda menghubungkan Jira, setiap issue Jira menjadi salah satu Task tersebut. Dari situ kontrak kerjanya sederhana: Agent meneliti, mengeksekusi, menguji, dan melapor; manusia menentukan arah, memberikan wewenang, dan menerima hasilnya. Sisa artikel ini hanyalah mekanisme dari kalimat itu.
Tetap pakai Jira, tambahkan lapisan eksekusi
Sharkly bukan pengganti Jira. Sharkly menambahkan lapisan Task bersama, Computer yang terhubung, eksekusi, dan peninjauan di sekitar tracker yang sudah dipakai tim Anda. Tidak ada yang perlu mempelajari board baru atau memigrasikan backlog untuk memulai.
Anda menghubungkan keduanya dengan sync link. Buka integrasi Jira, sambungkan akun (Jira Cloud menggunakan host *.atlassian.net, email akun, dan token API Atlassian; Server dan Data Center menggunakan base URL, username, dan personal access token), lalu pasangkan satu proyek Jira dengan satu Space Sharkly. Pemetaan intinya sesuai dugaan Anda:
- Issue Jira menjadi Task Sharkly
- Epic Jira menjadi Project Sharkly
- Assignee, status, komentar, dan lampiran ikut terbawa
Inilah dua pilihan yang perlu Anda timbang dengan jujur. Gunakan sync jika Anda ingin proyek yang aktif tetap terhubung, sehingga perubahan mengalir antara Jira dan Sharkly mulai saat itu. Gunakan import jika Anda ingin menyalin issue historis untuk migrasi yang terkendali; sync saja tidak mengisi riwayat masa lalu sebuah proyek. Sebagian besar tim yang baru memulai hanya membutuhkan sync link dua arah pada satu proyek aktif, tidak lebih. Panduan penyiapan lengkapnya, termasuk langkah webhook yang ditangani admin Jira sekali saja, ada di dokumentasi Sharkly.
Tugaskan tiket ke Agent
Setelah proyek tertaut, issue akan muncul sebagai Task di Space tersebut. Menugaskannya ke Agent sama seperti menugaskannya ke rekan kerja: Anda memilih Agent, bukan orang.
Agent bukan sekadar pilihan model. Instruksi, Runtime, repositori, dan pengaturan run-nya menentukan cara ia menangani pekerjaan, sama seperti deskripsi peran membentuk apa yang dilakukan karyawan baru. Runtime adalah mesin di baliknya: Claude Code, Codex, atau CLI agent apa pun yang sudah dijalankan tim Anda. Penggunaan model tetap berjalan melalui langganan atau API key yang dikonfigurasi di tool tersebut, jadi akses agent dan kode Anda tetap berada di hardware Anda sendiri. Sharkly mengoordinasikan penugasan; Sharkly tidak mengambil alih kredensial Anda.
Jika ini run pertama Anda, jaga cakupannya tetap kecil dan batasannya eksplisit. Menulis task yang benar-benar bisa dieksekusi agent adalah keterampilan tersendiri, dan ada baiknya Anda menguasainya sebelum mengarahkan Agent ke hal-hal yang krusial. Tiket yang rapi dengan definisi selesai yang jelas menghasilkan diff yang rapi; tiket yang kabur menghasilkan diff yang kabur juga.
Eksekusi di worktree yang terisolasi
Saat Agent mulai bekerja, run berlangsung di Computer yang terhubung, di dalam worktree terisolasi miliknya sendiri. Isolasi inilah yang membuat cara ini aman untuk diulang. Setiap run mendapat direktori kerja yang baru, sehingga dua Agent yang mengerjakan dua tiket pada repositori yang sama tidak akan saling menimpa file atau berebut branch. Ini disiplin yang sama seperti saat Anda memakai git worktrees untuk AI coding agents secara manual, tetapi sudah ditangani untuk Anda dan bisa diulang di setiap Task.
Ini juga yang membuat alur kerja bisa berkembang melampaui satu tiket. Begitu isolasi berjalan otomatis, menjalankan beberapa agent secara paralel tidak lagi jadi akrobat, karena hal yang biasanya bikin kacau (state yang dipakai bersama di disk) memang sudah dihilangkan sejak desain. Jika Anda masih baru dengan keseluruhan model ini, menugaskan task pertama Anda ke AI agent adalah langkah awal yang lebih ringan sebelum Anda menghubungkan Jira.
Bawa PR kembali ke dalam catatan
Hasil kerja Agent kembali ke Task: percakapan, log eksekusi, hambatan, dan perubahan yang dihasilkan semuanya bermuara di satu tempat, bukan terpencar di terminal dan utas chat. Saat Agent membuka pull request, Anda menghubungkannya ke Task dengan menuliskan ID Task di nama branch, judul PR, atau isi PR. Integrasi GitHub Sharkly mengenali ID tersebut, menautkan pull request ke Task, dan bisa meninggalkan komentar linkback agar siapa pun yang memantau tiket bisa langsung melompat ke kodenya.
Karena sync link Jira bersifat dua arah, aktivitas itu juga terus mengalir ke issue aslinya. Orang yang membuat tiket bisa melihat pekerjaannya bergerak tanpa perlu membuka terminal sama sekali. Inilah manfaat mengarahkan pekerjaan melalui Task bersama alih-alih prompt pribadi: konteks, kemajuan, hambatan, hasil, dan peninjauan semuanya tetap terlihat sejak permintaan sampai rilis.
Batas yang jujur: manusia yang menerima
Tidak ada yang di-merge sendiri. Ini memang disengaja, dan perlu dikatakan secara gamblang karena pembaca mungkin mengira sebaliknya: melakukan merge pull request tidak mengubah status Task, dan itu tidak pernah terjadi secara otomatis. Otomatisasi berhenti di titik yang membutuhkan penilaian tim.
Pembagian kerja ini bertahan sampai akhir. Agent menjalankan pekerjaan, membuka PR, dan melaporkan apa yang dikerjakannya, apa yang diverifikasinya, dan bagian mana yang masih ia ragukan. Manusia membaca diff tersebut terhadap kriteria penerimaan awal, meminta perubahan atau menyetujuinya, lalu mengambil keputusan merge dan rilis. Sebuah agent akan dengan senang hati mengisi kekosongan dengan inisiatifnya sendiri, jadi tahap peninjauan bukan sekadar formalitas; itulah kontrol yang membuat bagian otomatis layak dipercaya. Keputusan akhir penerimaan dan rilis tetap di tangan manusia.
Itulah keseluruhan siklusnya. Sebuah tiket Jira masuk, Agent mengambilnya, pekerjaan berjalan secara terisolasi dan kembali ke catatan sebagai pull request yang bisa Anda baca, lalu Anda yang memutuskan apakah perubahan itu dirilis. Untuk gambaran lebih luas tentang bagaimana hal ini cocok untuk tim yang terdiri dari banyak agent, bukan sekadar satu run, lihat apa arti orkestrasi AI agent bagi tim developer, atau ringkasan Sharkly untuk keseluruhan platform.
Untuk mencobanya pada satu tiket nyata: unduh Sharkly, masuk di app.sharkly.ai, hubungkan sebuah Computer, dan tautkan satu proyek Jira yang berisiko rendah.
Pertanyaan yang sering diajukan
Apakah Sharkly menggantikan Jira? Tidak. Sharkly menambahkan lapisan eksekusi dan peninjauan di sekitar Jira. Issue, epic, status, dan alur kerja Anda tetap di tempatnya; sync link menjaga semuanya tetap terhubung sementara Agent memajukan pekerjaannya.
Versi Jira apa saja yang didukung? Keduanya. Jira Cloud terhubung dengan host, email akun, dan token API Atlassian. Jira Server dan Data Center terhubung dengan base URL, username, dan personal access token.
Apakah saya harus memigrasikan backlog terlebih dahulu? Tidak. Sync link menghubungkan proyek yang aktif dan menjaga perubahan berikutnya tetap mengalir tanpa mengimpor riwayat. Jalankan import terpisah hanya jika Anda memang ingin menyalin issue masa lalu.
Apakah merge pull request akan menutup tiketnya? Tidak. Merge PR tidak mengubah status Task, dan itu memang disengaja. Manusia yang menerima hasilnya dan memutuskan langkah merge dan rilis. Lihat menugaskan task pertama Anda ke AI agent untuk memahami cara kerja siklus peninjauannya.
Di mana kode dan akses model saya berada? Di hardware Anda sendiri. Agent berjalan di Computer yang Anda hubungkan, menggunakan langganan atau API key yang sudah dikonfigurasi di coding tool Anda. Sharkly mengoordinasikan penugasan, konteks, dan peninjauan; Sharkly tidak menghosting repositori atau kuota model Anda.
