Issue Anda sudah ada di GitHub. Begitu juga kode, review pull request, dan aturan branch yang butuh seperempat waktu tim Anda untuk disepakati. Tidak ada yang mau memelihara board kedua agar tetap sinkron dengan yang pertama. Yang kurang adalah cara untuk menyerahkan salah satu issue itu ke coding agent dan mendapatkan kembali pull request yang bisa di-review, tanpa meninggalkan repo asalnya.
Itulah yang dilakukan dengan menghubungkan GitHub ke Sharkly. Sharkly adalah platform komando dan manajemen Agent serba ada: ia mengubah issue GitHub menjadi Task yang bisa ditugaskan, mengarahkannya ke coding agent (Claude Code, Codex, Gemini, atau Runtime apa pun yang tim Anda jalankan), mengeksekusi pekerjaan di sebuah Computer dalam worktree terisolasi, lalu mengembalikan hasilnya sebagai pull request yang Anda review dengan cara biasa. Ada dua hal yang paling penting di sini: siapa yang sebenarnya boleh menyentuh repositori, dan di mana manusia tetap harus memberi persetujuan.
Alurnya dalam satu kalimat
Hubungkan GitHub, tautkan repositori ke sebuah Space, dan issue baru pun menjadi Task. Tugaskan ke sebuah Agent dan kontrak yang sama berlaku di seluruh Sharkly: Agent meneliti, mengeksekusi, menguji, dan melaporkan; manusia me-review diff-nya dan memutuskan apa yang dirilis.
Dua koneksi, dan mengapa keduanya berbeda
Integrasi GitHub punya dua lapisan, dan mencampuradukkannya adalah cara tercepat untuk bingung soal siapa yang bisa melihat apa.
Lapisan pertama adalah koneksi organisasi. Seorang Organization Owner atau Admin membuka Integrations, menemukan GitHub, lalu memasang GitHub App pada repositori yang seharusnya terlihat olehnya. Koneksi inilah yang memungkinkan penautan pull request dan komentar linkback. Anggota juga bisa menghubungkan akun GitHub pribadi, tapi itu hanya mengubah identitas siapa yang muncul pada komentar yang tersinkron, bukan mengubah apa yang sudah dilakukan koneksi organisasi.
Lapisan kedua adalah menautkan salah satu repositori tersebut ke sebuah Space. Setelah itu, issue GitHub baru mulai muncul sebagai Task; issue yang sudah ada tidak diimpor. Sebuah repositori bisa memasok satu Space secara satu arah (perubahan issue mengalir masuk, tidak pernah kembali) atau dua arah (issue dan Task tetap sinkron di kedua arah), dan satu Space hanya bisa memiliki satu repositori dua arah pada satu waktu, jadi pilih dengan hati-hati.
Inilah batas yang sering membuat orang keliru: semua ini bukan cara seorang Agent mendapatkan izin untuk meng-clone kode Anda. Integrasi GitHub mencakup tautan pull request, sinkronisasi issue, dan komentar linkback. Ini tidak memberi Agent mana pun akses baca atau tulis ke repositori.
Berikan akses kode ke Agent secara terpisah
Akses kode adalah konfigurasi terpisah, yang diatur pada Agent atau Space, bukan pada koneksi GitHub. Agent yang tidak memiliki repositori sendiri akan mengikuti konfigurasi Space tempat Task itu berada. Persempit daftar itu pada Agent itu sendiri ketika ia seharusnya hanya menyentuh satu basis kode dari beberapa yang dirujuk oleh sebuah Space.
Apa pun pilihannya, eksekusinya tetap membutuhkan akses Git yang berfungsi di Computer itu sendiri: SSH key, token HTTPS, atau kredensial host yang sudah disiapkan di sana. Koneksi organisasi tidak menyediakan atau menggantikan hal-hal tersebut. Jika sebuah eksekusi tidak bisa meng-clone, itu masalah Computer, bukan pengaturan GitHub App.
Tugaskan issue ke sebuah Agent
Setelah repositori ditautkan, issue GitHub baru masuk sebagai Task (Issue, Bug, Feature, dan Ticket semuanya tipe task yang valid, tergantung apa yang digunakan Space Anda). Menugaskannya ke sebuah Agent sama caranya dengan menugaskannya ke rekan tim: buka kontrol Assignee dan pilih Agent sebagai gantinya.
Agent adalah konfigurasi kerja yang tersimpan, bukan prompt sekali pakai: instruksinya, Runtime, repositori, dan pengaturan eksekusinya membentuk pekerjaan itu, seperti deskripsi peran membentuk apa yang dilakukan karyawan baru. Jika Task mendarat di Backlog, belum ada yang berjalan, itu hanya tempat penampungan. Pindahkan ke status kerja dan Sharkly akan mengirimkan eksekusi begitu Computer dan Runtime siap.
Ketika dua Agent menyentuh repositori yang sama
Inilah bagian yang paling dikhawatirkan tim. Mode default-nya adalah Temporary: setiap Task mendapat direktori terisolasi, dan eksekusi berbasis repositori menyiapkan worktree baru. Dua Agent pada dua issue berbeda di repositori yang sama masing-masing mendapat checkout-nya sendiri, bukan yang dipakai bersama, sehingga mereka tidak bisa saling menimpa berkas atau berebut branch, bahkan pada Computer yang sama. Ini disiplin yang sama seperti menggunakan git worktree dengan AI coding agent secara manual, hanya saja otomatis.
Konkurensi punya batasnya sendiri. Eksekusi Temporary secara default dibatasi sekitar setengah dari batas keseluruhan Computer; naikkan secara manual dan produk akan memperingatkan Anda begitu nilainya melampaui kapasitas direktori yang tersedia, di situlah tabrakan sebenarnya mulai terjadi. Mode Specified juga ada, di mana Agent menggunakan kembali satu direktori tetap alih-alih worktree baru, tapi mode ini melayani satu eksekusi pada satu waktu, kurang cocok untuk repositori yang diakses beberapa Agent sekaligus.
Apa yang kembali: pull request
Ketika Agent membuka pull request, Anda menghubungkannya ke Task dengan menuliskan ID Task ke dalam nama branch, judul, atau body. Salah satu dari ketiganya sudah cukup; ID polos seperti SH-312 berfungsi sama seperti Fixes SH-312, karena tidak ada penanganan khusus untuk kata seperti fixes, closes, atau skip. Pada repositori publik, hanya penulis tepercaya, yaitu owner, member, atau collaborator, yang bisa ditautkan, sehingga pull request dari orang asing tidak bisa memalsukan jalannya ke Task Anda.
Pull request yang tertaut juga bisa mendapat komentar linkback yang mengarah kembali ke Task. Fitur ini aktif secara default untuk repositori privat dan nonaktif secara default untuk repositori publik, sebuah pengaturan yang berlokasi di pengaturan GitHub, terpisah dari apakah Space itu sendiri publik atau privat.
Gerbang review: di sinilah penilaian manusia berada
Menggabungkan pull request tidak mengubah status Task, dan hal itu tidak pernah terjadi sendiri. Itu disengaja. Status Task dan status kerja Agent dilacak secara terpisah, sehingga Task yang berstatus Started juga bisa menampilkan Working, Waiting for human reply, Waiting for human review, atau Error, dan sinyal-sinyal itu muncul di Inbox bagi siapa pun yang bertanggung jawab. Menutup atau membuka kembali issue GitHub yang mendasarinya bisa mengubah status Task dua arah; menggabungkan pull request tidak bisa.
Agent meneliti, mengeksekusi, menguji, dan melaporkan. Manusia membaca diff-nya terhadap issue asli, meminta perubahan atau menerima, dan mengambil keputusan merge dan rilis sendiri. Pembagian itu berlaku sampai akhir, di GitHub sama seperti di seluruh bagian lain Sharkly: otomatisasi berhenti tepat di titik yang membutuhkan penilaian tim. Untuk mekanisme yang lebih mendalam, alur review human-in-the-loop Sharkly membahasnya secara langsung.
Ketika hub agent milik GitHub sendiri sudah cukup
Jika tim Anda sepenuhnya menggunakan GitHub, untuk source, CI, review, dan langganan Copilot berbayar, Agent HQ milik GitHub sendiri mengoordinasikan agent di dalam ekosistem itu dengan baik, dan Anda mungkin tidak butuh yang lain. Alasan untuk beralih ke Sharkly muncul begitu pekerjaan juga melewati Jira, begitu Agent berjalan di Computer di luar cloud GitHub, atau begitu tim Anda mencampur berbagai Runtime dan tidak ingin membangun ulang alur kerjanya setiap kali yang terbaik berubah. Jika Jira termasuk dalam campuran itu, menugaskan tiket Jira ke AI Agent menelusuri alur yang sama dari sisi itu.
Untuk mencobanya pada satu issue nyata: buka integrasi GitHub, Jira, dan Slack Sharkly, hubungkan organisasi GitHub Anda, tautkan satu repositori berlalu lintas rendah ke sebuah Space, dan tugaskan issue kecil berikutnya ke seorang Agent alih-alih ke diri Anda sendiri.
Pertanyaan yang sering diajukan
Apakah menghubungkan organisasi GitHub saya memberi Agent akses ke kode saya? Tidak. Koneksi organisasi mencakup tautan pull request, sinkronisasi issue, dan komentar linkback. Akses kode dikonfigurasi secara terpisah, pada Agent atau Space, dan eksekusinya tetap membutuhkan kredensial Git-nya sendiri di Computer.
Apakah dua Agent yang mengerjakan repositori yang sama bisa bertabrakan? Tidak, dalam mode Temporary default. Setiap eksekusi mendapat worktree terisolasi sendiri, sehingga Agent yang berjalan bersamaan tidak pernah berbagi salinan kerja, bahkan pada Computer yang sama.
Apakah menggabungkan pull request akan menutup issue GitHub atau Task-nya? Menggabungkan tidak pernah mengubah status Task dengan sendirinya. Menutup issue GitHub yang mendasarinya bisa, pada repositori yang tersinkron dua arah, tapi itu tindakan yang terpisah dari menggabungkan PR.
Sebenarnya pull request milik Agent menargetkan apa? Sharkly menautkan pull request berdasarkan ID Task di branch, judul, atau body, mana pun yang ditulis oleh Runtime Anda. Sharkly tidak menetapkan strategi branch, jadi pastikan perilaku base-branch default Runtime Anda sebelum menugaskan apa pun yang taruhannya lebih tinggi daripada issue uji coba.
Bisakah saya mempertahankan issue GitHub saya yang sudah ada, bukan hanya yang baru? Menautkan repositori menyinkronkan issue yang baru dibuat ke depannya. Issue yang sudah ada tidak diimpor secara otomatis.
