Issue'larınız zaten GitHub'da yaşıyor. Kod, pull request incelemesi ve ekibinizin bir çeyrek boyunca üzerinde anlaştığı branch kuralları da orada. Kimse birincisiyle senkron tutulacak ikinci bir pano istemez. Eksik olan şey, bu issue'lardan birini bir kodlama ajanına verip, geldiği repodan çıkmadan incelenebilir bir pull request geri almanın bir yolu.
GitHub'ı Sharkly'ye bağlamak tam da bunu yapıyor. Sharkly, hepsi bir arada bir Agent komuta ve yönetim platformudur: bir GitHub issue'sunu atanabilir bir Task'a dönüştürür, onu bir kodlama ajanına yönlendirir (Claude Code, Codex, Gemini veya ekibinizin çalıştırdığı herhangi bir Runtime), işi izole bir worktree içindeki bir Computer üzerinde yürütür ve sonucu normal şekilde incelediğiniz bir pull request olarak geri döndürür. Burada en çok önem taşıyan iki şey var: repoya gerçekte kimin dokunabildiği ve bir insanın hâlâ nerede onay vermesi gerektiği.
Tek cümlede döngü
GitHub'ı bağlayın, bir repoyu bir Space'e bağlayın; yeni bir issue bir Task haline gelir. Onu bir Agent'a atayın ve Sharkly'nin her yerinde aynı sözleşme geçerlidir: Agent araştırır, yürütür, test eder ve raporlar; bir kişi diff'i inceler ve neyin yayına gideceğine karar verir.
İki bağlantı ve neden aynı şey olmadıkları
GitHub entegrasyonunun iki katmanı vardır ve bunları karıştırmak, kimin neyi görebildiği konusunda kafanızın karışmasının en hızlı yoludur.
İlk katman organizasyon bağlantısıdır. Bir Organization Owner veya Admin, Integrations'ı açar, GitHub'ı bulur ve GitHub App'i görmesi gereken repolara kurar. Pull request bağlantılandırmayı ve linkback yorumlarını mümkün kılan bu bağlantıdır. Üyeler ayrıca kişisel bir GitHub hesabı da bağlayabilir, ancak bu yalnızca senkronize yorumlarda hangi kimliğin görüneceğini değiştirir; organizasyon bağlantısının zaten yaptıklarını değil.
İkinci katman, bu repolardan birini bir Space'e bağlamaktır. Bunu yaptığınızda yeni GitHub issue'ları Task olarak görünmeye başlar; mevcut issue'lar içe aktarılmaz. Bir repo bir Space'i tek yönlü besleyebilir (issue değişiklikleri içeri akar, asla geri dönmez) veya iki yönlü (issue'lar ve Task'lar her iki yönde senkron kalır) ve bir Space aynı anda yalnızca bir iki yönlü repo alır; bu yüzden dikkatli seçin.
İnsanların ayağına takılan sınır şu: bunların hiçbiri bir Agent'ın kodunuzu klonlama iznini aldığı yol değildir. GitHub entegrasyonu pull request bağlantılarını, issue senkronizasyonunu ve linkback yorumlarını kapsar. Hiçbir Agent'a bir repoya okuma veya yazma erişimi vermez.
Agent'a kod erişimini ayrıca verin
Kod erişimi, GitHub bağlantısında değil, Agent veya Space üzerinde ayarlanan ayrı bir yapılandırmadır. Kendi reposu olmayan bir Agent, Task'ın Space'inin yapılandırıldığı şeye geri döner. Bir Space'in başvurduğu birkaç kod tabanından yalnızca birine asla dokunmaması gerektiğinde, bu listeyi Agent'ın kendisinde daraltın.
Her iki durumda da çalıştırma, Computer'ın kendisinde çalışan Git erişimine ihtiyaç duyar: bir SSH anahtarı, bir HTTPS token'ı veya orada zaten kurulmuş host kimlik bilgileri. Organizasyon bağlantısı bunları sağlamaz veya değiştirmez. Bir çalıştırma klonlayamıyorsa, bu bir GitHub App ayarı değil, bir Computer sorunudur.
Issue'yu bir Agent'a atayın
Bir repo bağlandıktan sonra, yeni bir GitHub issue'su bir Task olarak düşer (Issue, Bug, Feature ve Ticket'ın tümü geçerli task türleridir; Space'iniz hangisini kullanıyorsa). Onu bir Agent'a atamak, bir ekip arkadaşına atamakla aynı şekilde çalışır: Assignee kontrolünü açın ve bunun yerine Agent'ı seçin.
Bir Agent, tek seferlik bir prompt değil, kaydedilmiş bir çalışma yapılandırmasıdır: talimatları, Runtime'ı, repoları ve çalıştırma ayarları işi şekillendirir; tıpkı bir rol tanımının yeni bir işe alımın ne yapacağını şekillendirmesi gibi. Task Backlog'a düşerse henüz hiçbir şey çalışmaz; orası bir bekleme alanıdır. Onu çalışan bir duruma taşıyın ve bir Computer ile Runtime hazır olduğunda Sharkly çalıştırmayı gönderir.
İki Agent aynı repoya dokunduğunda
Ekiplerin en çok endişelendiği kısım burasıdır. Varsayılan mod Temporary'dir: her Task izole bir dizin alır ve repo destekli çalıştırmalar yeni bir worktree hazırlar. Aynı repodaki iki farklı issue üzerinde çalışan iki Agent, paylaşılan bir checkout değil, kendi checkout'unu alır; böylece aynı Computer'da bile birbirlerinin dosyalarının üzerine yazamaz veya bir branch için kavga edemezler. Bu, AI kodlama ajanlarıyla git worktree'leri kullanmanın arkasındaki aynı disiplindir, yalnızca otomatik hali.
Eşzamanlılığın kendi tavanı vardır. Temporary çalıştırmalar varsayılan olarak Computer'ın genel sınırının yaklaşık yarısını kullanır; bunu elle yükseltin ve değer mevcut dizin kapasitesini aştığında ürün sizi uyarır; çakışmaların gerçekte başladığı yer burasıdır. Specified modu da vardır; bir Agent yeni bir worktree yerine tek bir sabit dizini yeniden kullanır, ancak aynı anda yalnızca bir çalıştırmaya hizmet eder; bu, birkaç Agent'ın aynı anda vurduğu bir repo için daha kötü bir uyumdur.
Geri dönen şey: pull request
Agent bir pull request açtığında, Task ID'sini branch adına, başlığa veya gövdeye yazarak onu Task'a bağlarsınız. Üçünden herhangi biri yeterlidir; SH-312 gibi çıplak bir ID, Fixes SH-312 ile aynı şekilde çalışır; çünkü fixes, closes veya skip gibi sözcükler için özel bir işleme yoktur. Herkese açık bir repoda yalnızca güvenilir bir yazar, sahip, üye veya işbirlikçi bağlanır; böylece bir yabancının pull request'i Task'ınıza sahte şekilde bağlanamaz.
Bağlantılı pull request'ler ayrıca Task'a geri işaret eden bir linkback yorumu alabilir. Bu, özel repolarda varsayılan olarak açıktır ve herkese açık olanlarda varsayılan olarak kapalıdır; GitHub ayarlarında bulunan bir anahtardır ve Space'in kendisinin herkese açık mı özel mi olduğundan ayrıdır.
İnceleme kapısı: muhakemenin durduğu yer
Bir pull request'i merge etmek Task'ın durumunu değiştirmez ve asla kendi kendine gerçekleşmez. Bu bilinçlidir. Task durumu ile bir Agent'ın çalışma durumu ayrı ayrı izlenir; bu nedenle Başlatılmış bir Task aynı zamanda Working, Waiting for human reply, Waiting for human review veya Error gösterebilir ve bu sinyaller sorumlu olan kişi için Inbox'ta görünür. Altta yatan GitHub issue'sunu kapatmak veya yeniden açmak iki yönlü bir Task'ın durumunu değiştirebilir; pull request'i merge etmek değiştiremez.
Agent'lar araştırır, yürütür, test eder ve raporlar. İnsanlar diff'i orijinal issue'ya karşı okur, değişiklik ister veya kabul eder ve merge ile release kararını kendileri verir. Bu ayrım baştan sona geçerlidir; GitHub'da da Sharkly'nin her yerinde olduğu gibi: otomasyon tam olarak ekip muhakemesinin gerekli olduğu yerde durur. Daha derin işleyiş için, Sharkly'nin human-in-the-loop inceleme iş akışı bunu doğrudan ele alır.
GitHub'ın kendi agent merkezi ne zaman yeterli olur
Ekibiniz GitHub, kaynak, CI, inceleme ve ücretli bir Copilot koltuğuna tamamen bağlıysa, GitHub'ın kendi Agent HQ'su bu ekosistem içindeki agent'ları iyi koordine eder ve başka bir şeye ihtiyacınız olmayabilir. Sharkly'nin gerekçesi, iş Jira'dan da geçmeye başladığında, Agent'lar GitHub'ın bulutunun dışındaki Computer'larda çalıştığında veya ekibiniz Runtime'ları karıştırıp en iyisi her değiştiğinde iş akışını yeniden kurmak istemediğinde ortaya çıkar. Jira bu karışımın parçasıysa, bir Jira ticket'ını bir AI Agent'a atamak aynı döngüyü o taraftan yürütür.
Gerçek bir issue üzerinde denemek için: Sharkly'nin GitHub, Jira ve Slack entegrasyonlarını açın, GitHub organizasyonunuzu bağlayın, düşük trafikli bir repoyu bir Space'e bağlayın ve sıradaki küçük issue'yu kendiniz yerine bir Agent'a atayın.
Sık sorulan sorular
GitHub organizasyonumu bağlamak bir Agent'a koduma erişim verir mi? Hayır. Organizasyon bağlantısı pull request bağlantılarını, issue senkronizasyonunu ve linkback yorumlarını kapsar. Kod erişimi ayrıca, Agent veya Space üzerinde yapılandırılır ve çalıştırmanın yine de Computer'da kendi Git kimlik bilgilerine ihtiyacı vardır.
Aynı repoda çalışan iki Agent hiç çakışır mı? Varsayılan Temporary modunda çakışmaz. Her çalıştırma kendi izole worktree'sini alır; böylece eşzamanlı Agent'lar aynı Computer'da bile hiçbir zaman bir çalışma kopyasını paylaşmaz.
Pull request'i merge etmek GitHub issue'sunu veya Task'ı kapatır mı? Merge etmek tek başına Task'ın durumunu asla değiştirmez. Altta yatan GitHub issue'sunu kapatmak, iki yönlü senkronize bir repoda bunu yapabilir, ancak bu PR'ı merge etmekten ayrı bir eylemdir.
Agent'ın pull request'i aslında neyi hedefler? Sharkly pull request'i, Runtime'ınızın hangisini yazdığına bağlı olarak branch, başlık veya gövdedeki Task ID'siyle bağlar. Bir branch stratejisi dayatmaz; bu yüzden test issue'sundan daha yüksek riskli bir şey atamadan önce Runtime'ınızın varsayılan base-branch davranışını doğrulayın.
Yalnızca yenileri değil, mevcut GitHub issue'larımı da tutabilir miyim? Bir repoyu bağlamak, bundan sonra oluşturulan yeni issue'ları senkronize eder. Mevcut issue'lar otomatik olarak içe aktarılmaz.
