Aydın Tiryaki & Claude Opus 5.5 & Gemini 4 Argon

Giriş

Yapay zekâ yordamları (Gemini’deki adıyla Skills) kısa sürede günlük çalışmamın merkezine yerleşti. “Skills” için Türkçede “yapay zekâ yordamı”, kısaca “yordam” karşılığını öneriyorum (1). Gemini’nin bu yapısı, başlangıçta düşündüğümden çok daha başarılı çalışıyor. Ama bir noktada platformun koyduğu bir sınıra dayanıyor: aynı anda en fazla 100 yordam aktif olabiliyor. Bu yazı o sınırı kaldırmayı istemiyor. Önerdiği şey, sınırın içinde kalarak bütün yordamlara erişmeyi sağlayacak bir yöntem.

Önerinin özü kısa: yordamlar bellekte tutulmasın, ama yolları gösterilsin. Yordam gelsin, işini yapsın, gitsin.

Konu bir yazıya sığmayacak kadar geniş. Bu nedenle bu metin, aynı konudaki olası yazıların ilki olarak tasarlandı. Bu yazıda Gemini ele alınıyor. Claude’daki durum ayrı bir yazıda incelenecek.

1. Bugün işleyen düzen

Önce neyin iyi çalıştığını belirtmek gerekiyor. Gemini’de bir konu söylendiğinde model, aktif yordamlar arasından en uygun olanı buluyor. Yordamın adı biliniyorsa doğrudan adıyla da çağrılabiliyor. Bir yordamın içinden başka bir yordam çağırmak, hatta o ikinci yordamın içinden üçüncüsünü çağırmak da sorunsuz çalışıyor. Bunların hiçbirinde bir aksaklık yaşamadım ve hepsi gündelik çalışmada gayet kullanışlı.

Yani bu yazının yordam mimarisinin kendisine bir itirazı yok. Konu, aktif listenin dışında kalan yordamlara nasıl ulaşılacağı.

2. Yüz sınırı

Google’ın geçiş açıklamasına göre istenildiği kadar yordam oluşturulabiliyor, ama aynı anda yalnızca 100’ü aktif olabiliyor. Sınır doluyken yeni bir yordamı aktif etmek için bir başkasını kapatmak gerekiyor (2)(3).

Bu sınırı kendi hesabımda bilerek zorladım, çünkü yazılı bir kural ile sistemin gerçek davranışı her zaman örtüşmeyebiliyor. Bazen bir şey söylenir ama gerçek değildir. Deaktif durumdaki yordamları aktif ederek de, yeni yordamlar ekleyerek de 100’ü geçmeyi denedim. Sistem hiçbir yoldan izin vermedi. Sonuç açık: oluşturma serbest, aktivasyon tavanlı.

3. Bir kullanıcının koleksiyonu

Gem döneminde yaklaşık 90 Türkçe Gem ve bunların her biri için birer İngilizce eş hazırlamıştım. Yordamlar gelince bu Gem’lerin hepsini kendim yordama dönüştürdüm (1). Bunun için Gem Fabrikası’nın yordam üretimine uyarlanmış sürümünü (Skills Edition) hazırladım ve bu sürümle Gem’leri tek tek çevirerek hepsinin SKILL.md dosyalarını oluşturdum. Bugün yazılı ve çalışır durumda yaklaşık 180 yordamım var. 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 (4). Gem Fabrikası’nı sorunsuz çalıştırmak için Argon modelini ve sohbet kipi yerine görev kipini kullanıyorum. Benim deneyimimde görev kipi, sohbet kipine göre çok daha kararlı çalışıyor.

İngilizce sürümlerin hepsini deaktif tutuyorum. Bu düzenin iki gerekçesi var. Birincisi, aktif sayıyı 100’ün altında tutmak. İkincisi, aynı işi yapan iki dil sürümünün birden tetiklenmeye aday olmasını önlemek. Bir dil sürümünü kapalı tutmak bu çakışmayı pratikte çözüyor. İngilizce sürümleri ise kullanmak isteyenlerle SKILL.md dosyaları olarak paylaşmak için saklıyorum. Ayrıca sitemde her yordam için birer Türkçe ve İngilizce makale ile bunları bir araya getiren paket sayfaları bulunuyor.

Ama 100 sınırı, yeni konularda yordam yazma olanağımı giderek daraltıyor. Yeni bir konuda yordam yazmam gerektiğinde, bu gidişle devam etme şansım kalmayacak.

4. Kendi optimizasyonum

Madem 100’lük bir sınır var, kendimi bu sınıra uyarlamaya çalışıyorum. Az kullandığım bazı Türkçe yordamları da deaktif tutuyorum. Birbirine benzer konulardaki Türkçe yordamları ise, ek menüler oluşturarak tek bir yordamda birleştirmeye başladım. Birleşik yordam her iki işi de aynı anda görebiliyor. Şimdiye kadar beş çifti birleştirdim ve yordam sayım beş azaldı. Bunlara yenileri de eklenecek.

Bu birleştirmelerin hepsi aynı nitelikte değil. Bir kısmı zaten birbirine yakın işleri bir araya getiriyor ve doğal olarak iyi bir düzenleme sayılabilir. Ama bir kısmını yalnızca sınır yüzünden yapıyorum. Bunların bir bedeli var: birleştirilen yordamın gövdesi büyüyor ve işlerden yalnızca birine ihtiyaç duyulduğunda ötekinin talimatları da yükleniyor. Bu yazıda önerdiğim dizin ve geçici aktivasyon düzeni olsaydı, bu zoraki birleştirmeleri yapmaz, o yordamları ayrı tutardım.

Aktif yordam sayısını hiçbir zaman 90’ın üzerine çıkarmamaya çalışıyorum. Çünkü çalışma sırasında aynı anda çok sayıda yordam hazırlandığında sayı 100’ü geçebiliyor. Bu yüzden yaklaşık on yordamlık bir çalışma boşluğu bırakmam gerekiyor.

5. “Aktif” ne demek?

Önceki yazımda belirttiğim gibi, Gemini’de “aktif” sözcüğü “kullanılabilir” anlamına gelmiyor. Anlamı, “kendiliğinden tetiklenebilir” (4). Deaktif bir yordam ölü değil. Sistemde duruyor, çalışmaya hazır ve yalnızca elle çağrılmayı bekliyor.

6. Erişim sorunu

Sorun tam burada başlıyor. Deaktif yordamlar @ işaretiyle açılan listede görünmüyor. Gözlemlerime göre elle çağrı, ancak yordamın tam adı bilinip doğrudan yazıldığında mümkün oluyor. Deaktif bir yordamı elle çağırıp kullanabildiğimi daha önce not etmiştim (4), ama o kadar çok deneme yaptım ki tam olarak nasıl yaptığımı şu anda hatırlamıyorum. Bu yazıyı hazırlarken yeniden denemek istedim, ancak Gemini’deki beş saatlik kotam dolmuştu. Bu davranışın ayrıntılarını ayrıca sınayacağım: deaktif yordamın listede hiç görünüp görünmediğini, tam ad yapıştırıldığında çağrının kabul edilip edilmediğini ve işaretsiz, düz metinle istendiğinde modelin onu bulup bulamadığını. Yüzlerce yordam arasında adı hatırlamak ya da ayarlar listesinde aramak ise ciddi bir zaman kaybı.

Gemini’nin kendi açıklamasına göre, bir yordam deaktif edildiği anda modelin önündeki yordam listesinden tamamen çıkıyor. Model artık onun ne adını ne de açıklamasını görebiliyor. Kullanıcı yordamı @ ile çağırdığında onu arka planda geçici olarak devreye sokan da model değil, arayüz katmanı. Bu açıklamayı yapacağım denemeyle doğrulayacağım.

Daha önemli bir sorun daha var: model ve diğer yordamlar deaktif bir yordama erişemiyor. Bunun benim için somut bir karşılığı var. Kendi sorunlarımı kendim çözmeye alışkın olduğum için bu konuda da bir çözüm geliştirdim: Yordam Ekosistemi adını verdiğim, gdn021 kodlu bir üst yordam (5). Ona bir konu verdiğimde, var olan yordamları tarıyor ve o konuda hangilerinin işime yarayacağını söylüyor. Bu yordamı yazmamın nedeni, 90 yordamlık aktif listede bile bazılarını hatırlamakta zorlanmam. Ama gdn021 yalnızca aktif yordamları tarayabiliyor. Deaktif durumdaki yaklaşık 90 yordam onun için kör nokta.

Bir yordama gidip onu okuyan ve onun hakkında makale yazan yordamlarım da var. Aynı mantıkla, deaktif yordamların hepsini tarayıp her biri için “hangi iş için çağrılır” bilgisini derleyen, bunu tek bir belgede toplayan ve yayımlayan bir yordamı da kolayca yazabilirim. Ama o yordam da deaktif olanlara ulaşamayacağı için, her seferinde önce onları aktif etmek, taramak, işi bitirmek ve yeniden kapatmak gerekiyor. 180 yordamlık bir koleksiyonda bu dolambaçlı bir angarya.

Bir başka yol da sitemdeki yordam makalelerini taratarak bilgi toplamak olabilir. Ama benim istediğim bu değil. Yordamların bilgisi platformun içinde zaten var. Kullanıcının bu bilgiyi dışarıdan, kendi sitesinden geri toplamak zorunda kalması gereksiz bir dolaşma.

Burada dikkat çekici bir tutarsızlık var. Kullanıcı deaktif bir yordamı elle çağırabiliyor, ama model aynı yordamın adına ve açıklamasına bile bakamıyor. “Sürekli taşımamak” ile “hiç erişememek” arasında geniş bir ara alan var ve şu anda bu alan boş. İsteğim tam olarak bu ara alanla ilgili: yordam deaktif olsun, platformun belleğinde yer tutmasın, ama ona kolayca ulaşmamız için bize yol göstersin.

7. Sınır neden haklı?

Bu yazı sınıra karşı çıkmıyor, çünkü sınırın iki geçerli gerekçesi var.

Birincisi yük. Modelin bir yordamı kendiliğinden seçebilmesi için, aktif her yordamın adı ve açıklaması hiçbiri kullanılmasa bile sürekli önünde durmak zorunda. Yapay zekânın “100’den fazla yordamı belleğimde tutmam” demesi bu açıdan tamamen haklı. Böyle bir yükü her kullanıcı için ayrı ayrı sınırsız büyütmek doğru olmaz.

İkincisi seçim kalitesi. Aktif listede birbirine benzeyen açıklamalar çoğaldıkça doğru yordamı seçmek zorlaşıyor. Bunu kendi çalışmamda da yaşadım. Model, o anda en yakın bulduğu ama işle ilgisi olmayan yordamları kendiliğinden çağırmaya başladı. Bu yüzden birçok sohbeti “hiçbir yordam çağırma” talimatıyla başlatmak zorunda kaldım.

Burada önemli bir noktayı da belirtmek gerekiyor. Gemini aktif yordamlar için zaten iki katmanlı bir düzenle çalışıyor: ad ve açıklama sürekli bağlamda durur, yordamın gövdesi ise ancak model onu çağırmaya karar verdiğinde yüklenir. Bu kademeli yükleme, yordamların ortak dosya biçimini tanımlayan açık Agent Skills standardının da temel ilkesi (6). Dolayısıyla bu yazının önerisi yepyeni bir mimari değil. Platformun bugün aktif yordamlar için kullandığı ilkenin, deaktif yordamlara da genişletilmesi.

8. Büyüme sorunu

Bugünkü 100 sınırı büyük olasılıkla platformun şu anki altyapısının kaldırabileceği düzeyi yansıtıyor ve zamanla genişleyecektir: 128, 256, 512. Ama kullanıcıların kendi yazdığı yordamların sayısı da aynı ölçüde, belki üstel bir hızla artacak. Yordamlar biriktikçe ve kapasite bu birikime yetişemedikçe, kullanıcılar ellerindeki her şeyi sürekli kısıtlamak zorunda kalacak.

Sorun şöyle özetlenebilir: yapay zekânın olanakları sınırlı, kullanıcıların istekleri sınırsız. Kapasiteyi büyütmek tek başına bu farkı kapatmaya yetmez.

9. Birinci öneri: Silik liste

En basit iyileştirme arayüzde yapılabilir. @ ya da / yazıldığında açılan listede deaktif yordamlar da görünsün, ama aktif olanlardan ayırt edilebilecek şekilde silik olarak. Kullanıcı “şu anda aktif değil, ama ben onu şimdi kullanmak istiyorum” dediği yordamı, yüzlerce yordam arasında başka bir listede aramak yerine doğrudan oradan seçebilsin.

Bu önerinin modele hiçbir maliyeti yok. Arayüzdeki liste modelin bağlamına girmiyor, yalnızca ekranda duruyor. Sınırın gerekçesi modelin yükü ise, ekrandaki listeyi kısıtlamak için bir gerekçe kalmıyor.

10. İkinci öneri: Yordam Dizini

Asıl öneri, platformun kendiliğinden tuttuğu ve güncellediği bir Yordam Dizini.

Dizinin özellikleri şunlar:

• Kapsamı: Kullanıcının yüklediği bütün yordamlar, aktif olanlar da aktif olmayanlar da. Kapsam platform kütüphanelerini de içine alacak şekilde genişletilebilir (bkz. 13. bölüm).
• Hazırlanışı: Platform yapay zekânın kendi yeteneklerini kullanarak dizini iyi dizinlenmiş ve sıkıştırılmış bir belge olarak oluşturur. Bu sayede bilgilere çok daha derli toplu ve hızlı erişilebilir.
• Güncelliği: Dizin yordam kayıtlarının kendisinden türetildiği için, bir yordam eklendiğinde, değiştirildiğinde ya da silindiğinde kendiliğinden güncellenir. Dizinde her zaman en son bilgi bulunur. Kullanıcının elle tuttuğu bir katalog eskir; platformun türettiği dizin eskimez.
• Yeri: Kullanıcı dizinin nerede durduğuyla, nasıl saklandığıyla hiç ilgilenmez. Dizin platformun kendi iç sisteminde, Skill Ecosystem adlı özel bir yordam olarak tutulur (bkz. 12. bölüm). Böylece hızlı erişilir, kotaya ya da dosya izinlerine bağlı kalmaz ve kullanıcı tarafından yanlışlıkla silinip bozulamaz. Kullanıcıya şeffaflık ve yedek sağlamak için, isteğe bağlı olarak kendi alanına, örneğin Drive’ına, otomatik bir ayna kopya bırakılabilir. Dizinin ayrıntılı bölümü bağlamda durmaz; her turda modelin önüne konmaz, yalnızca istendiğinde okunur. Çok kısa bir özeti ise koleksiyonun büyüklüğüne göre sürekli bağlamda kalabilir (bkz. 11. bölüm).

Her yordam için dizinde asgari olarak şu bilgiler yer alır: yordamın tam adı (çağırmak için), ne işe yaradığını anlatan kısa bir sinopsis, durumu (aktif ya da aktif değil) ve varsa başka dildeki eşi. İsteğe bağlı olarak konu grupları ve anahtar sözcükler de eklenebilir.

Kullanım basit. Kullanıcı “şu konuda bir yordam arıyorum” ya da “deaktif durumdakiler arasından bana şu işi yapacak bir yordam bulur musun?” dediğinde model dizine bakar ve şöyle bir cevap verir: “Bu iş için şu yordamlar aktif, şunlar aktif değil. Dilediğinizi kullanabilirsiniz.” Uygun yordam deaktifse, model onun tam adını verir ve isterseniz yükleyebileceğini söyler. gdn021 kodlu Yordam Ekosistemi yordamımın bugün yalnızca aktif yordamlar için yaptığı işi, dizin bütün koleksiyon için yapmış olur.

Dizin, kişisel talimatların bir tür eşi gibi düşünülebilir. Kişisel talimatlar her zaman modelin önünde durur. Dizin ise başka bir yerde saklanır, sürekli bellekte tutulmaz ve yalnızca gerektiğinde açılır.

11. Dizinin katmanları: Kısa dizin, uzun dizin ve küme başlıkları

Dizin tek parça olmak zorunda değil. Koleksiyonun büyüklüğüne göre iki ya da üç katmanlı hazırlanabilir. Temel iki katman şunlar:

• Kısa dizin: Deaktif her yordam için yalnızca tam ad ve birkaç sözcüklük bir etiket. Hızlı arama burada yapılır.
• Uzun dizin: Deaktif yordamlar için ayrıntılı bilgiler: sinopsis, dil eşi, konu grupları, anahtar sözcükler. Bu katman bağlamda durmaz, yalnızca ayrıntılı arama gerektiğinde okunur.

Aktif yordamlar ise bugünkü gibi ad ve açıklamalarının tamamıyla bağlamda kalabilir. Gerekirse aktif yordamlara ayrılan alan biraz daraltılarak, deaktif yordamların kısa bilgilerini içeren bu dizin alanına yer açılabilir. Böylece yapı üç kademeye ayrılır:

1. Aktif yordamlar: Ad ve açıklamanın tamamı, sürekli bağlamda.
2. Kısa dizin: Deaktif yordamların adı ve etiketi, sürekli bağlamda.
3. Uzun dizin: Deaktif yordamların ayrıntılı bilgileri, yalnızca istendiğinde.

Küçük bir koleksiyonda maliyet tarafı ikna edici. Gemini’de bir yordam açıklaması 1024 karaktere kadar çıkabiliyor. Kısa dizindeki bir kayıt ise belki 40–60 karakter. 80–90 deaktif yordamın kısa kaydı, yalnızca birkaç aktif yordamın açıklaması kadar yer tutar. Yani sürekli yük çok az artar, ama model artık deaktif yordamların varlığından haberdar olur.

Ancak bu hesap 80–90 deaktif yordam için geçerli. Önerinin hedefi sınırsız yordam olduğuna göre, örneğin 2.000 deaktif yordamlık bir koleksiyonda kısa dizin tek başına 100.000 karakterin üzerine çıkar. Bu hem bir yük hem de bir dikkat dağıtıcı olur. Model her turda kısa etiketler arasında seçim yapmaya çalışırken, az bilgiye dayandığı için yanlış öneriler artar ve “şu yordamı açayım mı?” soruları kullanıcıyı bunaltabilir. Bu yüzden düzen koleksiyonun büyüklüğüne göre değişmeli:

• Küçük koleksiyonda: Kısa dizin sürekli bağlamda durur.
• Belli bir eşiğin üzerinde: Bağlamda yalnızca küme başlıkları durur. Örneğin “deaktif koleksiyonda makale editörleri, futbol yordamları ve İngilizce eşler bulunuyor” gibi. Kısa dizin de uzun dizin gibi bağlam dışında bekler ve model ancak bir küme başlığı işle ilgili göründüğünde onu okur.

Böylece büyük koleksiyonlarda yapı dört kademeye çıkar: aktif yordamlar, küme başlıkları, kısa dizin ve uzun dizin. Bu kademelenme sanal bellekteki çok katmanlı sayfa tablolarına karşılık geliyor (bkz. 20. bölüm).

Kısa kaydın yalnızca addan oluşması her zaman yeterli fikir vermeyebilir. Bazen başlık yeterince fikir verir, ama Gemini’de yordam adları dar bir karakter kümesiyle sınırlı. Türkçe karakter kullanılamayan, tireli kısa adlar çoğu zaman ne iş yaptıklarını tam anlatmıyor (4). Bu yüzden kısa kaydın “ad + birkaç sözcüklük etiket” olması daha güvenli. Bu etiket, önceki yazımda önerdiğim sinopsis alanının en kısa hâli.

Kısa dizin ya da küme başlıkları sürekli bağlamda olduğu için yeni bir olanak da doğuyor: model, kullanıcı sormadan da “bu iş için deaktif durumdaki X yordamı uygun, geçici olarak açayım mı?” diye öneride bulunabilir. Ancak açma kararı her zaman kullanıcıda kalır. Model önerir, açmaz. İlgisiz yordamların kendiliğinden çağrılması deneyimi (bkz. 7. bölüm), bu sınırın neden gerekli olduğunu gösteriyor.

12. Dizinin taşıyıcısı: Skill Ecosystem

Kullanıcı olarak bu dizinle hiç uğraşmamamız gerekiyor. Belgenin nerede duracağı, nasıl saklanacağı, ne zaman güncelleneceği tamamen platformun işi olmalı. Bunun en kolay yolu, dizinin yeni bir mekanizma olarak değil, sistemin zaten tanıdığı bir biçimde tutulması: bir SKILL.md olarak.

Önerim şu: platform, kullanıcının bütün yordamları için kendiliğinden özel bir yordam yazar ve günceller. Bu yordamın adı Skill Ecosystem olur, dosyası da örneğin skill-ecosystem.md. Platform onu, diğer SKILL.md dosyalarını nasıl okuyup çalıştırıyorsa öyle, gerektiğinde okur ve çalıştırır. Kullanıcı da diğer yordamlarını nasıl görebiliyorsa onu da öyle görebilir.

Adı bilerek İngilizce öneriyorum. Türkçeye her kullanıcı kendi tercihine göre çevirebilir; ben “yordam ekosistemi” diyorum. Bu ad benim gdn021 kodlu Yordam Ekosistemi yordamımla aynı kökten geliyor ve bu bir rastlantı değil: gdn021, platformdan istediğimiz şeyin kullanıcı tarafından, yalnızca aktif yordamlarla sınırlı olarak kurulmuş bir ön örneği. Karışmaması için bu yazıda platformun önerilen yordamına Skill Ecosystem, benim yordamıma gdn021 diyorum.

Bu çözümün en güçlü yanı, önceki bölümde tanımlanan katmanların bir yordamın zaten var olan yapısına birebir oturması:

• Yordamın açıklaması (sürekli bağlamda) → küme başlıkları ya da kısa bir özet
• Yordamın gövdesi (çağrıldığında yüklenir) → kısa dizin
• Yordamın referans dosyaları (gerektiğinde okunur) → uzun dizin

Yani platformun yeni bir katman icat etmesi gerekmiyor. Bugünkü kademeli yükleme düzeni dizini olduğu gibi taşıyabiliyor (bkz. 7. bölüm). Tek yeni iş, bu özel yordamın platform tarafından kendiliğinden yazılması ve güncellenmesi.

Burada 11. bölümdeki hesapla ilgili bir ayrıntıyı netleştirmek gerekiyor. Yük açısından bir sorun yok: 80–90 deaktif yordamın kısa dizini yaklaşık 4.500 karakter tutar ve bu, birkaç aktif yordamın açıklaması kadardır. Sınır yükte değil, alanın kapasitesinde. Gemini’de bir yordamın açıklaması 1024 karakterle sınırlı ve 4.500 karakterlik bir kısa dizin tek bir açıklama alanına sığmaz. Bunun iki çözümü var:

• Geniş açıklama alanı: Skill Ecosystem bir kullanıcı yordamı değil, sistem yordamı olduğu için platform ona küçük bir koleksiyonun kısa dizinini taşıyacak kadar geniş bir açıklama alanı tanıyabilir. Bu da yalnızca dört beş aktif yordamın açıklaması kadar yer demek.
• Gövdeye taşıma: 1024 karakter sınırı korunur. Açıklamada her durumda yalnızca küme başlıkları ya da kısa bir özet durur, kısa dizin ise yordamın gövdesine taşınır.

Böylece 11. bölümdeki küçük koleksiyon düzeni birinci yolla, büyük koleksiyon düzeni ikinci yolla aynı yordamın içinde karşılanmış olur.

Skill Ecosystem’in iki kuralı daha olmalı:

• Salt okunur: Kullanıcı Skill Ecosystem’i görebilir, ama düzenlemez. İçerik yordam kayıtlarından kendiliğinden üretildiği için, elle yapılan bir değişiklik bir sonraki güncellemede silinir ya da dizin gerçek durumla çelişir. Bir yordamın dizindeki tanımı beğenilmiyorsa, düzeltme o yordamın kendi açıklamasında yapılır ve dizine kendiliğinden yansır.
• Yuva harcamaz: Skill Ecosystem kullanıcının 100 yuvasından birini harcamaz, platformun sistem yordamı olarak sayılır.

13. Dizinin kapsamını genişletmek: Platform kütüphaneleri

Dizin yalnızca kullanıcının kendi yazdığı yordamlarla sınırlı kalmamalı. Gemini’de Keşfet bölümünün “Gemini’yi özelleştirin” kısmında, günlük araçlar ve işletmeler için araçlar gibi başlıklar altında Google’ın örnek olarak hazırladığı yordamlar bulunuyor. Bunlar da kullanıcı açısından deaktif durumda; kullanıcı dilerse oradan aktif hâle getirebiliyor. Yani durumları, benim deaktif tuttuğum yordamlarımla aynı. O hâlde bu yordamlar da özellikleriyle birlikte dizine dahil edilebilir.

Bu yalnızca bir başlangıç. Platform kütüphaneleri büyüdükçe öneri daha da önem kazanacak. Claude’da bugün oldukça geniş yordam kütüphaneleri bulunuyor. Özelleştirme sayfasında yeni eklenenler, en çok yüklenenler ve kategoriler altında çok sayıda yordam var; örneğin mühendislik başlığı altında gerçekten ciddi bir kütüphane oluşmuş durumda. Gemini’de de benzer kütüphanelerin oluşması büyük olasılık. Claude’daki durumu bu dizinin bir sonraki yazısında ayrıntılı olarak ele alacağım.

Öneri şu: her kütüphanenin kendi dizini olur. Kullanıcı “bu konuda ne var?” diye sorduğunda model önce kullanıcının kendi dizinine, ardından kütüphane dizinlerine bakar ve sonuçları birlikte sunar: “Sizin yordamlarınız arasında şunlar var; platform kütüphanesinde de şu örnekler bulunuyor.”

Bu genişlemenin üç ayrıntısı var:

• Kaynak etiketi: Dizindeki her kayıt nereden geldiğini göstermeli: kullanıcının kendi yordamı mı, platformun kütüphanesinden mi, ileride paylaşım açılırsa başka bir kullanıcıdan mı. Başkasına ait bir yordamı ilk kez açmak, kendi yordamını açmaktan farklı bir adımdır. Kullanıcı onun ne yaptığını ve neye eriştiğini görerek karar vermelidir (4). “Model önerir, açmaz” ilkesi burada daha da önem kazanır. Kaynak etiketi aynı zamanda bir ad alanı gibi çalışır: kullanıcının kendi yazdığı bir yordam ile kütüphanedeki bir yordam aynı adı taşısa bile karışmaz. Aramada ise her zaman önce kullanıcının kendi yordamları gelir, kütüphane sonuçları onların ardından sunulur.
• Paylaşılan dizin: Kullanıcının kendi dizini kişiseldir, ama bir kütüphanenin dizini bütün kullanıcılar için aynıdır. Platform onu bir kez hazırlar ve herkes aynı dizine bakar. Bu yüzden kütüphane dizininin kullanıcı başına ek maliyeti yok denecek kadar azdır.
• Bağlamda durmaz: Kütüphaneler binlerce yordama ulaşabileceği için kütüphane dizinleri sürekli bağlamda tutulmaz. En fazla küme başlıkları durur. Kütüphane dizini ancak kullanıcı sorduğunda ya da kendi dizininde uygun bir yordam bulunamadığında okunur (bkz. 11. bölüm).

14. Üçüncü öneri: Geçici aktivasyon

Dizinden bulunan yordam aktif değilse, platform onu iş için geçici olarak aktif eder. Yordam kullanılır ve iş bitince yeniden deaktif olur. Kalıcı aktif listeye hiç girmez.

Böylece bilgi kademeli ve yalnızca ihtiyaç anında belleğe giriyor:

1. Önce dizine bakılır. Hızlı arama kısa dizinde (büyük koleksiyonlarda önce küme başlıklarında), gerekirse ayrıntılı arama uzun dizinde yapılır. Uzun dizin hiçbir zaman sürekli bellekte değildir; yalnızca gerektiğinde incelemesi için yapay zekâya söylediğimiz bir başvuru kaynağıdır.
2. Erişilen bilgiye göre o yordamı kullanmaya karar verilir. Yordam aktif edilerek geçici olarak belleğe alınır, kullanılır ve iş bitince deaktif edilerek bellekten çıkarılır.

Aktivasyon ve deaktivasyon modelin değil yazılımın işi; büyük bir bağlam gerektirmeden otomasyonla yapılabiliyor. Bu nedenle bu geçişlerin kendisi modele yük olmaz. Yük yalnızca yordamın kullanıldığı süre boyunca ödenir.

Bunun kullanıcı açısından önemli bir sonucu var. Deaktif bir yordama, modelin belleğinde yer tutmadan ve ona yük olmadan, dilediğimiz an ulaşabilirsek, aktif olmayan her ihtiyaç için çekinmeden yordam yazabiliriz. Yordam gelir, işini yapar ve gider.

15. Yuva meselesi

Geçici aktivasyonun 100 sınırıyla ilişkisi iki şekilde kurulabilir.

• Temel seçenek: Kullanıcı, 100 yuvanın bir kısmını geçici kullanım için boş bırakır. Aynı anda 10 deaktif yordam kullanmak isteyen 10, 20 kullanmak isteyen 20 yuva ayırır. Bu tür bir kural kolayca kabul edilebilir bir sınırlamadır. Altyapıda hiçbir değişiklik gerektirmez ve bugünkü kapasiteyle çalışır. Platform “kapasitemiz yetmez” diye itiraz edemez, çünkü istenen şey yeni bir yük değil, mevcut yuvaların daha akıllıca kullanılması. Bu seçeneğin bir benzerini bugün zaten kendim uyguluyorum: aktif sayıyı 90’da tutarak yaklaşık on yuvalık bir çalışma boşluğu bırakıyorum (bkz. 4. bölüm).
• Cömert seçenek: Platform yine 100 yuva hakkını tanır, ama geçici aktivasyonları “nasıl olsa geçici olarak kullanılacak” diyerek 100’ün dışında, bonus olarak sayar. Bu tamamen platformun takdirinde. Atalarımızın dediği gibi, ağanın eli tutulmaz.

16. Geçici aktivasyonun süresi

Geçici aktivasyonun ne kadar süreceğine kullanıcı karar verir. İki seçenek var:

• Tek iş: Görev tamamlandığında yordam deaktif olur.
• Sohbet boyunca: Yordam o sohbet bitene kadar aktif kalır ve gerektiğinde yeniden çağrılabilir.

Kendi deneyimimde çoğu zaman tek iş seçeneği daha pratik. Bir sohbette yordamın sürekli açık kalmasına genellikle gerek olmuyor. Bu yüzden varsayılan “tek iş” olmalı. Kullanıcıya önce “açayım mı?”, ardından “ne kadar süreyle?” diye iki ayrı soru sormak gereksiz bir sürtünme yaratır. Model uygun yordamı bulduğunda tek bir onay ister: “X yordamını bu iş için geçici olarak çalıştırayım mı? Sohbet boyunca açık kalmasını isterseniz belirtebilirsiniz.” Böylece iş tek onayla yürür, seçim yine kullanıcıda kalır. Aktivasyonun ve deaktivasyonun yöntemi de bu seçime göre belirlenir.

17. Deaktivasyonun gerçek anlamı

Burada teknik bir ayrımı doğru koymak gerekiyor. Aynı sohbet içinde okunmuş bir talimat, yordam deaktif edilse de o sohbetin bağlamında kalır, yani model onu “unutamaz.” Bu nedenle “tek iş” seçeneğindeki deaktivasyon bir bellek temizliği değil, davranışsal bir kapanış. Platform iş bitince modele “bu yordamın görevi tamamlandı, talimatlarını artık uygulama” diye bir işaret verir ve yordam sohbetin geri kalanına karışmaz. Sonraki sohbetlerde ise hiç yük oluşturmaz.

Bu kapanışın bugün bile mümkün olduğunu kendi denemelerimde gördüm. İlk deneme yazımda aynı sohbette iki ayrı yordamı peş peşe çalıştırmayı başardığımı kaydetmiştim (7). Daha sonra Gemini’de ilişkili altı yordamı aynı sohbette sırayla çalıştırdım, ardından onları askıya alıp yeni bir yordam yükledim. Gemini’nin sözlü bir istekle yordamı askıya alabildiğini önceki yazımda da not etmiştim (4). Bu, Şubat 2026’da önerdiğim InGem yaşam döngüsünün, yani “çağrıl, işini yap, çekil” düzeninin, uygulamada işlediğini gösterdi (8). Bugün “tamam, artık bunu gönder” dendiğinde yordam bağlamdan tamamen çıkmıyor, ama askıya alınabiliyor. Askıya alınan yordam bir kez gelmiş olsa da sohbetin geri kalanında artık işe karışmıyor. Önerilen düzende ise yordam deaktif olduğunda, işini bitirmiş olarak kendiliğinden çekilmiş olacak. Mimari geliştikçe gerçek bir boşaltma da mümkün olacaktır.

18. Aktif liste: Sık kullanılanlar

Dizin ve geçici aktivasyon olunca, aktif listenin işlevi değişir. Bugün kullanıcı 100 yuvayı doldurmak zorunda hissediyor, çünkü yuva dışında kalan yordam fiilen kayboluyor. Dizinle birlikte aktif tutmak “erişilebilir kalmak” için değil, yalnızca “sık kullanılan” için gerekli olur. Aktif liste, insanların sürekli açık tutmak istediği bir sık kullanılanlar listesine dönüşür. İnsanlar büyük olasılıkla 100’ü bırakıp en çok kullandıkları 10–20 yordamla yetinir, diğerlerini yalnızca gerektiğinde kullanır.

Kazanç iki yönlü. Platform açısından aktif liste kısaldıkça her turdaki yük azalır. Kullanıcı açısından model doğru yordamı daha isabetli seçer ve ilgisiz yordamların kendiliğinden tetiklenmesi azalır. Böylece platform 100 sınırını genişletmeye bile gerek duymadan kullanıcıların talebini fiilen azaltmış olur.

19. Eski bir soru: Sınırsız istek, sınırlı olanak

Bu sorun yeni değil. Toplumsal ve ekonomik alanda, hangi açıdan bakılırsa bakılsın, sınırsız isteklerin sınırlı olanaklarla karşılanması temel bir sorudur ve bunun her alanda bir değerlendirme yöntemi vardır. Lionel Robbins 1932’de iktisadı tam olarak bu ilişki üzerinden tanımlamıştı: sınırsız amaçlar ile alternatif kullanımları olan kıt araçlar arasındaki ilişki (9). Bu yazının önerisi aynı soruyu yapay zekâ kaynakları için soruyor: yapay zekânın kapasitesi ve olanakları ile insanların istekleri arasındaki dengeyi, sınırları zorlamadan ikinci yollarla sağlayacak bir optimizasyon yöntemi.

20. Bilinen bir çözüm: Sanal bellek

Bilgisayar biliminde bu sorunun onlarca yıldır işleyen bir çözümü var: sanal bellek. Fiziksel bellek sınırlıdır, programların ihtiyacı ondan büyüktür. Çözüm belleğin büyümesini beklemek değil; ihtiyaç duyulan bölümü o anda belleğe almak ve işi bitince geri yazmaktır. Bu fikir ilk kez 1962’de Manchester’daki Atlas bilgisayarında uygulandı (10). 1970’lerin başında da IBM ana bilgisayarlarıyla yaygınlaştı.

Önerinin sanal bellekle eşleşmesi neredeyse birebir:

• Sayfa tablosu → Yordam Dizini, yani Skill Ecosystem (neyin nerede olduğunu bilir, içeriği taşımaz)
• Çok katmanlı sayfa tablosu → küme başlıkları, kısa dizin ve uzun dizin
• Paylaşılan kütüphaneler → platform kütüphanelerinin herkes için tek dizini
• Sayfayı belleğe alma → geçici aktivasyon
• Sayfayı geri yazma → iş bitince deaktivasyon
• Fiziksel bellek sınırı → 100 aktif yordam

Çok katmanlı sayfa tabloları da tam bu yazıdaki ölçeklenme sorunu yüzünden ortaya çıktı. Bellekler büyüdükçe tek parça sayfa tabloları da şişti. Çözüm, tablonun yalnızca üst katmanını sürekli bellekte tutmak ve alt katmanları gerektiğinde okumaktı. Büyük koleksiyonlarda yalnızca küme başlıklarının bağlamda durması aynı mantığı izliyor.

İşletim sistemlerindeki paylaşılan kütüphaneler de 13. bölümdeki öneriye karşılık geliyor. Birçok programın kullandığı bir kütüphane bellekte tek kopya olarak durur ve her program kendi kopyasını taşımak yerine o tek kopyayı kullanır. Platform kütüphanelerinin dizini de böyle: bir kez hazırlanır ve bütün kullanıcılar aynı dizine bakar.

Peter Denning’in 1968’de ortaya koyduğu çalışma kümesi kavramı da bu tabloya uyuyor (11). Çalışma kümesi, bir programın belli bir zaman diliminde gerçekten kullandığı sayfalardır. İyi bir bellek yönetimi her şeyi bellekte tutmaya çalışmaz, yalnızca çalışma kümesini tutar. Kullanıcının sık kullandığı 10–20 aktif yordam, tam olarak onun çalışma kümesi.

Bu benzetme önerinin denenmemiş bir fikir olmadığını gösteriyor: işlediği kanıtlanmış bir ilke yeni bir alana uygulanıyor.

21. Ara çözüm mü, kalıcı tasarım mı?

Öneri ilk bakışta, kapasite yetişene kadar başvurulacak bir ara çözüm gibi görünebilir. Ama kapasite yetişse de gerekli kalacak. Çünkü sorun yalnızca altyapının kaldırabileceği yük değil, seçimin kalitesi de. Aktif yordam sınırı 512’ye çıksa bile 512 yordamın hepsinin aynı anda kendiliğinden tetiklenmeye aday olması istenmez. Platform kütüphaneleri binlerce yordama ulaştığında bu daha da açık hâle gelir. Sanal bellek de bellekler büyüdükçe ortadan kalkmadı, tersine standart hâline geldi.

Dolayısıyla Yordam Dizini ve geçici aktivasyon bir geçiş dönemi çaresi değil, yordam mimarisi için kalıcı olarak daha iyi bir tasarım.

22. Davranış kullanıcıdan, uygulama platformdan

Bu öneriler bugünkü sisteme göre tasarlandı. Ama tanımladıkları şey sistemin nasıl davranması gerektiği; bunun mimaride ve arayüzde nasıl gerçekleştirileceği platformun işi. Madem yordamları en verimli ve en yaygın biçimde kullanmak için bir yöntem geliştiriyoruz ve yapay zekânın olanakları sınırlı, yapay zekâ mimarisi de bu yönde geliştikçe gerekli değişiklikler hem altyapıda hem arayüzde yapılacaktır.

Bu ayrım benim yazılıma her zaman baktığım açıyla da örtüşüyor: algoritma kullanıcınındır, platform yalnızca araçtır. Öneri algoritmayı ortaya koyuyor, uygulama ayrıntısı platforma kalıyor. Bu sayede öneri bugünkü sistemde ayakta duruyor ve mimari değiştiğinde eskimiyor.

23. Sonuç

Gemini’nin 100 aktif yordam sınırı haklı gerekçelere dayanıyor ve bu yazı onu kaldırmayı istemiyor. İstediği, sınırın dışında kalan yordamlara giden yolun açılması. Önerilen yapı üç parçadan oluşuyor: arayüzde deaktif yordamları da gösteren silik bir liste; platformun Skill Ecosystem adlı özel bir yordam olarak kendiliğinden yazıp güncellediği, koleksiyonun büyüklüğüne göre kademelenen, ayrıntılı katmanı yalnızca istendiğinde okunan ve platform kütüphanelerini de kapsayabilen bir Yordam Dizini; ve dizinden bulunan yordamı, varsayılan olarak tek iş için, kullanıcı isterse sohbet boyunca geçici olarak aktif eden bir mekanizma.

Öneri yeni bir mimari icat etmiyor. Platformun aktif yordamlar için bugün kullandığı kademeli yükleme ilkesini deaktif yordamlara ve kütüphanelere genişletiyor. Dizin bile ayrı bir mekanizma değil, bir SKILL.md. Kullanıcı bu dizinle hiç uğraşmıyor, yalnızca istediğinde ona bakıyor. Bu yapının üç kazancı var. Yapay zekânın kaynakları en verimli biçimde kullanılır. Sınır korunduğu için platform açısından bir sorun çıkmaz. Kullanıcı ise kendi yordamlarına ve platform kütüphanelerine sınırsız biçimde erişme olanağı kazanır ve yordamlarını sınır yüzünden zoraki biçimde birleştirmek zorunda kalmaz. Aktif liste bir sık kullanılanlar listesine dönüşür, modelin sürekli yükü azalır ve seçim isabeti artar. Sınırlı bellekle sınırsız yordam.

Kaynaklar

(1) Aydın Tiryaki, “Özel Asistanlardan Ortak Standarda: Gem’ler, GPT’ler, Projeler ve Yapay Zekâ Yordamları (Skills)”, aydintiryaki.org, 27 Ekim 2026. https://aydintiryaki.org/2026/10/27/ozel-asistanlardan-ortak-standarda-gemler-gptler-projeler-ve-yapay-zeka-yordamlari-skills/

(2) Pasquale Pillitteri, “Gemini Launches Skills, and Gems Disappear in November”, 2026. https://pasqualepillitteri.it/en/news/19145/gemini-skill-gems-novembre-en

(3) Prompt Optimizer, “How to Use Gemini Skills (and Move Your Gems Over)”, 14 Ekim 2026. https://promptoptimizer.tools/blog/how-to-use-gemini-skills

(4) Aydın Tiryaki & Claude Opus 5.5, “Gemini Skills Nasıl Olmalı? Bir Kullanıcının ve Bir Dil Modelinin Tasarım Önerileri”, aydintiryaki.org, 26 Ekim 2026. https://aydintiryaki.org/2026/10/26/gemini-skills-nasil-olmali-bir-kullanicinin-ve-bir-dil-modelinin-tasarim-onerileri/

(5) Aydın Tiryaki, “Yordam Ekosistemi (Gemini Skills)”, aydintiryaki.org, 4 Kasım 2026. https://aydintiryaki.org/2026/11/04/yordam-ekosistemi-gemini-skills/

(6) Agent Skills, açık standart belgesi. https://agentskills.io

(7) Aydın Tiryaki, “Gemini Skills: İki İleri Bir Geri”, aydintiryaki.org, 18 Ekim 2026. https://aydintiryaki.org/2026/10/18/gemini-skills-iki-ileri-bir-geri/

(8) Aydın Tiryaki, “Yapay Zeka Etkileşiminde Yeni Bir Standart Önerisi: InGem (Insertable Gem) Modeli”, aydintiryaki.org, 18 Şubat 2026. https://aydintiryaki.org/2026/02/18/yapay-zeka-etkilesiminde-yeni-bir-standart-onerisi-ingem-insertable-gem-modeli/

(9) Lionel Robbins, An Essay on the Nature and Significance of Economic Science, Macmillan, Londra, 1932.

(10) T. Kilburn, D. B. G. Edwards, M. J. Lanigan, F. H. Sumner, “One-Level Storage System”, IRE Transactions on Electronic Computers, EC-11(2), 1962.

(11) Peter J. Denning, “The Working Set Model for Program Behavior”, Communications of the ACM, 11(5), 1968, s. 323–333.

Künye

Yazarlar: Aydın Tiryaki & Claude Opus 5.5 (Anthropic) & Gemini 4 Argon (Google, orta düşünme düzeyi).

Aydın Tiryaki: Önerinin fikri ve kavramsal tasarımı (silik liste, Yordam Dizini, kısa ve uzun dizin katmanları, dizinin Skill Ecosystem adlı bir SKILL.md olarak tutulması, dizinin platform kütüphanelerini kapsayacak şekilde genişletilmesi, geçici aktivasyon, yuva seçenekleri, kullanım süresinin kullanıcıya bırakılması, aktif listenin sık kullanılanlara dönüşmesi, sınırsız istek ile sınırlı olanak çerçevesi), Yordam Ekosistemi (gdn021) ile kendi optimizasyon uygulamaları, Gemini ve Claude kütüphanelerine dair gözlemler, saha gözlemleri ve deneyler.

Claude Opus 5.5: Yazım, kaynak araştırması ve kavramsal tartışma. Metne giren kendi değerlendirmeleri: sanal bellek, çok katmanlı sayfa tablosu, paylaşılan kütüphane ve çalışma kümesi benzetmeleri; deaktivasyonun “davranışsal kapanış” olarak tanımlanması; önerinin ara çözüm değil kalıcı tasarım olduğu görüşü; kullanıcının deaktif yordamı çağırabilip modelin göremediği tutarsızlığın belirlenmesi; kısa dizin kaydının “ad + etiket” olması ve “model önerir, açmaz” ilkesi; dizin katmanlarının bir yordamın kendi yapısına (açıklama, gövde, referans dosyaları) eşlenmesi; Skill Ecosystem’in salt okunur olması ve yuva harcamaması; kütüphane dizinlerinde kaynak etiketi, paylaşılan dizin ve bağlam dışında tutma ayrıntıları; Gemini değerlendirmelerinin süzülmesi; kaynakların yazarın sitesinden doğrulanması.

Gemini 4 Argon: 1.04, 1.07 ve 1.09 sürümlerinin değerlendiricisi. Değerlendirmelerinden doğan öneriler içeriğe girdiği için imzaya katıldı. 1.04 üzerine metne giren önerileri: kısa dizinin büyük koleksiyonlarda şişme riski ve küme başlıkları çözümü; varsayılan “tek iş” yaklaşımı; dizinin platform içinde tutulup Drive’a ayna kopya bırakılması; zoraki yordam birleştirmenin bedeli; Gemini’nin aktif yordamlarda zaten kullandığı iki katmanlı düzenin vurgulanması; Yordam Ekosistemi örneğinin metne eklenmesi; deaktif yordamın modelin listesinden çıkmasına dair açıklama. 1.07 üzerine metne giren önerileri: 11. ve 12. bölümler arasındaki 1024 karakter geçişinin yumuşatılması; 11. bölümdeki katman ifadesinin başlıkla ve 12. bölümdeki üçlü yapıyla uyumlu hâle getirilmesi. 1.09 üzerine metne giren önerileri: kaynak etiketinin aynı adlı yordamları ayıran bir ad alanı gibi çalışması ve aramada kullanıcının kendi yordamlarına öncelik verilmesi; görev kipinin genel okur için açıklanması. 1.10 sürümünü son biçimiyle onayladı.

Sürüm geçmişi:
1.01 — 4 Kasım 2026, ilk taslak.
1.02 — 4 Kasım 2026, tek yazarlı imzaya geçildi; Gem’lerin yordama dönüştürülmesi ve kullanıcının kendi optimizasyonu (4. bölüm) eklendi; yuva meselesine kendi uygulamam örnek olarak işlendi.
1.03 — 4 Kasım 2026, iki katmanlı dizin (kısa dizin ve uzun dizin) bölümü (11. bölüm) eklendi; ilgili bölümler buna göre güncellendi; (3) numaralı kaynağın imzası düzeltildi.
1.04 — 4 Kasım 2026, çift yazarlı imzaya geçildi; başlığa “(Skills)” eklendi; sohbetteki ayrıntılar metne işlendi (6., 10., 11., 12., 13., 14., 15., 16., 17., 20. ve 21. bölümler).
1.05 — 4 Kasım 2026, Gemini değerlendirmesi işlendi: Yordam Ekosistemi örneği ve deaktif yordamlara dair Gemini açıklaması (6. bölüm), mevcut iki katmanlı düzen (7. bölüm), birleştirme ayrımı (4. bölüm), dizinin yeri (10. bölüm), küme başlıkları ve eşiğe bağlı düzen (11. bölüm), varsayılan tek iş (14. bölüm), çok katmanlı sayfa tablosu (18. bölüm); (9) numaralı kaynak eklendi.
1.06 — 4 Kasım 2026, dizinin Skill Ecosystem adlı özel bir SKILL.md olarak tutulması önerisi yeni 12. bölüm olarak eklendi; sonraki bölümler yeniden numaralandı; 6., 10., 19. ve 22. bölümler buna göre güncellendi; platformun önerilen yordamı (Skill Ecosystem) ile kullanıcının kendi yordamı (gdn021) metinde ayrıldı.
1.07 — 4 Kasım 2026, yazarın önceki makalelerinin bağlantıları paket sayfalarından alınarak kaynakçaya işlendi; yayımlanmadığı anlaşılan “Gemini Skills’e İkinci Bakış” kaynağı çıkarıldı, yerine “Gemini Skills: İki İleri Bir Geri” ve “Gemini Skills Nasıl Olmalı?” yazılarına başvuruldu (16. bölüm); “Gemini Skills Nasıl Olmalı?” yazısının tam başlığı düzeltildi; “Özel Asistanlardan Ortak Standarda” yazısı yeni (1) numaralı kaynak olarak eklendi (giriş ve 3. bölüm); 6. bölüme önceki gözleme gönderme eklendi; kaynaklar ilk geçiş sırasına göre yeniden numaralandı.
1.08 — 4 Kasım 2026, Gemini’nin 1.07 değerlendirmesi işlendi: 11. bölümün ilk cümlesi “iki ya da üç katmanlı” olarak düzeltildi; 12. bölümdeki 1024 karakter paragrafı 11. bölümdeki hesapla uyumlu hâle getirildi ve iki çözüm yolu ayrıştırıldı; 3. bölüme Gem Fabrikası’nın Argon modeli ve görev kipiyle çalıştırıldığı gözlemi eklendi.
1.09 — 4 Kasım 2026, dizinin platform kütüphanelerini kapsayacak şekilde genişletilmesi önerisi yeni 13. bölüm olarak eklendi (Gemini’nin örnek yordamları ve Claude’un yordam kütüphaneleri örnekleriyle); sonraki bölümler yeniden numaralandı; 10., 11., 20., 21. ve 23. bölümler buna göre güncellendi; sanal bellek eşleştirmesine paylaşılan kütüphaneler eklendi.
1.10 — 4 Kasım 2026, Gemini’nin 1.09 değerlendirmesi işlendi: 13. bölümdeki kaynak etiketi maddesine ad alanı ve arama önceliği eklendi; 3. bölüme görev kipinin açıklaması eklendi; künyede değerlendirici model adı ve düşünme düzeyi belirtildi.
1.11 — 4 Kasım 2026, üçlü imzaya geçildi: Gemini 4 Argon’un değerlendirmelerinden doğan öneriler içeriğe girdiği için yazarlar arasına eklendi; künye buna göre güncellendi.
1.12 — 4 Kasım 2026, son sürüm: “Yordam Ekosistemi (Gemini Skills)” makalesi gdn021’in ilk geçtiği yerde (6. bölüm) yeni (5) numaralı kaynak olarak eklendi; sonraki kaynaklar yeniden numaralandı.

---

| 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 ░ | ░ Sınırlı Bellek, Sınırsız Yordam (Skills): Gemini’de Bütün Yordamlara Erişim için Bir Dizin Önerisi │Limited Memory, Unlimited Skills: A Directory Proposal for Reaching Every Skill in Gemini ░ 04.11.2026

---