GitHub Blog rehberi, Copilot, Claude Code ve Cursor için taşınabilir agent becerileri oluşturmayı anlatıyor

Bir agent becerisi nedir

GitHub Blog'un tanımladığı şekliyle bir agent becerisi, merkezinde SKILL.md dosyası bulunan sürümlenen bir dizindir; bu dosya, tekrar eden bir görevin ne zaman yapılacağını ve nasıl yürütüleceğini açıklar. Talimatlar agent'lar arasında taşınabilir; ancak bunlara göre harekete geçme yeteneği taşınabilir değildir. Araçlar, kimlik bilgileri ve izinler host ortama aittir; dolayısıyla bir beceri bir veritabanını sorgulama prosedürünü açıklayabilirken, o veritabanına erişim beceriyi çalıştıran tarafta kalır.

Procore'da Data Engineering Kıdemli Müdürü Shishir Tewari ile birlikte verilen bir GitHub Universe 2026 oturumuyla bağlantılı olan yazı, tanıdık bir sıkıntıdan yola çıkıyor: aynı görev bir agent'a defalarca yeniden anlatılıyor ve bu bilginin bir kısmı yalnızca bir çalışanın kafasında var. Beceriler, her ikisini de ekiplerin inceleyebileceği, sürümleyebileceği ve yeniden kullanabileceği dosyalara taşıyor; böylece bir akşam yazılan kişisel bir beceri daha sonra bir ekip pipeline'ının parçası olabiliyor.

Bir beceri, bir iş

GitHub, her beceriye tanımlı girdileri ve çıktıları olan tek ve net bir iş vermeyi öneriyor. İlk örnek olan Proof Agent, yapay zekâ tarafından üretilen değişiklikler için bir doğrulayıcı. Temel fikir şurada: bir agent'ın kendi işini notlaması gerçek bir denetim sayılmaz; bu yüzden beceri bağımsız bir doğrulayıcı başlatıyor. SKILL.md içindeki frontmatter beceriyi adlandırıyor ve amacını tanımlıyor; ayrıca özel bir bölüm, doğrulamanın ne zaman tetikleneceğini belirtiyor.

Doğrulama, doğrulayıcıya orijinal isteği ve kod diff'ini ileten ama kodlama agent'ının ne yaptığına dair kendi anlatımını bilinçli olarak vermeyen bir GitHub Actions workflow'unda çalışıyor. Doğrulayıcı PASS, FAIL veya PARTIAL yanıtı veriyor ve kanıtı değiştirilen dosyalarda göstermek zorunda. Action yalnızca diff'i statik olarak inceliyor; kod veya test çalıştırmıyor. Demoda denetim, başarısızlıkların yalnızca bilgilendirici olacak şekilde yapılandırılmıştı; ancak varsayılan olarak bir FAIL, denetimi başarısız kılıyor ve denetim zorunlu kılındığında bir merge'ü engelleyebiliyor. GitHub'a göre test sonuçları ve merge kuralları deponun CI'ına aittir.

Becerileri bir workflow içinde birleştirmek

İkinci örnek olan Data Forge, bir pipeline'ı doğru kılan muhakemenin birkaç kişiye dağıldığı, dolayısıyla bu kişilerin her değişiklik için darboğaz haline geldiği veri pipeline'larını hedefliyor. forge-init becerisi projeyi, kaynak tablolar ve adlandırma kuralları dahil, inceliyor ve bulgularını diğer tüm becerilerin okuduğu çözümlenmiş bir manifest'e kaydediyor. forge-builder becerisi ardından işi issue'dan pull request'e kadar yürütüyor; veri platformunu sorgulamak için forge-dbx, ekip standartlarını uygulamak için forge-lint'i çağırıyor. Bir kişi önerilen kararları süreç boyunca inceliyor ve ortaya çıkan pull request, pipeline kodunu, şema değişikliklerini ve testleri taşıyor.

Destek masası demosu, her birinde insan kontrol noktası bulunan yedi aşama çalıştırıyor; workflow bir aşamanın tamamlandığını doğrulayıp sonrakine başlıyor ve şema değişiklikleri çalışmadan önce onay istiyor. Her beceri tek bir sorumluluğa sahip olduğu ve proje bağlamını yeniden keşfetmek yerine paylaştığı için, bir adımdaki değişiklik yalnızca bir beceriyi düzenlemek ve geri kalanına dokunmamak anlamına geliyor.

GitHub sınırlar hakkında da açık sözlü. Beceriler; kontrol listeleri, sürümler (release), geçişler (migration) ve metrik pipeline'ları gibi yeniden kullanılabilir muhakemeden yararlanan, sınırlı ve tekrarlanabilir işlere uygundur. Bir workflow'un kararlı bir arayüze, paylaşılan duruma, denetim izine, uzun süreli kontrole veya model dışında zorunlu kılınan izinlere ihtiyacı varsa, uygulama daha uygun seçenektir.

Manifest'ler ve çok istemcili paketleme

Adlar, şemalar, kurallar ve veri motoru gibi projeye özgü ayrıntılar, becerilerin kendisine değil manifest'e aittir. Demoda manifest DuckDB'yi ve Spark tabanlı bir Python pipeline çerçevesini seçiyor; ancak DuckDB CLI'yı kuramıyor veya veritabanı erişimi veremiyor; kurulum ve erişim ortamın işi olarak kalıyor. GitHub ayrıca keşfedilen gerçekleri ekip kurallarından ayırıyor: forge-init bulduklarını kaydediyor, forge-lint standartları sağlıyor ve iş muhakemesi geçerli olduğunda insanlar keşifleri onaylıyor veya geçersiz kılıyor. Taşınabilirlik testi şudur: başka bir ekip, becerileri kendi manifest'ine karşı bunları yeniden yazmadan çalıştırabilir mi?

Birkaç agent istemcisini destekleyen ekipler için beceriler dizini tek doğruluk kaynağı olarak hizmet veriyor ve bir paketleme betiği istemciye özgü dosyalar üretiyor: Claude Code için .claude-plugin/plugin.json, Cursor için .cursor-plugin/plugin.json ve GitHub Copilot için .github/agents/*.agent.md. Betik, CI için bir kontrol modu içeriyor. İstemciler modeller, araçlar ve izinler açısından farklılaştığından GitHub, kurulumdan sonra istemcinin beceriyi amaçlanan görev için tanıdığını, referanslarını yüklediğini, gerekli araçları kullanabildiğini ve becerinin gerektirdiği kanıtı döndürdüğünü doğrulamayı öneriyor.

Neden önemli

Yazı üç pratikle kapanıyor: iş bağlamını tek bir görünür dosyada tutun, ilgili becerilere platforma giden tek ve paylaşılan bir yol verin ve işi yönlendirmek için talimatları, doğrulamak için denetimleri kullanın. Daha büyük sinyal ise standartlaşma. SKILL.md, Copilot, Claude Code ve Cursor arasında ortak bir format haline gelirse, yeniden kullanılabilir agent işi herhangi bir kod gibi incelenebilir hale geliyor, ekipler aynı prompt'ları istemci istemci yeniden yazmayı bırakıyor ve kurumsal bilgi, sohbet dizilerinden ve kişilerin kafalarından çıkıp sürümlenen dosyalara taşınıyor; insanlar karar noktalarında tutulurken CI sonuçları zorunlu kılıyor.