Copilot'a depo bağlamını öğretmek: talimatlar, skill'ler, ajanlar ve MCP

GitHub, Ekim 2026'da yayımladığı iki yazıda GitHub Copilot'un kod tabanı bağlamıyla kullanımına odaklandı. İlki üç Java Champion'ın üretim ve açık kaynak projelerindeki somut iş akışlarını, ikincisi depo düzeyinde özelleştirmenin dört yolunu anlatan bir başlangıç rehberini içeriyor. İkisi birlikte okunduğunda ortak bir sonuç çıkıyor: önerilerin isabeti modelin kendisinden çok, modele verilen bağlamla ve üretilen işin nasıl doğrulandığıyla ilgili.

Rehberdeki dört mekanizma şöyle: depo genelinde geçerli kurallar için .github/copilot-instructions.md, belirli dosya tiplerine daraltılmış kurallar için .github/instructions altındaki applyTo alanlı dosyalar, tekrarlayan prosedürler için .github/skills altında her biri kendi klasöründe duran SKILL.md dosyaları ve daha geniş görevler için .github/agents altındaki özel ajan profilleri. Dördüncüsü MCP sunucuları: Copilot'u depo dışındaki araçlara ve veri kaynaklarına bağlıyor. Playwright MCP ile Copilot tarayıcıda uygulamayı açıp arayüzü elle test edebiliyor. Ayrıntılar GitHub Blog'daki başlangıç rehberinde.

Talimat, skill, ajan: hangisi ne zaman?

Ayrım pratikte oldukça basit. Sürekli tekrar ettiğiniz bir kural varsa — "servis katmanı repository'yi doğrudan çağırmaz", "testler JUnit 5 ile yazılır" gibi — yeri özel talimat dosyası. Copilot'un her seferinde tahmin etmek zorunda kaldığı test ve lint komutları, sürüm hazırlığı ya da hata ayıklama adımları varsa, bunlar bir skill klasörüne gidiyor.

Ajan profilleri ise tek bir prosedürden büyük işler için. Erişilebilirlik denetimi gibi birden çok dosyayı ve aracı aynı anda dolaşması gereken görevlerde, Copilot'un belirli bir rol ve bakış açısıyla çalışmasını sağlıyor. Skill'lerin SKILL.md içindeki açıklaması, Copilot'un o becerinin ne zaman devreye gireceğine karar vermesinde kullanılıyor; yani açıklamayı "ne yapar" diye değil "ne zaman kullanılır" diye yazmak gerekiyor.

Şampiyonların iş akışından çıkan dersler

Vlad Mihalcea, Hypersistence Optimizer için performans geçmişini gösteren bir web uygulamasını haftalar yerine iki günde bitirdiğini söylüyor. Buradaki asıl ilginç kısım süre değil, hazırlık: kendi yayımlanmış yazılarından 65'inin üslubunu yakalayan bir skill hazırlamış, böylece Copilot'un ürettiği dokümantasyon "model gibi" değil "kendisi gibi" okunuyor. Ayrıntılı işlerde büyük bağlam pencereli bir modeli, rapor ve sürüm notu gibi hafif işlerde daha küçük modelleri kullandığını da ekliyor.

Patrick Baumgartner'ın örneği doğrulama tarafını daha net gösteriyor. 15 sunumdaki yaklaşık 900 slaytı Reveal.js'ten Marp'a taşımış, iş sekiz-on saat sürmüş. Ama "taşındı" demekle yetinmemiş: ekran görüntülerini görsel ve algoritmik olarak karşılaştırmış, iki desteyi yan yana çalıştıran küçük bir uygulama yazmış, PDF çıktılarını da kıyaslamış. Onun ifadesiyle "bitti", modelin bitti demesi değil.

Baumgartner'ın net tavsiyesi tek seferde her şeyi istememek: önce ajanın kendisiyle mülakat yapmasını istiyor, çünkü iyi bir ajan yanlış fikri çok hızlı uygulayabiliyor ve sonradan o yoldan dönmek pahalıya geliyor. Aynı kişi dört saatlik bir yolculukta telefonundan yönettiği ajanla Spring Boot otomatik yapılandırma optimizasyonu için çalışan bir Maven eklentisi, CI hattı ve performans testleri üretmiş.

Frank Delporte ise Copilot'u pull request değerlendirmede ve hata raporu incelemede kullanıyor. Pi4J kütüphanesinin Şubat 2026'da çıkan V4 sürümü, Foreign Function & Memory API kullanan yeni bir eklenti getirmiş; sürümden kısa süre sonra beş giriş düğmesinden beşincisinin çalışmadığı bildirilmiş. Bu tür bağlam ağırlıklı hata ayıklamada Copilot'un işi hızlandırdığını ama kararı vermediğini aktarıyor. Üç ismin deneyimleri ilgili GitHub yazısında yer alıyor.

MCP'yi ne zaman devreye almalı?

MCP, Copilot'un depo dışına çıkması gerektiğinde anlamlı. Baumgartner dokümantasyon için Context7'yi, kendi Logseq bilgi tabanını ve bir deneme olarak Adobe Premiere Pro entegrasyonunu kullanmış. Kuralı net: iyi bir komut satırı aracı varsa MCP kurmak yerine onu tercih ediyor, çünkü daha doğrudan ve daha hızlı geliyor. Rehberdeki Playwright örneği ise farklı bir boşluğu dolduruyor: kod otomatik testlerden geçse bile arayüzün gerçekten beklendiği gibi davrandığını görmek.

Somut bir başlangıç ve sınırlar

Küçük başlamak için şu sıra işe yarıyor:

• Sürekli tekrar ettiğiniz tek bir kuralı seçip .github/copilot-instructions.md içine yazın.
• Dosya tipine özgü kuralları .github/instructions altına applyTo ile ayırın; geniş kuralları her dosya tipine zorlamayın.
• Tekrarlayan bir prosedürü (test, lint, sürüm hazırlığı) SKILL.md olarak paketleyin; açıklamayı "ne zaman" sorusuna göre yazın.
• Her görev için "bitti" tanımını kanıtla birlikte belirleyin: testler, ekran görüntüsü, içerik kontrolü.
• MCP'yi yalnızca depo dışı bir araca gerçekten ihtiyaç duyduğunuzda ekleyin; komut satırı yetiyorsa onunla kalın.

Sınırları da açık söylemek gerekiyor. Her iki metin de bireysel deneyimlere dayanıyor; ölçülmüş bir üretkenlik artışı ya da ekip ölçeğinde karşılaştırmalı bir veri sunmuyor. Sekiz-on saatlik taşıma süresi tek bir kişinin aktarımı, iki günlük uygulama örneği de tek bir projeye ait. Bana kalırsa buradan çıkarılacak en sağlam sonuç, araç seçimi değil: ajanı hızlandırıcı olarak kurup sorumluluğu insanda tutmak, ve her adımda "bitti"yi kanıtla tanımlamak.