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

Introduction

AI skills (Skills, in Gemini’s terminology) have quickly become the centre of my daily work. In Turkish, I propose the term “yapay zekâ yordamı”, or simply “yordam”, for Skills (1). Gemini’s implementation works far better than I first expected. At one point, however, it runs into a limit set by the platform: no more than 100 skills can be active at the same time. This article does not ask for that limit to be removed. What it proposes is a way to reach every skill while staying within it.

The core of the proposal is short: skills should not be held in memory, but the way to them should be shown. A skill arrives, does its job, and leaves.

The subject is too broad for a single article, so this text is designed as the first in a possible series. It deals with Gemini; the situation in Claude will be examined in a separate article.

1. What works today

It is worth starting with what works well. When a topic is mentioned in Gemini, the model finds the most suitable skill among the active ones. If the name of a skill is known, it can be called directly by name. Calling one skill from inside another, and even a third from inside the second, also works without trouble. I have not run into problems with any of this, and all of it is genuinely useful in daily work.

So this article has no objection to the skill architecture itself. Its subject is how to reach the skills that sit outside the active list.

2. The hundred-skill limit

According to Google’s transition notice, users can create as many skills as they like, but only 100 can be active at once. When the limit is reached, another skill has to be switched off before a new one can be activated (2)(3).

I tested this limit deliberately on my own account, because a written rule and a system’s actual behaviour do not always match; something may be stated and still not be true in practice. I tried to go past 100 both by activating deactivated skills and by adding new ones. The system refused every time. The result is clear: creation is unlimited, activation is capped.

3. One user’s collection

In the Gem era I had built about 90 Turkish Gems, each with an English counterpart. When Skills arrived, I converted all of these Gems into skills myself (1). For this I prepared a version of my Gem Factory adapted to skill production (Skills Edition), and with it I converted the Gems one by one and produced SKILL.md files for all of them. Today I have about 180 written, working skills. When Gemini opens, it offers two options: chat or task. Task mode is used to define work to be carried out later (4). To keep the Gem Factory running smoothly, I use the Argon model and task mode rather than chat mode. In my experience, task mode is considerably more stable than chat mode.

I keep all the English versions deactivated. There are two reasons for this. The first is to keep the active count under 100. The second is to stop two language versions of the same skill from both becoming candidates for the same task. Keeping one language version switched off solves this conflict in practice. I keep the English versions so that I can share them, as SKILL.md files, with anyone who wants to use them. My website also has a Turkish and an English article for each skill, along with package pages that bring the two together.

But the 100 limit is steadily narrowing my room to write skills on new subjects. Whenever I need a skill for a new topic, at this rate I will soon have no way to continue.

4. My own optimisation

Since there is a limit of 100, I try to adapt to it. I also keep some rarely used Turkish skills deactivated. And I have started merging Turkish skills on similar topics into a single skill with added menus, so that the merged skill can handle both jobs. So far I have merged five pairs, which has reduced my skill count by five, and more will follow.

These merges are not all of the same kind. Some bring together closely related tasks and can reasonably be seen as good design in their own right. Others I make only because of the limit, and these have a cost: the body of the merged skill grows, and when only one of the tasks is needed, the instructions for the other are loaded as well. If the directory and temporary activation scheme proposed in this article existed, I would not make these forced merges; I would keep those skills separate.

I try never to let my active count rise above 90. During work, when several skills are being prepared at once, the count can exceed 100, so I need to leave a working buffer of about ten skills.

5. What does “active” mean?

As I noted in an earlier article, “active” in Gemini does not mean “usable”. It means “able to trigger on its own” (4). A deactivated skill is not dead. It stays in the system, ready to work, simply waiting to be called by hand.

6. The access problem

This is exactly where the problem begins. Deactivated skills do not appear in the list that opens when the @ sign is typed. In my observation, a manual call works only when the exact name of the skill is known and typed directly. I had noted earlier that a deactivated skill could be called and used by hand (4), but I have run so many experiments that I no longer remember exactly how I did it. I wanted to repeat the test while preparing this article, but my five-hour Gemini quota window had run out. I will test the details separately: whether a deactivated skill appears in the list at all, whether a call is accepted when its exact name is pasted, and whether the model can find it when asked in plain text without any sign. In the meantime, recalling a name among hundreds of skills, or hunting for it in the settings list, is a real waste of time.

According to Gemini’s own explanation, once a skill is deactivated it disappears entirely from the list of skills in front of the model. The model can no longer see its name or its description. When the user calls it with @, what brings it in temporarily in the background is the interface layer, not the model. I will verify this explanation with the test mentioned above.

There is a more important problem as well: neither the model nor other skills can reach a deactivated skill. This has a concrete meaning for me. Being used to solving my own problems, I built my own solution here too: a meta-skill coded gdn021, whose English name is Skills Ecosystem (5). When I give it a topic, it scans the existing skills and tells me which of them would help. I wrote it because even within an active list of 90 skills I find some hard to remember. But gdn021 can scan only active skills. The roughly 90 deactivated skills are a blind spot for it.

I also have skills that go to another skill, read it and write an article about it. Along the same lines, I could easily write a skill that scans all the deactivated skills, compiles for each one “what task it is called for”, gathers this into a single document and publishes it. But that skill could not reach the deactivated ones either, so each time I would have to activate them first, scan them, finish the job and switch them off again. In a collection of 180 skills, that is a roundabout chore.

Another route would be to scan the skill articles on my website. But that is not what I want. The information about the skills already exists inside the platform. Making the user gather it back from outside, from their own website, is an unnecessary detour.

There is a striking inconsistency here. The user can call a deactivated skill by hand, yet the model cannot even look at the same skill’s name and description. Between “not carrying something all the time” and “never being able to reach it” lies a wide middle ground, and at the moment that ground is empty. My request concerns exactly this middle ground: let the skill stay deactivated and take up no room in the platform’s memory, but show us a way to reach it easily.

7. Why the limit is justified

This article does not oppose the limit, because the limit rests on two valid reasons.

The first is load. For the model to choose a skill on its own, the name and description of every active skill must stay in front of it at all times, even if none of them is used. In that sense, an AI saying “I will not hold more than 100 skills in memory” is entirely right. Growing that load without limit for every single user would not make sense.

The second is selection quality. As similar descriptions pile up in the active list, choosing the right skill becomes harder. I have experienced this in my own work. The model began calling, on its own, skills that seemed closest at that moment but had nothing to do with the task. Because of this I had to start many chats with the instruction “do not call any skill”.

One more point deserves emphasis. Gemini already works with a two-layer arrangement for active skills: the name and description stay in context, while the body of the skill is loaded only when the model decides to call it. This progressive loading is also the core principle of the open Agent Skills standard, which defines the common file format for skills (6). So the proposal in this article is not a brand-new architecture. It extends the principle the platform already uses for active skills to deactivated ones.

8. The growth problem

Today’s limit of 100 most likely reflects what the platform’s current infrastructure can carry, and it will grow over time: 128, 256, 512. But the number of skills that users write for themselves will grow just as fast, perhaps exponentially. As skills accumulate and capacity fails to keep up, users will be forced to keep cutting back on everything they have.

The problem can be summed up like this: the AI’s resources are limited, users’ wants are unlimited. Growing capacity alone will not close that gap.

9. First proposal: A greyed-out list

The simplest improvement can be made in the interface. When @ or / is typed, the list that opens should also show deactivated skills, greyed out so that they can be told apart from active ones. A user who says “this one isn’t active right now, but I want to use it now” should be able to pick it straight from that list instead of searching for it elsewhere among hundreds of skills.

This proposal costs the model nothing. The list in the interface does not enter the model’s context; it sits only on the screen. If the reason for the limit is the model’s load, there is no reason left to restrict the list on the screen.

10. Second proposal: A Skill Directory

The main proposal is a Skill Directory that the platform maintains and updates by itself.

Its properties are these:

• Scope: All the skills the user has installed, active and inactive alike. The scope can be extended to cover platform libraries as well (see section 13).
• How it is built: The platform uses the AI’s own capabilities to build the directory as a well-indexed, compressed document, so that the information can be reached in a far more orderly and quicker way.
• Freshness: Because the directory is derived from the skill records themselves, it updates automatically whenever a skill is added, changed or deleted. It always holds the latest information. A catalogue kept by hand goes stale; a directory derived by the platform does not.
• Location: The user does not have to care where the directory lives or how it is stored. It is kept inside the platform’s own system as a special skill called Skill Ecosystem (see section 12). This makes it fast to reach, independent of quotas or file permissions, and safe from being deleted or damaged by mistake. For transparency and backup, an automatic mirror copy can optionally be placed in the user’s own space, such as their Drive. The detailed part of the directory does not stay in context; it is not placed in front of the model on every turn and is read only when requested. A very short summary of it, however, can stay in context depending on the size of the collection (see section 11).

For each skill, the directory holds at minimum: the skill’s exact name (for calling it), a short synopsis of what it does, its status (active or not), and, if one exists, its counterpart in another language. Topic groups and keywords can optionally be added.

Using it is simple. When the user says “I’m looking for a skill on this topic” or “can you find me a skill among the deactivated ones that does this?”, the model looks at the directory and replies along these lines: “For this task, these skills are active and these are not. You can use whichever you like.” If the suitable skill is deactivated, the model gives its exact name and says it can be loaded if the user wishes. The directory does for the whole collection what my gdn021 skill does today for active skills only.

The directory can be thought of as a kind of counterpart to personal instructions. Personal instructions always stay in front of the model. The directory is stored elsewhere, is not held in memory all the time, and is opened only when needed.

11. The directory’s layers: Short index, long index and cluster headings

The directory does not have to be a single block. Depending on the size of the collection, it can be built in two or three layers. The two basic layers are:

• Short index: For each deactivated skill, only its exact name and a label of a few words. Quick searches happen here.
• Long index: Detailed information on deactivated skills: synopsis, language counterpart, topic groups, keywords. This layer does not stay in context; it is read only when a detailed search is needed.

Active skills can stay in context as they do today, with their full names and descriptions. If necessary, the space allotted to active skills can be narrowed slightly to make room for this directory area holding brief entries for deactivated skills. The structure then falls into three tiers:

1. Active skills: Full name and description, always in context.
2. Short index: Names and labels of deactivated skills, always in context.
3. Long index: Detailed information on deactivated skills, only on request.

For a small collection, the cost side is convincing. A skill description in Gemini can run up to 1,024 characters, while an entry in the short index might take 40–60. The short entries for 80–90 deactivated skills take up only as much room as the descriptions of a few active skills. The constant load rises very little, yet the model now knows the deactivated skills exist.

That calculation, however, holds for 80–90 deactivated skills. Since the proposal aims at unlimited skills, a collection of, say, 2,000 deactivated skills would have a short index of over 100,000 characters on its own. That would be both a load and a distraction. As the model tries on every turn to choose among short labels, its suggestions, resting on little information, would more often be wrong, and repeated “shall I open this skill?” questions could wear the user down. So the arrangement should change with the size of the collection:

• In a small collection: The short index stays in context.
• Above a certain threshold: Only cluster headings stay in context, for example “the deactivated collection contains article editors, football skills and English counterparts”. The short index, like the long index, waits outside the context, and the model reads it only when a cluster heading looks relevant to the task.

In large collections the structure therefore grows to four tiers: active skills, cluster headings, short index and long index. This tiering corresponds to multi-level page tables in virtual memory (see section 20).

A short entry consisting of the name alone may not always give enough of an idea. Sometimes a title says enough, but skill names in Gemini are limited to a narrow character set. Short hyphenated names that cannot use Turkish characters often fail to convey what a skill does (4). It is therefore safer for a short entry to be “name + a label of a few words”. That label is the shortest form of the synopsis field I proposed in an earlier article.

Because the short index or the cluster headings stay in context, a new possibility opens up: without being asked, the model can suggest, “the deactivated skill X fits this task; shall I open it temporarily?” The decision to open it, however, always stays with the user. The model suggests; it does not open. The experience of unrelated skills being called on their own (see section 7) shows why this line is necessary.

12. The directory’s carrier: Skill Ecosystem

As users, we should not have to deal with this directory at all. Where the document lives, how it is stored and when it is updated should be entirely the platform’s business. The easiest way to achieve this is to keep the directory not as a new mechanism but in a form the system already knows: as a SKILL.md.

My proposal is this: the platform writes and updates, on its own, a special skill covering all of the user’s skills. This skill is called Skill Ecosystem, and its file might be skill-ecosystem.md. The platform reads and runs it when needed, just as it reads and runs any other SKILL.md file. And the user can view it, just as they can view their other skills.

I am deliberately proposing an English name. Each user can translate it as they prefer; in Turkish I call it “yordam ekosistemi”. The name shares its root with my own skill gdn021, whose English name is Skills Ecosystem, and this is no coincidence: gdn021 is a user-built prototype of what we are asking the platform for, limited to active skills. To avoid confusion, in this article the proposed platform skill is called Skill Ecosystem, and my own skill is referred to as gdn021.

The strongest point of this solution is that the layers defined in the previous section map one-to-one onto the structure a skill already has:

• The skill’s description (always in context) → cluster headings or a short summary
• The skill’s body (loaded when called) → short index
• The skill’s reference files (read when needed) → long index

So the platform does not need to invent a new layer. Today’s progressive loading arrangement can carry the directory as it is (see section 7). The only new work is for the platform to write and update this special skill automatically.

One detail regarding the calculation in section 11 needs clarifying here. There is no problem in terms of load: the short index for 80–90 deactivated skills comes to roughly 4,500 characters, about as much as the descriptions of a few active skills. The limit lies not in the load but in the capacity of the field. A skill description in Gemini is capped at 1,024 characters, and a 4,500-character short index will not fit into a single description field. There are two solutions:

• A wider description field: Since Skill Ecosystem is a system skill rather than a user skill, the platform can give it a description field wide enough to hold the short index of a small collection. That amounts to the space of only four or five active skill descriptions.
• Moving it into the body: The 1,024-character limit is kept. The description always holds only cluster headings or a short summary, and the short index moves into the body of the skill.

In this way, the small-collection arrangement in section 11 is served by the first route and the large-collection arrangement by the second, both within the same skill.

Skill Ecosystem should follow two more rules:

• Read-only: The user can view Skill Ecosystem but does not edit it. Since its content is generated automatically from the skill records, a manual change would either be erased by the next update or leave the directory contradicting the actual state. If the user dislikes how a skill is described in the directory, the correction is made in that skill’s own description and flows into the directory automatically.
• No slot used: Skill Ecosystem does not use one of the user’s 100 slots; it counts as a platform system skill.

13. Widening the directory’s scope: Platform libraries

The directory should not be limited to the skills users write themselves. In Gemini’s Explore area, in the section for customising Gemini, there are skills prepared by Google as examples, under headings such as everyday tools and tools for businesses. From the user’s point of view these are also deactivated; the user can activate them from there if they wish. Their status, in other words, is the same as that of my own deactivated skills. These skills can therefore be included in the directory together with their properties.

This is only a beginning. As platform libraries grow, the proposal will matter even more. Claude today offers quite extensive skill libraries. On its customisation page there are newly added skills, the most installed ones, and a large number of skills under categories; under the engineering heading, for example, a genuinely substantial library has formed. Similar libraries are very likely to emerge in Gemini as well. I will look at the situation in Claude in detail in the next article in this series.

The proposal is this: each library has its own directory. When the user asks “what is there on this topic?”, the model looks first at the user’s own directory, then at the library directories, and presents the results together: “Among your own skills there are these; the platform library also has these examples.”

This extension involves three details:

• Source label: Every entry in the directory should show where it comes from: the user’s own skill, the platform’s library, or, if sharing opens up in the future, another user. Opening someone else’s skill for the first time is a different step from opening one’s own. The user should decide having seen what it does and what it accesses (4). The principle “the model suggests, it does not open” becomes even more important here. The source label also works as a namespace: even if a skill the user wrote and a library skill carry the same name, they do not get mixed up. In searches, the user’s own skills always come first, with library results presented after them.
• Shared directory: The user’s own directory is personal, but a library’s directory is the same for all users. The platform prepares it once, and everyone looks at the same directory. The additional cost of a library directory per user is therefore close to nothing.
• Kept out of context: Because libraries can grow to thousands of skills, library directories are not kept in context. At most, cluster headings stay there. A library directory is read only when the user asks, or when no suitable skill is found in the user’s own directory (see section 11).

14. Third proposal: Temporary activation

If the skill found in the directory is not active, the platform activates it temporarily for the task. The skill is used and, once the job is done, deactivated again. It never enters the permanent active list.

Information thus enters memory in stages, and only when needed:

1. First the directory is consulted. Quick searches happen in the short index (in large collections, first in the cluster headings), and detailed searches, if needed, in the long index. The long index is never permanently in memory; it is a reference source the AI is asked to examine only when needed.
2. Based on the information found, the decision is made to use that skill. The skill is activated, brought temporarily into memory, used, and, once the job is done, deactivated and taken out of memory.

Activation and deactivation are the work of software, not of the model; they can be automated without requiring a large context. These switches therefore place no load on the model themselves. The load is paid only for as long as the skill is in use.

This has an important consequence for users. If we can reach a deactivated skill whenever we like, without it taking room in the model’s memory or burdening it, we can freely write a skill for every need that does not have to stay active. The skill arrives, does its job, and leaves.

15. The question of slots

The relationship between temporary activation and the limit of 100 can be set up in two ways.

• Basic option: The user leaves some of the 100 slots free for temporary use. Someone who wants to use 10 deactivated skills at the same time keeps 10 slots free; someone who wants 20 keeps 20. A rule like this is an easily acceptable restriction. It requires no change to the infrastructure and works with today’s capacity. The platform cannot object that “our capacity won’t allow it”, because what is being asked for is not a new load but a smarter use of existing slots. I already practise something similar today: by keeping my active count at 90, I leave a working buffer of about ten slots (see section 4).
• Generous option: The platform still grants 100 slots but, reasoning that “these will only be used temporarily anyway”, counts temporary activations outside the 100, as a bonus. This is entirely at the platform’s discretion. As an old Turkish saying goes, “the agha’s hand is not held”: the powerful are free to be generous if they choose.

16. How long temporary activation lasts

The user decides how long temporary activation lasts. There are two options:

• Single task: The skill is deactivated once the task is complete.
• For the whole chat: The skill stays active until the chat ends and can be called again when needed.

In my experience, the single-task option is usually more practical. There is rarely a need for a skill to stay open throughout a chat. The default should therefore be “single task”. Asking the user first “shall I open it?” and then “for how long?” creates needless friction. When the model finds a suitable skill, it asks for a single confirmation: “Shall I run skill X temporarily for this task? Let me know if you’d like it to stay open for the rest of the chat.” The work then proceeds with one confirmation, and the choice still rests with the user. The way activation and deactivation are carried out follows from that choice.

17. What deactivation really means

A technical distinction needs to be drawn correctly here. An instruction that has been read within a chat stays in that chat’s context even after the skill is deactivated; the model cannot “forget” it. Deactivation under the single-task option is therefore not a memory purge but a behavioural closure. When the job is done, the platform signals to the model that “this skill’s task is complete; stop applying its instructions”, and the skill no longer interferes with the rest of the chat. In later chats it places no load at all.

I have seen in my own experiments that this kind of closure is already possible today. In my first exploratory article I recorded that I had managed to run two separate skills one after the other in the same chat (7). Later I ran six related skills in sequence in the same Gemini chat, then suspended them and loaded a new one. I had also noted in an earlier article that Gemini can suspend a skill on a spoken request (4). This showed that the InGem lifecycle I proposed in February 2026, “be called, do your job, withdraw”, works in practice (8). Today, when you say “all right, you can go now”, the skill does not leave the context entirely, but it can be suspended. A suspended skill, although it has once been loaded, no longer interferes with the rest of the chat. Under the proposed arrangement, a deactivated skill will simply have withdrawn on its own once its job is done. As the architecture matures, a true unloading will become possible too.

18. The active list: Favourites

With a directory and temporary activation in place, the role of the active list changes. Today users feel they must fill all 100 slots, because a skill left outside the slots is effectively lost. With a directory, keeping a skill active is no longer needed to “stay reachable”, only for “frequent use”. The active list becomes a favourites list that people want to keep open at all times. Most people would probably let go of the 100 and settle for the 10–20 skills they use most, using the rest only when needed.

The gain runs both ways. For the platform, a shorter active list means less load on every turn. For the user, the model chooses the right skill more accurately, and unrelated skills trigger on their own less often. The platform thus effectively reduces users’ demand without even needing to raise the limit of 100.

19. An old question: Unlimited wants, limited means

This problem is not new. In social and economic life, from whatever angle one looks, meeting unlimited wants with limited means is a fundamental question, and every field has its way of weighing it. In 1932 Lionel Robbins defined economics precisely through this relationship: the relationship between unlimited ends and scarce means that have alternative uses (9). This article’s proposal asks the same question about AI resources: an optimisation method that balances the AI’s capacity and means against people’s wants by other routes, without forcing the limits.

20. A known solution: Virtual memory

Computer science has had a working solution to this problem for decades: virtual memory. Physical memory is limited; the needs of programs are larger. The solution is not to wait for memory to grow but to bring the needed part into memory at the moment it is needed and write it back once the job is done. This idea was first implemented in 1962 on the Atlas computer in Manchester (10). In the early 1970s it spread widely with IBM mainframes.

The proposal maps onto virtual memory almost one-to-one:

• Page table → the Skill Directory, i.e. Skill Ecosystem (knows where everything is, without carrying the content)
• Multi-level page table → cluster headings, short index and long index
• Shared libraries → a single directory of platform libraries for everyone
• Paging in → temporary activation
• Paging out → deactivation once the job is done
• Physical memory limit → 100 active skills

Multi-level page tables emerged precisely because of the scaling problem described in this article. As memories grew, single-block page tables grew bloated too. The solution was to keep only the top level of the table permanently in memory and read the lower levels when needed. Keeping only the cluster headings in context for large collections follows the same logic.

Shared libraries in operating systems also correspond to the proposal in section 13. A library used by many programs sits in memory as a single copy, and each program uses that one copy instead of carrying its own. The directory of platform libraries works the same way: it is prepared once, and all users look at the same directory.

Peter Denning’s working set concept, introduced in 1968, also fits this picture (11). A working set is the set of pages a program actually uses within a given period. Good memory management does not try to keep everything in memory; it keeps only the working set. The 10–20 active skills a user relies on most are exactly that user’s working set.

This analogy shows that the proposal is not an untested idea: it applies a proven principle to a new field.

21. Stopgap or lasting design?

At first glance, the proposal may look like a stopgap to rely on until capacity catches up. But it will remain necessary even when capacity does catch up. The problem is not only the load the infrastructure can carry but also the quality of selection. Even if the active limit rises to 512, nobody would want all 512 skills to be candidates for triggering on their own at the same time. This becomes even clearer once platform libraries reach thousands of skills. Virtual memory did not disappear as memories grew either; on the contrary, it became the standard.

The Skill Directory and temporary activation are therefore not a remedy for a transition period but a permanently better design for skill architecture.

22. Behaviour from the user, implementation from the platform

These proposals were designed around today’s system. What they define, however, is how the system should behave; how that is realised in the architecture and the interface is the platform’s job. Since we are developing a way to use skills as efficiently and widely as possible, and since the AI’s means are limited, the necessary changes will be made in both the infrastructure and the interface as AI architecture develops in this direction.

This distinction also matches the way I have always looked at software: the algorithm belongs to the user; the platform is only a tool. The proposal sets out the algorithm and leaves the implementation details to the platform. That is why it stands up in today’s system and will not age when the architecture changes.

23. Conclusion

Gemini’s limit of 100 active skills rests on sound reasons, and this article does not ask for it to be removed. What it asks for is a way to reach the skills that fall outside it. The proposed structure has three parts: a greyed-out list in the interface that also shows deactivated skills; a Skill Directory that the platform writes and updates on its own as a special skill called Skill Ecosystem, tiered according to the size of the collection, with its detailed layer read only on request, and able to cover platform libraries as well; and a mechanism that temporarily activates a skill found in the directory, for a single task by default or for the whole chat if the user wishes.

The proposal does not invent a new architecture. It extends to deactivated skills and to libraries the progressive loading principle the platform already uses for active skills. Even the directory is not a separate mechanism; it is a SKILL.md. The user never has to deal with it and simply looks at it when they want. This structure brings three gains. The AI’s resources are used as efficiently as possible. Because the limit is preserved, no problem arises for the platform. And users gain unlimited access to their own skills and to platform libraries, without being forced to merge their skills artificially because of the limit. The active list becomes a favourites list, the model’s constant load falls, and selection becomes more accurate. Limited memory, unlimited skills.

References

(1) Aydın Tiryaki, “From Custom Assistants to a Common Standard: Gems, GPTs, Projects and AI Skills”, aydintiryaki.org, 27 October 2026. https://aydintiryaki.org/2026/10/27/from-custom-assistants-to-a-common-standard-gems-gpts-projects-and-ai-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 October 2026. https://promptoptimizer.tools/blog/how-to-use-gemini-skills

(4) Aydın Tiryaki & Claude Opus 5.5, “How Should Gemini Skills Work? Design Proposals from a User and a Language Model”, aydintiryaki.org, 26 October 2026. https://aydintiryaki.org/2026/10/26/how-should-gemini-skills-work-design-proposals-from-a-user-and-a-language-model/

(5) Aydın Tiryaki, “Skills Ecosystem (Gemini Skills)”, aydintiryaki.org, 4 November 2026. https://aydintiryaki.org/2026/11/04/skills-ecosystem-gemini-skills/

(6) Agent Skills, open standard documentation. https://agentskills.io

(7) Aydın Tiryaki, “Gemini Skills: Two Steps Forward, One Step Back”, aydintiryaki.org, 18 October 2026. https://aydintiryaki.org/2026/10/18/gemini-skills-two-steps-forward-one-step-back/

(8) Aydın Tiryaki, “A Proposal for a New Standard in AI Interaction: The InGem (Insertable Gem) Model”, aydintiryaki.org, 18 February 2026. https://aydintiryaki.org/2026/02/18/a-proposal-for-a-new-standard-in-ai-interaction-the-ingem-insertable-gem-model/

(9) Lionel Robbins, An Essay on the Nature and Significance of Economic Science, Macmillan, London, 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, pp. 323–333.

Colophon

Authors: Aydın Tiryaki & Claude Opus 5.5 (Anthropic) & Gemini 4 Argon (Google, medium thinking level).

Aydın Tiryaki: The idea and conceptual design of the proposal (greyed-out list, Skill Directory, short and long index layers, keeping the directory as a SKILL.md called Skill Ecosystem, extending the directory to platform libraries, temporary activation, slot options, leaving the duration of use to the user, the active list becoming a favourites list, and the framework of unlimited wants and limited means), his own optimisation practices including gdn021, observations on Gemini’s and Claude’s libraries, field observations and experiments.

Claude Opus 5.5: Writing, source research and conceptual discussion. Its own evaluations that entered the text: the virtual memory, multi-level page table, shared library and working set analogies; defining deactivation as a “behavioural closure”; the view that the proposal is a lasting design rather than a stopgap; identifying the inconsistency whereby the user can call a deactivated skill while the model cannot see it; the “name + label” form of short index entries and the principle “the model suggests, it does not open”; mapping the directory layers onto a skill’s own structure (description, body, reference files); Skill Ecosystem being read-only and using no slot; the source label, shared directory and out-of-context details of library directories; filtering Gemini’s reviews; verifying the sources against the author’s website.

Gemini 4 Argon: Reviewer of versions 1.04, 1.07 and 1.09. Joined the byline because suggestions arising from its reviews entered the content. Suggestions from its review of 1.04 that entered the text: the risk of the short index swelling in large collections and the cluster-heading solution; the “single task” default; keeping the directory inside the platform with an optional mirror copy in Drive; the cost of forced skill merges; emphasising the two-layer arrangement Gemini already uses for active skills; adding the gdn021 example to the text; the explanation that a deactivated skill drops out of the model’s list. From its review of 1.07: smoothing the transition on the 1,024-character limit between sections 11 and 12; aligning the layer wording in section 11 with its heading and with the three-part structure in section 12. From its review of 1.09: the source label working as a namespace that separates skills with the same name, and giving priority to the user’s own skills in searches; explaining task mode for the general reader. It approved version 1.10 in its final form.

English version: The Turkish original was adapted into English, and rewritten rather than translated literally, by Claude Opus 5.5.

Version history:
1.01 — 4 November 2026, first draft.
1.02 — 4 November 2026, switched to a single byline; the conversion of Gems into skills and the user’s own optimisation (section 4) added; the author’s own practice added as an example of the slot question.
1.03 — 4 November 2026, section on the two-layer directory (short and long index) added (section 11); related sections updated; byline of reference (3) corrected.
1.04 — 4 November 2026, switched to a double byline; “(Skills)” added to the title; details from the discussion worked into the text (sections 6, 10, 11, 12, 13, 14, 15, 16, 17, 20 and 21).
1.05 — 4 November 2026, Gemini’s review incorporated: the gdn021 example and Gemini’s explanation of deactivated skills (section 6), the existing two-layer arrangement (section 7), the distinction between merges (section 4), the directory’s location (section 10), cluster headings and the threshold-based arrangement (section 11), the single-task default (section 14), multi-level page tables (section 18); reference (9) added.
1.06 — 4 November 2026, the proposal to keep the directory as a special SKILL.md called Skill Ecosystem added as a new section 12; later sections renumbered; sections 6, 10, 19 and 22 updated accordingly; the proposed platform skill (Skill Ecosystem) and the user’s own skill (gdn021) distinguished in the text.
1.07 — 4 November 2026, links to the author’s earlier articles taken from their package pages and added to the references; the reference “Gemini Skills’e İkinci Bakış”, found not to have been published, removed and replaced by references to “Gemini Skills: Two Steps Forward, One Step Back” and “How Should Gemini Skills Work?” (section 16); full title of “How Should Gemini Skills Work?” corrected; “From Custom Assistants to a Common Standard” added as new reference (1) (introduction and section 3); a pointer to the earlier observation added to section 6; references renumbered in order of first appearance.
1.08 — 4 November 2026, Gemini’s review of 1.07 incorporated: the first sentence of section 11 changed to “two or three layers”; the 1,024-character paragraph in section 12 aligned with the calculation in section 11 and its two solutions separated; the observation that the Gem Factory is run with the Argon model and task mode added to section 3.
1.09 — 4 November 2026, the proposal to extend the directory to platform libraries added as a new section 13 (with examples from Gemini’s sample skills and Claude’s skill libraries); later sections renumbered; sections 10, 11, 20, 21 and 23 updated accordingly; shared libraries added to the virtual memory mapping.
1.10 — 4 November 2026, Gemini’s review of 1.09 incorporated: namespace and search priority added to the source label item in section 13; an explanation of task mode added to section 3; the reviewer’s model name and thinking level stated in the colophon.
1.11 — 4 November 2026, switched to a triple byline: Gemini 4 Argon added as an author because suggestions arising from its reviews entered the content; colophon updated accordingly.
1.12 — 4 November 2026, final version: the article on gdn021 added as new reference (5) where gdn021 first appears (section 6); later references renumbered. English version prepared.

---

| 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

---