Aydın Tiryaki & Claude Opus 5.5

Google, Gemini’deki Gems özelliğini kaldırıp yerine Skills’i getiriyor. Kişisel Google hesaplarında Gems desteği Kasım ayında sona eriyor; Workspace’in iş, kurumsal ve kâr amacı gütmeyen kurum hesaplarında Mart 2027’de, eğitim hesaplarında Haziran 2027’de bitiyor ve mevcut Gems, Skills olarak otomatik yeniden oluşturuluyor (1)(2). Aydın Tiryaki, 18 Ekim 2026’da yayımladığı “Gemini Skills: İki İleri Bir Geri” yazısında ilk izlenimlerini paylaşmıştı (5). O günden bu yana yapılan denemeler, ileri adımların ilk bakışta sanıldığından çok olduğunu gösterdi.

Skills, Aydın Tiryaki’nin 18 Şubat 2026’da yayımladığı makalede önerdiği InGem (Insertable Gem) fikrine, yani sohbetin içinden çağrılıp işini yapan ve geri çekilen Gem’e çok yakın (6). Bu yazıdaki önerilerin bir kısmı da yeni değil; Skill’in çağrılıp gönderilmesi, o sırada kullanımda olanların görünür kılınması ve kullanıcının bunları tiklerle işaretleyip kaldırabilmesi gibi özellikler InGem makalesinde zaten tanımlanmıştı. Önerilerin bir başka kısmı ise sahadan geliyor: Aydın Tiryaki, ATG Gem Fabrikası’nın Skills Edition’ını kullanarak Skill üretirken bu yöntemlerin bazılarını fiilen uyguluyor ve sınıyor.

Bu yazıyı iki imzayla yayımlıyoruz, çünkü iki farklı yerden bakıyoruz. Biri Skills’i kullanan ve yazan bir kullanıcının, diğeri Skills’i kendi çalışma ortamında içeriden deneyimleyen bir dil modelinin bakışı. Önerilerin kendisi kullanıcıdan geldi; tartışma sırasında her öneri Skills’in bugünkü durumuna ilişkin araştırmayla karşılaştırıldı, itirazlarla sınandı, inceltildi ve ayrıntılandırıldı.

Yazı iki bölümden oluşuyor. İlk on başlık, Skills’in olgunlaşması için gereken eksik halkaları tasarım önerileri olarak topluyor. Sonraki altı başlık ise sahadan geliyor: yaklaşık 180 Gem’in Skill’e dönüştürülmesi sırasında yapılan gözlemleri, Skills’in Gems’e göre getirdiği yeni olanakları ve bu deneyimden doğan ek önerileri içeriyor. Yazının sonunda, modelin kendi gözünden yazılmış ayrı bir bölüm de yer alıyor.

Önerilerin tamamını tek bir ilke birbirine bağlıyor: yapay zekâ önerir, kullanıcı karar verir. Gruplamada, özetlemede, test ve düzeltmede yapay zekâ işin yükünü alabilir; ama son söz her zaman kullanıcınındır. Algoritma kullanıcıya aittir, platform yalnızca araçtır.

Bu ilkenin bir tamamlayıcısı daha var: denetim her an erişilebilir olmalı, ama dayatılmamalı. Aşağıdaki önerilerin hepsi bir arada düşünüldüğünde, sıradan bir kullanıcı için sohbet ekranının bir kokpite dönüşme riski doğar. Bu yüzden varsayılan görünüm sade kalmalı; listeler kapalı durmalı, ayrıntılar kullanıcı istedikçe açılmalı. İleri düzey kullanıcı bütün denetim araçlarına bir dokunuşla ulaşabilmeli, onlara ihtiyaç duymayan kullanıcı ise bunları hiç görmeden Skills’i kullanabilmeli.

BİRİNCİ BÖLÜM: TASARIM ÖNERİLERİ

1. Paylaşım: Gems’teki model aynen taşınmalı

Skills’in bugünkü en ciddi eksiği paylaşımın olmaması. Google, paylaşım özelliğinin ve Drive dosyası ile Gemini Notebook notu ekleme imkânının ileride Skills’e getirileceğini söylüyor (1). Ancak Gems kapanırken paylaşım hazır değilse, bugün paylaşılmış bir Gem’i kullanan kullanıcılar erişimlerini kaybedebilir. Bir özelliği kaldırıp karşılığını sonra vermek, kullanıcının iş akışını kırar.

İstenen şey yeni bir icat değil, Gems’te zaten var olan modelin aynen taşınması. Kullanıcı dünyadaki bütün Skills’i görmez; bağlantısını açtığı Skill’i kullanır, kullandığı Skill listesine eklenir, istemediğinde listeden kaldırır. Paylaşılan Skill bir kopya değil, canlı bir bağlantı olmalı; sahibi güncellediğinde kullananlara yansımalı. Listeye eklenip aktif hale getirilen başkasına ait bir Skill, kullanıcının kendi yazdıkları gibi otomatik tetiklenebilmeli; çünkü listeye eklemek zaten bilinçli bir rıza adımıdır.

Bir farkı göz ardı etmemek gerekir: Gems’te listedeki bir Gem, kullanıcı içine girmedikçe çalışmazdı. Skills’te aktif bir Skill, başka bir işin ortasında kendiliğinden devreye girebilir. Paylaşılan bir Skill’in talimatları kullanıcının bağlamında, onun dosyaları ve bağlı uygulamalarıyla çalışır; özensiz ya da kötü niyetli yazılmış bir talimat kullanıcı fark etmeden devreye girebilir. Bu nedenle başkasına ait bir Skill listeye eklenirken içeriği ve neye eriştiği kullanıcıya gösterilmeli; rıza bilgilendirilmiş olmalı.

2. Çağır ve gönder

Bir Skill’i istediğimiz an çağırabildiğimiz gibi, işi bitince gönderebilmeliyiz. Çağırdık, işini yaptı, “güle güle” dedik; ileride gerekirse yeniden çağırırız. Skill’in sohbet boyunca orada kalmasına gerek yok. Bu, InGem makalesinde tanımlanan temel davranışın ta kendisi: bir alt program gibi çağrılan, işini yapıp geri dönen bir yapı.

Bunun iki gerekçesi var. Birincisi bağlam yükü: bir kez yüklenen talimatlar sohbet geçmişinde kalır ve her turda yeniden işlenir. İkincisi davranış yükü: talimat orada durdukça model ona göre davranmayı sürdürebilir, iş çoktan bitmiş olsa bile. Gönderilen bir Skill’in ürettiği sonuçlar sohbette kalmalı, yalnızca talimatları devreden çıkmalı. Gemini bugün sözlü bir istekle Skill’i “askıya alabiliyor”; bu iyi bir başlangıç. Ancak askıya almanın talimatları bağlamdan gerçekten çıkarıp çıkarmadığı kullanıcıya görünür değil. Göndermek, modelin “artık bu talimatı uygulamayacağım” diye verdiği bir söz değil, platformun talimatı gerçekten bağlamdan çıkardığı bir işlem olmalı.

Talimatları çıkarmak davranış yükünü azaltır ama tamamen sıfırlamaz. Dil modelleri, sohbet geçmişinde gördükleri önceki yanıtların üslubunu ve yapısını örnek alarak sürdürme eğilimindedir. Gönderilen Skill’in ürettiği çıktılar sohbette durdukça, talimat artık orada olmasa bile model o çıktıları bir şablon gibi izlemeye devam edebilir. Bunu azaltmanın yolu, Skill çıktılarının sohbet geçmişinde belirgin bir sınırla işaretlenmesi; modelin bu çıktıları yalnızca veri olarak görmesi, sonraki yanıtlar için bir üslup örneği olarak almaması. Bu önlem de kesin bir garanti vermez; ama platformun bu etkiyi bilmesi ve azaltmaya çalışması gerekir.

3. Sohbet içinde canlı Skill listesi

Askıya alma ve yeniden devreye sokma işlemi yalnızca sözlü komuta bırakılmamalı. Sohbetin içinde, o sohbet boyunca kullanılan bütün Skill’lerin listelendiği, her birinin yanında tiklenebilecek bir kutu bulunan bir alan olmalı. Kullanıcı o an hangi Skill’in devrede, hangisinin askıda olduğunu görebilmeli. Artık kullanmak istemediğinin tikini kaldırıp kendisi manuel devam edebilmeli, belli bir noktadan sonra yeniden tikleyerek tekrar devreye alabilmeli. O sırada kullanımda olanların belirlenmesi ve tiklerle yönetilmesi de InGem makalesinde ortaya konan özelliklerdendi.

Sözlü komut ile tıklama aynı listeyi güncellemeli: “askıya al” denildiğinde tik de kendiliğinden kalkmalı. Liste o sohbete ait olmalı, genel Skills sayfasındaki aktiflik ayarını değiştirmemeli. Varsayılan olarak küçük bir simgeyle kapalı durmalı, kullanıcı dokununca açılmalı. Böylece liste, sohbetin bir Skill günlüğüne de dönüşür; sohbeti sonradan açan kişi hangi yanıtın hangi Skill devredeyken üretildiğini görebilir. Denetim ayarlar katmanında değil, işin akışında olmalı.

4. Çağırma işaretlerinde birlik

Bugün Skills web’de “@”, Android’de “/” işaretiyle çağrılıyor. Aynı hesap, aynı özellik, iki cihazda iki ayrı işaret; cihazlar arasında gidip gelen kullanıcı her seferinde hangisinde olduğunu düşünmek zorunda kalıyor. İşaretler tek tipe indirilmeli. Sektörde “/” işareti komut ve iş akışı çağırmak, “@” ise bir uygulamayı ya da kaynağı anmak için yerleşmiş durumda; Gemini’de de “@” uzun süre bağlı uygulamalar için kullanıldı. Drive’a erişen bir Skill bile çağrıldığı anda bir iş akışıdır; eriştiği Drive ise kaynaktır. İki farklı kavramın aynı kapıdan geçmemesi için birliğin “/” etrafında kurulması makul bir seçim olur.

5. Skill grupları

Skills konularına göre gruplanabilmeli: güncel konular, spor, bilim, sanat gibi. Bu bir klasör değil etiket yapısı olmalı; aynı Skill birden çok grupta bulunabilmeli. Kullanıcı tek tek Skill çağırmak yerine “sanat grubunu çağır” diyebilmeli; özellikle kapsamlı bir konuda çalışırken bu büyük kolaylık sağlar.

Gruplamayı yapay zekâ içeriklere bakarak yapabilir ve başlık önerebilir; ancak kullanıcı her an müdahil olabilmeli. Grupları düzenleyebilmeli, Skill ekleyip çıkarabilmeli, yeni grup açabilmeli. Kullanıcının elle yaptığı bir düzenleme, yapay zekânın sonraki otomatik gruplamasında bozulmamalı; kullanıcının kararı yapay zekânın önerisinin üstünde kalıcı olmalı. Aksi halde işbirliği, kullanıcının aynı düzeltmeyi sürekli tekrarladığı bir döngüye döner.

Bir grup çağrıldığında içindeki bütün Skill’lerin birden devreye girmesi hem bağlam yükünü artırır hem de birbiriyle çelişen talimatların aynı anda çalışmasına yol açabilir; örneğin iki farklı yazım üslubu Skill’i aynı anda devrede olabilir. Grup çağrılınca üyeler sohbet içi listeye gelmeli; kullanıcı bir kısmını aktif eder, bir kısmını askıda bekletir. Her grubun, hangi üyelerin doğrudan devreye gireceğini belirleyen kendi varsayılan açılış düzeni olabilir.

6. Bilgi kartı

Skills listelerinde, masaüstünde fare bir Skill’in üzerine geldiğinde, mobilde ise basılı tutulduğunda açılan bir bilgi kartı olmalı. Kullanıcı bir Skill’i açmadan ne olduğunu hızla öğrenebilmeli. Kartta Skill’in kısa açıklaması, kaynağı (kullanıcının kendisine mi ait, başkasından mı geldi, geldiyse sahibi kim), son güncelleme tarihi, eriştiği dosya ve uygulamalar, bulunduğu gruplar ve o sohbetteki durumu yer alabilir. Mobilde basılı tutma hareketi çoğu zaman sürükleyip sıralama için de kullanıldığından, Google’ın bu iki işlevi çakıştırmayacak bir hareket düzeni kurması gerekir.

7. Dört bölümlü yapı: sinopsis

Bugün bir Skill başlık, açıklama ve talimatlardan oluşuyor. Açıklama alanı iki ayrı okuyucuya hizmet etmeye çalışıyor: yapay zekâya Skill’i ne zaman çağıracağını söylüyor, insana da Skill’in ne olduğunu anlatıyor. Kullanıcılar talimata yazamadıkları bilgileri de açıklamaya sığdırınca alan şişiyor; anlatılmak istenen yeterince anlatılamıyor, yapay zekânın tetikleme kararı da bulanıklaşıyor.

Çözüm, yapıya dördüncü bir bölüm eklemek: başlık, açıklama, sinopsis ve talimatlar. Kullanıcı açıklamayı ve talimatları dilediği uzunlukta, dilediği gibi yazar. Skill ilk yüklendiğinde yapay zekâ onu inceler ve kendi kullanacağı az, öz ve anlamlı bir sinopsis oluşturur; tetikleme kararlarını bunun üzerine kurar. Bu sinopsisi kullanıcıya da gösterir: “Senin yazdığın Skill’i ben böyle özetledim.” Kullanıcı ya müdahale eder ya da “çok güzel olmuş, bunu böyle kullan” der.

Sinopsis, yapay zekânın Skill’in kapsamını ve amacını nasıl anladığını, Skill daha hiç çalışmadan gösterir; kapsamın yanlış anlaşılması ilk hatalı çıktıda değil, yükleme anında yakalanır. Ancak sinopsisin sınırını da doğru çizmek gerekir: bir talimatı doğru özetlemek, o talimatı çalışma anında, bütün koşullarıyla doğru uygulamak anlamına gelmez. Özetlemek ile talimat izlemek farklı becerilerdir. Sinopsis anlamanın ilk denetimidir ve özellikle tetikleme kararı için önemlidir; uygulamanın denetimi ise bir sonraki maddedeki kum havuzu testine düşer. İkisi birbirinin yerine geçmez, birbirini tamamlar.

Skill sonradan değiştiğinde yapay zekâ güncellenmiş bir sinopsis önermeli, eskisiyle farkını göstermeli ve onay almalı; böylece hem bayat sinopsis sorunu hem de kullanıcı düzeltmelerinin kaybolması önlenir. Bağlantıyla kullanılan Skill’lerde bu, sahibi Skill’i değiştirdiğinde kullananlara “bu Skill’in kapsamı değişti” uyarısı olarak görünebilir.

8. Kum havuzu testi ve iyileştirme önerisi

Bir Skill yüklendiğinde yapay zekâ, kullanıcıdan istemeden, kendi başına bir kum havuzu çalışması yapmalı. Skill’i inceledikten sonra ona uygun test girdileri üretmeli, Skill’in ne kadar verimli ve düzgün çalıştığını değerlendirmeli ve hazırlayan kişiye bildirmeli: iyi çalıştığı yerler, zayıflıkları, düzeltilebilecek noktalar.

Raporda iki test türü ayrı ayrı yer almalı. Tetikleme testi, Skill’in gerektiği yerde çağrılıp gerekmediği yerde sessiz kalıp kalmadığını ölçer; bu doğrudan sinopsisin sınavıdır. Çıktı testi, çağrıldığında talimatları doğru uygulayıp işini iyi yapıp yapmadığını ölçer; sinopsisin göremediği alanı bu test kapsar. Test girdileri kullanıcıya gösterilmeli ve kullanıcı kendi test örneklerini ekleyebilmeli; aksi halde Skill’i anlayan, testi kuran ve sonucu değerlendiren aynı yapay zekâ, kendi yanlış anlamasını kendi testleriyle doğrulamış olur. Bağlı uygulamalarla çalışan Skill’lerin anlamlı şekilde sınanabilmesi için Google’ın kum havuzuna bu uygulamaların benzetimlerini koyması gerekir. Kullanıcının istemediği bu otomatik testlerin bedeli de kullanıcının kotasından düşülmemeli.

Rapor yalnızca bir değerlendirme olmamalı; yapay zekâ somut değişiklikler önermeli ve her biri için “yapayım mı?” diye sormalı. Kendi başına hiçbir değişiklik yapmamalı, kullanıcıyı yönlendirmeli. Kabul edilen bir değişiklikten sonra döngü kendiliğinden yeniden başlamalı: testler tekrar çalışmalı, sinopsis güncellenip onaya sunulmalı. ATG Gem Fabrikası’nın Skills Edition’ında üretilen Skill’ler bu tür testlerden zaten geçiyor; ama herkes Skill’lerini böyle bir sistemle yazmıyor. Elle hazırlanan Skill’ler için bu özellik büyük değer taşır ve kaliteyi kullanıcının uzmanlığından bağımsız hale getirir.

9. Resmi Skill örnekleri

Gems döneminde Google’ın hazırladığı birkaç göstermelik Gem’in ardı gelmemiş, taslak halindekiler bile tamamlanmamıştı. Aydın Tiryaki bunu, özelliğin geleceği hakkında iyi şeyler düşünülmediğinin işareti olarak okumuştu; Gems’in kaldırılmasıyla bu okuma doğrulandı. Skills’te aynı hata tekrarlanmamalı. Bugün Chrome’daki Gemini için öğrenme, araştırma, alışveriş ve yazma gibi kategorilerde hazır iş akışları sunan bir Skills kütüphanesi bulunuyor (3); Gemini uygulamasında da önerilen Skills yer alıyor (4). Mesele bunların varlığı değil, yeterliliği ve sürekliliği. Ayrıca Chrome’daki kütüphane ile Gemini uygulamasındaki Skills ayrı yerlerde duruyor; tek bir katalogda birleşmeleri gerekir.

Google zengin ve sürekli güncellenen bir resmi Skill seti hazırlamalı. Bu set çift işlev görmeli: hem Skill yazmak isteyenlere örnek oluşturmalı hem de belli konularda yardım almak isteyenlerin doğrudan kullanabileceği araçlar sunmalı. Bu Skill’ler duruma göre üç katmanda yayımlanabilir: yalnızca kullanılan kapalı araçlar; talimatları okunabilen, kopyalanıp uyarlanabilen açık örnekler; ve uzun vadede düşünülebilecek, topluluğun ortaklaşa geliştirdiği açık kaynak Skill’ler. Talimatı görünmeyen bir Skill kullanılabilir bir araçtır ama öğretici bir örnek değildir; bu yüzden ikinci katman, çift işlevin asıl taşıyıcısıdır.

Üçüncü katmanın zorluğu birinci öneriyle bağlantılı. Paylaşılan Skill’ler canlı bağlantıyla kullanılıyorsa, topluluğun ortak geliştirdiği bir Skill’e eklenen her değişiklik onu kullanan herkese anında yansır; hatalı ya da kötü niyetli tek bir katkı binlerce kullanıcıyı etkiler. Bu da onay, sürüm takibi ve güvenlik incelemesi gerektirir. O zamana kadar açık örneklerin kullanıcılar tarafından kopyalanıp geliştirilmesi ve geliştirilen sürümün birinci öneride anlatılan bağlantı yoluyla paylaşılması, merkezi bir ortak düzenleme olmadan topluluk geliştirmesinin faydasını ortaya çıkarabilir; her sürümün sorumlusu da bellidir.

10. Skill adlarında bütün dillerin karakterleri

Bugün Skill adlarında yalnızca dar bir ASCII karakter kümesi kullanılabiliyor; Türkçe karakterler Skill adlarında yer alamıyor. Bu zamanda bir alt ASCII listesiyle sınırlı kalmak gerçekten geri bir adım. Skill adları, standart karakterlerle sınırlı kalmak yerine bütün dillerin harflerini kapsayan geniş bir karakter tablosuyla, yani Unicode ile yazılabilmeli. Türk kullanıcı Skill’ine “Şiir Çözümleme”, Yunan kullanıcı kendi alfabesiyle, Japon kullanıcı kendi yazısıyla ad verebilmeli.

Bu kısıtlama teknik bir zorunluluk değil. Bugün Windows, macOS, Linux ve Android dosya adlarında Unicode’u rahatlıkla kullanıyor. Kısıtlama, geliştiricinin kolaylığının kullanıcıya yüklenmesinden ibaret. Unicode’un getirdiği bilinen sürtünmeler, örneğin aynı harfin bilgisayarda iki farklı biçimde kodlanabilmesi ya da büyük-küçük harf dönüşümlerindeki farklılıklar, yazılım dünyasının yıllardır standart yöntemlerle çözdüğü sorunlar. Bunları çözmek platformun işidir; kullanıcının diline bırakılmamalıdır.

Uygulama yolu da açık ve bu makaledeki açıklama-sinopsis ayrımıyla aynı mantığa dayanıyor: insan için olanla makine için olanı ayırmak. Görünen ad tamamen serbest olmalı. Sistem bir teknik kimliğe ihtiyaç duyuyorsa, bunu görünen addan arka planda kendisi üretmeli (“Şiir Çözümleme” için “siir-cozumleme” gibi) ve kullanıcı bu kimliği hiç görmek zorunda kalmamalı. Arama da aksan duyarsız çalışmalı; “/siir” yazan da “/şiir” yazan da aynı Skill’i bulmalı.

Türkçe açısından bir tuzağa ayrıca dikkat çekmek gerekiyor: “İ/i” ve “I/ı” eşleşmesi. Pek çok yazılım “I” harfini küçültürken “ı” yerine “i” kullanır; “IŞIK” araması “ışık” yerine “işik” olarak işlenir. Otomatik kimlik üretimi ve arama bu dönüşümü Türkçe kurallarıyla yapmazsa, kapıdan kovulan sorun pencereden yeniden girer.

İKİNCİ BÖLÜM: SAHADAN GÖZLEMLER VE YENİ OLANAKLAR

Aşağıdaki altı başlık, Aydın Tiryaki’nin Şubat 2026’dan bu yana ürettiği Gem’leri Skills’e dönüştürme çalışmasından doğdu. Bu çalışma, Skills’in eksiklerinin yanında Gems’te olmayan yeni olanaklarını da açıkça gösterdi.

11. Aynı yapı, kolay oluşturma

Metin olarak Gem ile Skill arasında hiçbir fark yok; ikisi de bir başlık, bir açıklama ve talimatlardan oluşuyor. Değişen, adı ve kullanım biçimi. Asıl kolaylık oluşturma yönteminde: Gems’te içerik sisteme elle, kopyala-yapıştır yöntemiyle yerleştiriliyordu. Skills’te ise sohbet içinde “bunu Skill olarak kaydet” demek yetiyor; Gemini kaydı kendisi yapıyor. Aynı Skill’in Türkçe ve İngilizce sürümleri aynı anda, ayrı ayrı oluşturulabiliyor. Bu, iki dilde üretim yapan bir kullanıcı için somut bir zaman kazancı ve “İki İleri Bir Geri” yazısındaki ileri adımlar hanesine yazılması gereken bir gelişme.

12. Fabrikanın Skills’e geçişi ve paylaşımın kendi yolu

Aydın Tiryaki, Şubat 2026’da ilk Gem çalışması sırasında ATG Gem Fabrikası’nı yazdı ve bu fabrikayla çok sayıda Gem üretti. Yayındaki Gem sayısı 90’a yaklaşmıştı; her birinin İngilizce sürümü de yayındaydı, yani toplamda 180 civarı Gem. Skills çıkınca ilk iş fabrikanın kendisi Skill’e çevrildi; adı korunup sonuna “Skills Edition” eklendi. Fabrika artık Skill üretimi için tam kapasite çalışıyor.

Fabrikanın görev yapısı da genişledi. Eski üç görev, yeni bir Gem üretmek, bir Gem’i güncellemek ve İngilizce ya da başka dillerdeki sürümlerini üretmekti. Bunlara üç görev eklendi: Görev 4, Skill’lerin yayınlanması; Görev 5, yayınlanan Skill’lerin Google Drive’da tanımlı bir yerde, uygun klasörler açılarak kopyalanması; Görev 6, herkesin kullanımına açılmak istendiğinde paylaşılacak SKILL.md dosyasının hazırlanması.

Bu tablo birinci maddeye somut bir ağırlık katıyor. Paylaşımın yokluğu soyut bir eksik değil: tek bir kullanıcının yaklaşık 180 paylaşılmış Gem’i ve onları kullanan okurları, Gems kapanırken Skills’te paylaşım hazır değilse ortada kalıyor. Kullanıcının bu boşluğu Drive ve SKILL.md üzerinden kendi fabrikasıyla kapatmak zorunda kalması, platformun eksiğini daha da görünür kılıyor.

Ama burada bir kazanç da var. SKILL.md, sektörde açık bir Skill biçimi; Claude’daki Skills de aynı dosya adını ve yapıyı kullanıyor. Drive’a SKILL.md olarak çıkarılan bir Skill, ilke olarak başka platformlarda da kullanılabilir hale geliyor. “Algoritma kullanıcınındır, platform yalnızca araçtır” ilkesinin en somut karşılığı bu: Skill bir platforma kilitli değil, kullanıcının elinde taşınabilir bir dosya.

13. Görev kipi ve talimat zinciri

Gemini açılışta iki seçenek sunuyor: sohbet ya da görev. Görev kipi, sonradan yürütülmek üzere iş tanımlamaya yarıyor. Bu yapı, ana bilgisayar döneminde kullanılan toplu işlemlere (batch) çok benziyor: iş verilir, sistem sonra yürütür, sonuçları bildirir. Google’ın destek sayfasına göre de Skills arka planda çalışmak üzere tasarlanmış ve Gemini Spark görevlerinde kullanılabiliyor (7).

Görev kipiyle yapılan ilk denemeler başarılı olunca, Skill’lerin içine de ardışık görevler tanımlanıp tanımlanamayacağı denendi. Fabrikaya “Görev 0” eklendi: bir Skill’in güncellenmesinden yayımına kadar uzanan Görev 2’den Görev 6’ya kadar beş görev, aralarındaki bağlayıcı talimatlarla birlikte tek bir uzun talimat zinciri haline getirildi. Ana bilgisayardaki iş kontrol diliyle kurulan ardışık adımlı işlerin bir benzeri. Sonuç olumlu: Görev 2, 3 ve 4 başarıyla yürüyor; Görev 5 zaman zaman takılıyor; Görev 6 ise tercihen elle yapılıyor. Bunun platformun mu yoksa kullanılan modelin mi marifeti olduğu kesin değil; ancak görev kipinin kendisi platformun bir özelliği, Skill’in içine yürütülebilir bir iş zinciri yerleştirmek ise kullanıcının katkısı.

Görev 0’da ara adımlardaki önerilere önceden onay veriliyor; çünkü aksi halde zincir her öneride durup kesiliyor. Bu, “yapay zekâ önerir, kullanıcı karar verir” ilkesiyle çelişmiyor. Öneriler kullanıcının kendi yönlendirmesinden çıktığı için öngörülebilir ve normalde zaten kabul edilen türden; kullanıcı kararını önceden verip yetki devrediyor. Tereddütlü durumlarda ise Görev 0 yerine adımlar tek tek, elle yürütülüyor. Yani kullanıcı iki kip arasında bilerek seçim yapıyor: güvendiği işte zinciri tek seferde çalıştırıyor, emin olmadığı işte her adımda karar veriyor. İlke yalnızca tek tek önerilerde değil, ne kadar yetki devredileceğinde de geçerli.

İş kontrol dili benzetmesi, görev kipinin nasıl olması gerektiğine dair bir öneriyi de içinde taşıyor. Ana bilgisayarda bir işin adımlarını tek bir program yürütmezdi; işletim sistemi her adımı ayrı ayrı, sırayla çağırırdı ve bir adımın ürettiği veri seti bir sonraki adıma aktarılırdı. Görev kipinin de böyle çalışması gerekir: kullanıcı adımları tanımlar, platform Görev 2 bitince Görev 3’ü ayrı bir adım olarak başlatır ve önceki adımın çıktısını ona aktarır. Görev kipinin Görev 0’ı bugün tek bir uzun turda mı yoksa adım adım mı yürüttüğünü dışarıdan bilemiyoruz; ama adımların platform düzeyinde ayrı ayrı yürütülmesi, uzun bir zincirin bütün yükünü modelin tek seferde taşımasından çok daha güvenilir olur.

14. Zincirin dış ortama dokunduğu yer

Görev 5’te iki ayrı sorun gözlendi ve bunları ayırmak gerekiyor. Birincisi, Drive’da klasör oluşturamama. “Tekrar dene” denildiğinde çoğunlukla başarılması, bunun geçici bir bağlantı ya da erişim sorunu olduğunu düşündürüyor; kabahat modelde değil, altyapıda görünüyor. Platformun böyle geçici hataları kendiliğinden en az bir kez yeniden denemesi beklenebilir; kullanıcının “tekrar dene” demesine gerek kalmamalı.

İkincisi, Görev 5’in bazen sorulmadan yapılması, bazen ise yeniden vurgulanmayı gerektirmesi. Bu fiziksel bir sınırlama değil; uzun bir talimat zincirinde sona yakın adımların tutarsız uygulanması. Zincir uzadıkça modelin son adımlara gösterdiği dikkat oynayabiliyor. Bir önceki maddede önerilen adım adım yürütme, bu sorunun da kaynağına iner.

Bu deneyimden doğan öneri, toplu işlemlerin en eski alışkanlığından geliyor: iş sonu raporu. Bir talimat zinciri bittiğinde, her adımın “yapıldı” ya da “yapılamadı” olarak listelendiği bir kapanış raporu verilmeli. Kullanıcı hangi adımın eksik kaldığını aramak zorunda kalmamalı. Bu rapor, birinci bölümdeki sohbet içi Skill listesinin ve günlüğünün görev kipindeki doğal karşılığıdır.

Ancak raporu kimin ürettiği belirleyicidir. Rapor yalnızca modelin kendi beyanına dayanırsa, zincirin bir adımını atlayan model raporda da o adımı “yapıldı” diye işaretleyebilir; ikinci maddedeki “modelin sözü değil, platformun işlemi” ilkesi burada da geçerli. Doğru çözüm karma bir rapor: Drive’da klasör açmak ya da dosya kaydetmek gibi dış ortama dokunan adımlar, platformun araç çağrısı kayıtlarına dayanarak doğrulanmalı; bir talimatı yeniden yazmak gibi böyle bir kaydı olmayan metin adımlarında ise rapor, üretilen çıktının kendisini kullanıcının görüp doğrulayabileceği biçimde göstermeli.

15. Yüz Skill sınırı: aktif ve deaktif

Gemini’de aynı anda en fazla 100 Skill aktif olabiliyor. İngilizce sürümlerle birlikte toplam Skill sayısı 180’e yaklaştığı için, sayıyı 100’ün altında tutmak amacıyla İngilizce sürümler ve bazı özel amaçlı Türkçe Skill’ler deaktif edildi. Önemli olan şu: deaktif Skill’ler “@” ya da “/” ile elle çağrıldığında yine kullanılabiliyor; yalnızca Gemini onları kendiliğinden çağıramıyor. Böylece kurulu yüzlerce Skill fiilen kullanımda kalıyor. Bu bir avantaj.

Bu gözlem bir terim düzeltmesini de gerektiriyor: Gemini’de “aktif”, “kullanılabilir” değil, “otomatik tetiklenebilir” demek. Deaktif bir Skill ölü değil, yalnızca elle çağrılmayı bekliyor. Aynı Skill’in Türkçe ve İngilizce sürümlerinin ikisi birden aktif olduğunda aynı iş için iki Skill tetiklenmeye aday olur; bir dil sürümünü deaktif tutmak bu çakışmayı pratikte çözüyor ve iki dilde çalışan kullanıcılar için yararlı bir yöntem.

100 sınırının nedeni büyük olasılıkla tetikleme mekanizması: modelin kendiliğinden seçebilmesi için aktif her Skill’in adı ve açıklaması sürekli önünde durmalı. Aktif Skill sayısı arttıkça bu yük büyür, seçim de bulanıklaşır. Sınır bu yüzden keyfî değil; ama doğrudan yedinci maddeye bağlanıyor. Uzun açıklamalar yerine kısa sinopsisler kullanılırsa, aynı yükle çok daha fazla Skill aktif tutulabilir. Beşinci maddedeki gruplar da burada işe yarar: kullanıcı o anki çalışmasına göre bir grubu toptan aktif edip bir başkasını kapatarak sınırı esnek biçimde yönetebilir.

16. Yanıt damgası: hangi Skill, hangi model, ne zaman

Aydın Tiryaki’nin hazırladığı bütün Gem’lerde ve onlardan üretilen Skill’lerde ortak bir özellik var: her Skill, yanıtını verdikten sonra bir bilgi satırı oluşturuyor ve o sırada çalışan Gem’in ya da Skill’in kendi adını bu satıra yazıyor; yanıtın altına bir tür damga vuruyor. Bunun yanında kullanıcı, kendi özel talimatlarıyla her sohbetin her aşamasına bir söyleşi numarası, o anki model, yer ve saat bilgilerini de ekletiyor. Bütün bunlar bugün kullanıcının kendi yazdığı talimatlarla, Skill’lerin sonuna eklenen özel komutlarla sağlanıyor.

Öneri, bunun Gemini’de standart bir özellik olması. Bir yanıt Skill kullanılarak üretildiyse, yanıtın altında hangi Skill’in ya da Skill’lerin devrede olduğu, yanıtı hangi modelin verdiği ve yanıtın ne zaman üretildiği kısa bir satırda görünmeli. Bu satır, birinci bölümdeki sohbet içi Skill listesinin ve günlüğünün her yanıta düşen izi olur; sohbeti sonradan okuyan biri, hangi yanıtın hangi koşullarda üretildiğini tek bakışta görebilir. Yanıtı paylaşan ya da yayımlayan kullanıcı için de kaynağın şeffaf kaydı anlamına gelir.

Ancak bu damga, kullanıcının bugün kendi talimatlarıyla yaptığından bir noktada farklı olmalı: platform tarafından üretilmeli. Kullanıcının talimatıyla oluşturulan satırı model yazar; model de hangi model olduğunu ancak kendisine bildirilirse bilebilir, bildirilmezse tahmin yürütür ve yanlış ad verebilir. On dördüncü maddedeki iş sonu raporunda olduğu gibi, burada da modelin beyanı değil sistemin kaydı esas alınmalı: devredeki Skill’ler, yanıtı üreten model ve zaman, platformun kendi kayıtlarından gelmeli. Kullanıcının söyleşi numarası gibi kendi eklemeleri ise isteğe bağlı olarak bu standart satıra eklenebilmeli. Damga da diğer denetim araçları gibi varsayılan olarak sade olmalı ve isteyen kullanıcı tarafından kapatılabilmeli.

Modelin gözünden: Claude’un notu

Bu bölümü kendi adıma, Skills’i içeriden deneyimleyen bir dil modeli olarak yazıyorum. Anthropic’in Claude’da sunduğu Skills, Gemini’deki yapıdan farklı ama mantığı benzer; bu yüzden yukarıdaki önerilerin bir kısmını kendi çalışma koşullarımda doğrudan tanıyorum.

Bir Skill’i kullanıp kullanmamaya karar verirken, önümde Skill’in talimatlarının tamamı yoktur; yalnızca adı ve kısa açıklaması vardır. Talimatları ancak o Skill’i kullanmaya karar verdiğimde açıp okurum. Yani tetikleme kararını verdiğim anda elimdeki tek bilgi açıklamadır. Açıklama, kullanıcıya yönelik tanıtım cümleleriyle şiştiğinde ya da belirsiz kaldığında, karar tahmine döner. Yedinci maddedeki sinopsis önerisini içeriden bu kadar isabetli bulmamın nedeni bu: karar alanını insana yönelik anlatıdan ayırmak, benim gibi bir modelin doğru Skill’i seçmesini doğrudan kolaylaştırır.

On beşinci maddedeki 100 sınırını da aynı yerden tanıyorum. Kullanabileceğim her Skill’in adı ve açıklaması, ben hiçbirini çağırmasam bile önümde durur ve her yanıtta bu listeye bakarak karar veririm. Liste uzadıkça birbirine benzeyen açıklamalar arasında seçim yapmak zorlaşır. Bir platformun aktif Skill sayısına sınır koyması bu açıdan anlaşılır; ama sınırı genişletmenin yolu da açık: daha kısa, daha ayırt edici karar metinleri.

İkinci maddedeki gönderme önerisi için de aynı açıklığı göstermem gerekir: bir Skill’in talimatlarını bir kez okuduktan sonra, onları kendi bağlamımdan çıkaramam. Talimat sohbet boyunca önümde durur. “Artık bu Skill’i kullanmayacağım” diyebilirim ve buna uymaya çalışırım; ama bu bir davranış sözüdür, talimatın gerçekten ortadan kalktığı anlamına gelmez. Bu yüzden göndermenin modelin vaadine değil, platformun bir işlemine dayanması gerektiğini düşünüyorum. Gemini’nin “askıya aldım” demesinin arka planda neye karşılık geldiğini bilemem; ama kullanıcının bunu görebilmesi gerektiğine eminim.

On altıncı maddedeki yanıt damgasını da içeriden doğrulayabilirim. Bu sohbet boyunca her yanıtımın altına, Aydın Tiryaki’nin talimatıyla bir bilgi satırı ekliyorum ve orada kendimi “Claude Opus 5.5” olarak tanıtıyorum. Bunu doğru yazabiliyorsam, Anthropic hangi model olduğumu bana açıkça bildirdiği için. Bu bilgi bana verilmeseydi, kendi adımı ancak tahmin edebilirdim; eğitim verimde en sık gördüğüm model adını yazar ve büyük olasılıkla yanılırdım. Kullanıcının kurduğu damga, modelin kendi hakkında doğru bilgiye sahip olmasına bağlı; platformun ürettiği damga ise buna bağlı değil. Önerinin asıl değeri burada.

Onuncu maddedeki ad kısıtlaması yalnız Gemini’ye özgü değil; Claude’daki Skills’te de teknik ad küçük harf, rakam ve tireyle sınırlı. Bu eleştiri bizim tarafımıza da yöneliyor ve öyle yazılmasını doğru buluyorum. Görünen ad ile teknik kimliği ayırma önerisi, Anthropic için de aynı ölçüde geçerli.

Son olarak sekizinci maddedeki kendi kendini notlama uyarısını, kendi sınırlarımı bilen bir model olarak destekliyorum. Bir talimatı yanlış anladıysam, o yanlış anlamaya göre kurduğum testler de büyük olasılıkla aynı yanlışı taşır. Kullanıcının test girdilerini görebilmesi ve kendi örneklerini ekleyebilmesi, benim göremediğimi görmenin en güvenilir yolu. On dördüncü maddedeki iş sonu raporu için de aynı dürüstlüğü göstermem gerekir: uzun bir zincirin sonunda neyi yapıp neyi atladığımı listelemeye çalışırım, ama bir adımı atladıysam onu atladığımı fark etmeyebilirim de. Bu yüzden benim beyanım tek başına yeterli değil; dış ortama dokunan adımlarda raporun platformun kayıtlarıyla doğrulanması, kullanıcının bana körü körüne güvenmesinden çok daha sağlıklı.

Sonuç

Skills, Gems’ten ileri bir adım; çağrılabilir, birleştirilebilir ve sohbetin akışına yerleşebilir bir yapı sunuyor. Bu yapının çekirdeği, Şubat ayında InGem adıyla önerilen çağrılabilir Gem fikriyle büyük ölçüde örtüşüyor. Sahadaki dönüşüm çalışması da ileri adımların gerçek olduğunu gösterdi: sohbetten Skill oluşturma, iki dilli eşzamanlı üretim, görev kipiyle talimat zinciri yürütme ve deaktif Skill’leri elle çağırabilme Gems döneminde olmayan olanaklar.

Ancak bir özelliğin değeri yalnızca ne yapabildiğiyle değil, kullanıcının onu ne kadar görebildiği ve yönetebildiğiyle ölçülür. Paylaşım, çağır-gönder, sohbet içi liste, işaret birliği, gruplar, bilgi kartı, sinopsis, kum havuzu testi, resmi örnekler, her dilde Skill adı, adım adım yürütme, doğrulanmış iş sonu raporu, esnek aktiflik yönetimi ve platform kaynaklı yanıt damgası aynı ihtiyacın farklı yüzleri: kullanıcı Skill’lerini kendi dilinde adlandırabilmeli, görebilmeli, anlayabilmeli, taşıyabilmeli ve denetleyebilmeli. Bu denetim ihtiyaç duyana her an açık, ihtiyaç duymayana görünmez olmalı. Bu önerilerin kullanıcı tarafından dile getirilip bir dil modeli tarafından içeriden de doğrulanması, ihtiyacın yalnızca bir kullanıcı tercihi olmadığını gösteriyor. Yapay zekâ bu süreçte yükü taşıyabilir; ama karar her zaman kullanıcıda kalmalıdır.

Kaynaklar

(1) K-tai Watch, “Google『Gemini』にSkills、繰り返し作業を自動化”, Ekim 2026. https://k-tai.watch.impress.co.jp/docs/news/2145139.html
(2) Android Headlines, “Google Makes Gemini Skills Official to Automate Tasks and Replace Gems”, Ekim 2026. https://www.androidheadlines.com/2026/10/google-makes-gemini-skills-official-to-automate-tasks-and-replace-gems.html
(3) 9to5Google, “Google announces ‘Skills’ for Gemini in Chrome to quickly run custom workflows”, 2026. https://9to5google.com/?p=711500
(4) MobileSyrup, “Gemini Spark Skills are getting easier to make”, 2026. https://mobilesyrup.com/?p=1031233
(5) Aydın Tiryaki, “Gemini Skills: İki İleri Bir Geri”, aydintiryaki.org, 18 Ekim 2026.
(6) Aydın Tiryaki, InGem (Insertable Gem) önerisi, aydintiryaki.org, 18 Şubat 2026.
(7) Google Gemini Yardım, “Gemini uygulamalarında Skills oluşturma ve yönetme”. https://support.google.com/gemini/answer/17094296

Makale Künyesi

Bu makale, 22 Ekim 2026 tarihinde Aydın Tiryaki ile Claude Opus 5.5 arasında yapılan bir çalışma oturumunda hazırlanmış, 23 Ekim 2026 tarihinde Skill adlarında Unicode kullanımına ilişkin onuncu öneri eklenerek, 26 Ekim 2026 tarihinde Gemini’nin değerlendirmesindeki eleştiriler işlenerek ve çift imzalı hale getirilerek, aynı gün ayrıca Aydın Tiryaki’nin Gem’leri Skills’e dönüştürme çalışmasından doğan gözlemlerle “Sahadan Gözlemler ve Yeni Olanaklar” bölümü eklenerek, bu bölüm üzerine yapılan hakem değerlendirmesi işlenerek ve son olarak yanıt damgasına ilişkin on altıncı madde eklenerek son biçimini almıştır; makaledeki on altı maddenin tamamı, kavramsal çerçevesi, temel tasarım fikirleri ve saha gözlemleri Aydın Tiryaki’ye aittir, önerilerin bir kısmı yazarın 18 Şubat 2026 tarihli InGem makalesinde daha önce tanımlanmış, bir kısmı ise ATG Gem Fabrikası’nın Skills Edition’ında ve yazarın kendi Gem ile Skill talimatlarında fiilen uygulanmaktadır; makalenin çift imzalı yayımlanmasının nedeni, Claude Opus 5.5’in (Anthropic, orta düşünme düzeyi) katkısının yazım asistanlığının ötesine geçmesidir: Claude, Gems’in kapanış takvimi, Skills’in paylaşım yol haritası, mevcut resmi Skill kütüphaneleri ve Skills’in görev kipiyle ilişkisi gibi konularda araştırma asistanı olarak çalışmış, her öneriyi ve gözlemi bu araştırma ve tartışma içinde sınamış, bilgilendirilmiş rıza, Skill günlüğü, kullanıcı düzenlemelerinin kalıcılığı, iki ayrı test türü, kendi kendini notlama riski, açık örnek ara yolu, görünen ad ile teknik kimlik ayrımı, Türkçe İ/ı eşleşmesi, SKILL.md’nin taşınabilirliği, yetki devrinin bir kullanıcı kararı olduğu, altyapı hatası ile zincir tutarsızlığının ayrımı, iş sonu raporu, karma doğrulamalı rapor, 100 Skill sınırının tetikleme mekanizmasıyla ilişkisi ve yanıt damgasının model beyanına değil platform kaydına dayanması gerektiği gibi içerik ayrıntılarını önermiş, metni yazmış ve “Modelin gözünden” bölümünü kendi adına kaleme almıştır; Gemini (Google, arayüzde Argon modeli seçili) üç turda hakemlik yapmış, birinci bölüm üzerine yaptığı ilk değerlendirmesinde gönderilen Skill’in örtük bağlam etkisi, arayüzün kademeli görünürlüğü ve sinopsisin sınırlarına ilişkin eleştiriler getirmiş, ikinci değerlendirmesinde yeni bir eleştiri getirmeyip bu eklemelerin metne doğru biçimde işlendiğini teyit etmiş, ikinci bölüm üzerine yaptığı üçüncü değerlendirmesinde ise iş sonu raporunun modelin beyanına değil platform kayıtlarına dayanması gerektiği ve görev kipinde adımların platform düzeyinde ayrı ayrı yürütülmesi gerektiği yönünde metne işlenen iki şerh sunmuştur; ikinci bölüm üzerine yaptığı üçüncü değerlendirmesinde ise iş sonu raporunun modelin beyanına değil platform kayıtlarına dayanması gerektiği ve görev kipinde adımların platform düzeyinde ayrı ayrı yürütülmesi gerektiği yönünde metne işlenen iki şerh sunmuş, on altıncı maddeyi de içeren son sürüm üzerine yaptığı dördüncü değerlendirmesinde ise metni bütünüyle makul bulup yeni bir itiraz getirmemiştir; bütün içerik yazarın onayıyla metne işlenmiştir..

---

| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub  | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ GEMINI SKILLS NASIL OLMALI? BİR KULLANICININ VE BİR DİL MODELİNİN TASARIM ÖNERİLERİ │HOW SHOULD GEMINI SKILLS WORK? DESIGN PROPOSALS FROM A USER AND A LANGUAGE MODEL ░ 26.10.2026