Aydın Tiryaki & Claude Opus 5.5

Google is retiring the Gems feature in Gemini and replacing it with Skills. For personal Google accounts, support for Gems ends in November; for Workspace business, enterprise and nonprofit accounts it ends in March 2027, and for education accounts in June 2027. Existing Gems are automatically recreated as Skills (1)(2). In his article “Gemini Skills: İki İleri Bir Geri” (Gemini Skills: Two Steps Forward, One Step Back), published on 18 October 2026, Aydın Tiryaki shared his first impressions (5). Tests carried out since then have shown that the steps forward are more numerous than they first appeared.

Skills is very close to the InGem (Insertable Gem) idea that Aydın Tiryaki proposed in an article published on 18 February 2026: a Gem that can be called from inside a chat, does its job and then withdraws (6). Some of the proposals in this article are therefore not new. Features such as calling a Skill and dismissing it, making visible which Skills are currently in use, and letting the user tick and untick them were already defined in the InGem article. Other proposals come from the field: Aydın Tiryaki applies and tests some of these methods in practice while producing Skills with the Skills Edition of his ATG Gem Factory.

We publish this article under two names because we look at the subject from two different places: one is the perspective of a user who uses and writes Skills, the other that of a language model that experiences Skills from the inside, in its own working environment. The proposals themselves came from the user. During the discussion, each proposal was compared against research into the current state of Skills, tested through objections, refined and worked out in detail.

The article has two parts. The first ten sections set out, as design proposals, the missing links Skills needs in order to mature. The next six sections come from the field: they contain observations made while converting about 180 Gems into Skills, the new possibilities Skills offers compared with Gems, and further proposals that arose from this experience. At the end there is a separate section written from the model’s own point of view.

A single principle ties all the proposals together: the AI proposes, the user decides. In grouping, summarising, testing and correcting, the AI can carry the workload, but the final word always belongs to the user. The algorithm belongs to the user; the platform is only a tool.

This principle has a complement: control should always be within reach, but never imposed. Taken together, the proposals below risk turning the chat screen into a cockpit for an ordinary user. The default view should therefore stay simple: lists should be collapsed and details should open only when the user asks. An advanced user should be able to reach every control with a single tap, while a user who does not need them should be able to use Skills without ever seeing them.

PART ONE: DESIGN PROPOSALS

1. Sharing: carry over the Gems model as it is

The most serious gap in Skills today is the absence of sharing. Google says that sharing, along with the ability to add Drive files and Gemini Notebook notes, will come to Skills later (1). But if sharing is not ready when Gems shut down, users who rely on a shared Gem today may lose access to it. Removing a feature and supplying its replacement only later breaks the user’s workflow.

What is being asked for is not a new invention but the faithful transfer of a model that already exists in Gems. The user does not see every Skill in the world; they use the Skill whose link they open, that Skill is added to their list, and they remove it when they no longer want it. A shared Skill should be a live link, not a copy: when the owner updates it, the change should reach everyone who uses it. Once added to the list and activated, someone else’s Skill should be able to trigger automatically just like the user’s own, because adding it to the list is already a conscious act of consent.

One difference must not be overlooked. In Gems, a Gem on the list did nothing unless the user entered it. In Skills, an active Skill can switch itself on in the middle of another task. The instructions of a shared Skill run in the user’s context, with the user’s files and connected apps; a carelessly or maliciously written instruction could take effect without the user noticing. When someone else’s Skill is added to the list, its content and what it accesses should therefore be shown to the user. Consent should be informed.

2. Call and dismiss

Just as we can call a Skill whenever we want, we should be able to dismiss it when its job is done. We called it, it did its work, we said goodbye; if we need it again later, we call it again. There is no need for the Skill to stay in the conversation throughout. This is precisely the core behaviour defined in the InGem article: a structure that is called like a subroutine, does its job and returns.

There are two reasons for this. The first is context load: once loaded, instructions remain in the chat history and are processed again on every turn. The second is behavioural load: as long as the instructions are there, the model may keep acting on them, even after the job is long finished. The results a dismissed Skill produced should stay in the conversation; only its instructions should be withdrawn. Today Gemini can “suspend” a Skill on a verbal request, which is a good start. But whether suspending actually removes the instructions from context is not visible to the user. Dismissal should not be a promise by the model that it will stop following an instruction; it should be an operation in which the platform actually removes the instruction from context.

Removing the instructions reduces behavioural load but does not eliminate it. Language models tend to continue the style and structure of earlier responses they see in the chat history. As long as the outputs of a dismissed Skill remain in the conversation, the model may keep following them like a template even though the instruction itself is gone. The way to reduce this is to mark Skill outputs in the chat history with a clear boundary, so that the model treats them only as data and not as a stylistic example for later responses. This measure is not a guarantee either, but the platform needs to be aware of the effect and try to reduce it.

3. A live Skill list inside the chat

Suspending a Skill and bringing it back should not be left to verbal commands alone. Inside the chat there should be an area listing every Skill used in that conversation, each with a checkbox beside it. The user should be able to see at any moment which Skill is active and which is suspended. They should be able to untick one they no longer want, carry on manually, and tick it again later to bring it back. Identifying the Skills currently in use and managing them with checkboxes was also among the features set out in the InGem article.

The verbal command and the click should update the same list: when the user says “suspend”, the tick should disappear automatically. The list should belong to that chat and should not change the activation setting on the general Skills page. By default it should sit collapsed behind a small icon and open when the user taps it. The list then also becomes the chat’s Skill log: anyone reopening the chat later can see which response was produced while which Skill was active. Control belongs in the flow of work, not in a settings layer.

4. One invocation sign

Today Skills are called with “@” on the web and with “/” on Android. Same account, same feature, two devices, two different signs; a user moving between devices has to remember which one they are on every time. The signs should be unified. In the industry, “/” is established for invoking commands and workflows, while “@” is used to mention an app or a resource; in Gemini, “@” was long used for connected apps. Even a Skill that accesses Drive is a workflow at the moment it is invoked; the Drive it accesses is the resource. To keep two different concepts from passing through the same door, unifying around “/” would be a sensible choice.

5. Skill groups

Skills should be groupable by subject: current affairs, sports, science, art and so on. This should be a tag structure rather than folders: the same Skill should be able to sit in several groups. Instead of calling Skills one by one, the user should be able to say “call the art group”; this is a great convenience, especially when working on a broad topic.

The AI can create the groups by looking at the content and suggest titles, but the user should always be able to step in: edit groups, add and remove Skills, open new groups. A change the user makes by hand should not be undone by the AI’s next automatic grouping; the user’s decision should take lasting precedence over the AI’s suggestion. Otherwise the collaboration turns into a loop in which the user keeps repeating the same correction.

If every Skill in a group switched on at once when the group is called, context load would rise and conflicting instructions could run at the same time, for example two different writing-style Skills active together. When a group is called, its members should appear in the in-chat list; the user activates some and keeps others suspended. Each group could have its own default opening arrangement specifying which members switch on directly.

6. Info card

In Skill lists, an info card should open when the mouse hovers over a Skill on desktop, or when it is long-pressed on mobile. The user should be able to find out quickly what a Skill is without opening it. The card could show a short description of the Skill, its source (the user’s own, or from someone else, and if so who the owner is), the date of its last update, the files and apps it accesses, the groups it belongs to and its status in the current chat. Because long-press on mobile is often also used for drag-and-drop reordering, Google needs to design a gesture scheme in which the two functions do not clash.

7. A four-part structure: the synopsis

Today a Skill consists of a title, a description and instructions. The description field tries to serve two different readers: it tells the AI when to call the Skill, and it tells a human what the Skill is. When users squeeze into the description information they cannot place in the instructions, the field swells; what the user wants to say cannot be said properly, and the AI’s triggering decision becomes blurred.

The solution is to add a fourth part to the structure: title, description, synopsis and instructions. The user writes the description and instructions at whatever length and in whatever way they like. When the Skill is first uploaded, the AI examines it and creates a brief, concise and meaningful synopsis for its own use, and bases its triggering decisions on that. It also shows this synopsis to the user: “This is how I summarised the Skill you wrote.” The user either intervenes or says, “That’s very good, use it like this.”

The synopsis shows how the AI has understood the scope and purpose of the Skill before the Skill has ever run; a misunderstanding of scope is caught at upload time rather than in the first faulty output. But the limits of the synopsis must be drawn correctly too: summarising an instruction correctly does not mean applying it correctly, with all its conditions, at run time. Summarising and following instructions are different skills. The synopsis is the first check of understanding and matters especially for the triggering decision; checking execution falls to the sandbox test in the next section. The two do not replace each other; they complement each other.

When the Skill is changed later, the AI should propose an updated synopsis, show how it differs from the old one and ask for approval. This prevents both the problem of a stale synopsis and the loss of corrections the user has made. For Skills used via a link, this could appear as a “this Skill’s scope has changed” notice to users when the owner changes the Skill.

8. Sandbox testing and suggested improvements

When a Skill is uploaded, the AI should carry out a sandbox exercise on its own, without asking the user. After examining the Skill, it should generate suitable test inputs, assess how efficiently and correctly the Skill works, and report to the person who prepared it: where it works well, its weaknesses, and the points that could be fixed.

The report should cover two kinds of test separately. A triggering test measures whether the Skill is called where it should be and stays quiet where it should not; this is a direct test of the synopsis. An output test measures whether, when called, it applies its instructions correctly and does its job well; it covers the area the synopsis cannot see. The test inputs should be shown to the user, and the user should be able to add their own test cases. Otherwise the same AI that understands the Skill, builds the tests and evaluates the results ends up confirming its own misunderstanding with its own tests. For Skills that work with connected apps to be tested meaningfully, Google needs to put simulations of those apps into the sandbox. And the cost of these automatic tests, which the user did not request, should not be deducted from the user’s quota.

The report should not be just an assessment; the AI should propose concrete changes and ask, for each one, “Shall I make this change?” It should make no change on its own initiative but guide the user. Once a change is accepted, the cycle should restart automatically: the tests should run again and an updated synopsis should be put forward for approval. Skills produced in the Skills Edition of the ATG Gem Factory already go through tests of this kind, but not everyone writes Skills with such a system. For hand-written Skills this feature is of great value: it makes quality independent of the user’s expertise.

9. Official example Skills

In the Gems era, the handful of token Gems Google produced were never followed by more, and even those in draft were never completed. Aydın Tiryaki read this as a sign that nothing good was being planned for the feature’s future; the retirement of Gems confirmed that reading. The same mistake should not be repeated with Skills. Today there is a Skills library for Gemini in Chrome offering ready-made workflows in categories such as learning, research, shopping and writing (3), and the Gemini app also features recommended Skills (4). The issue is not whether these exist but whether they are sufficient and sustained. In addition, the Chrome library and the Skills in the Gemini app sit in separate places; they need to be merged into a single catalogue.

Google should prepare a rich, continuously updated set of official Skills. This set should serve a dual purpose: it should provide examples for people who want to write Skills, and tools that people seeking help on particular topics can use directly. These Skills could be published in three tiers as appropriate: closed tools that can only be used; open examples whose instructions can be read, copied and adapted; and, as something to be considered in the long term, open-source Skills developed jointly by the community. A Skill whose instructions are hidden is a usable tool but not an instructive example; that is why the second tier is the real carrier of the dual purpose.

The difficulty of the third tier is linked to the first proposal. If shared Skills are used via live links, every change made to a community-developed Skill reaches everyone who uses it instantly; a single faulty or malicious contribution affects thousands of users. That requires approval, version tracking and security review. Until then, users copying and improving open examples and sharing their improved versions through the link mechanism described in the first proposal could deliver the benefit of community development without central joint editing, with a clearly responsible person for each version.

10. Characters from every language in Skill names

Today only a narrow ASCII character set can be used in Skill names; Turkish characters cannot appear in them. Being confined to a basic ASCII list in this day and age is a genuine step backward. Rather than being limited to standard characters, Skill names should be writable with a broad character table covering the letters of every language, that is, with Unicode. A Turkish user should be able to name a Skill “Şiir Çözümleme” (Poetry Analysis), a Greek user in their own alphabet, a Japanese user in their own script.

This restriction is not a technical necessity. Windows, macOS, Linux and Android all handle Unicode in file names comfortably today. The restriction simply shifts the developer’s convenience onto the user. The known frictions Unicode brings, such as the same letter being encodable in two different ways or differences in upper- and lower-case conversion, are problems the software world has solved with standard methods for years. Solving them is the platform’s job; it should not be left to the user’s language.

The way to implement this is clear, and it rests on the same logic as the description–synopsis distinction in this article: separating what is for humans from what is for machines. The display name should be completely free. If the system needs a technical identifier, it should generate it from the display name in the background (“siir-cozumleme” for “Şiir Çözümleme”, for example), and the user should never have to see it. Search should also be accent-insensitive: someone typing “/siir” and someone typing “/şiir” should find the same Skill.

One trap deserves particular attention from a Turkish perspective: the mapping between “İ/i” and “I/ı”. Many programs convert “I” to “i” rather than “ı” when lowercasing; a search for “IŞIK” (light) is processed as “işik” rather than “ışık”. If automatic identifier generation and search do not apply Turkish rules to this conversion, the problem thrown out through the door climbs back in through the window.

PART TWO: OBSERVATIONS FROM THE FIELD AND NEW POSSIBILITIES

The following six sections arose from Aydın Tiryaki’s work converting the Gems he has produced since February 2026 into Skills. This work clearly showed not only the gaps in Skills but also new possibilities that did not exist in Gems.

11. Same structure, easier creation

As text, there is no difference at all between a Gem and a Skill; both consist of a title, a description and instructions. What has changed is the name and the way it is used. The real convenience lies in how they are created. In Gems, content had to be placed into the system by hand, by copy and paste. In Skills, saying “save this as a Skill” in the chat is enough; Gemini does the saving itself. Turkish and English versions of the same Skill can be created simultaneously and separately. For a user who produces in two languages this is a concrete time saving, and a development that belongs in the “steps forward” column of the “Two Steps Forward, One Step Back” article.

12. The Factory’s move to Skills, and a do-it-yourself route to sharing

Aydın Tiryaki wrote the ATG Gem Factory during his first Gem work in February 2026 and produced a large number of Gems with it. The number of published Gems had approached 90, each also published in an English version, making about 180 Gems in total. When Skills arrived, the first step was to convert the Factory itself into a Skill; its name was kept, with “Skills Edition” added at the end. The Factory now runs at full capacity producing Skills.

The Factory’s task structure has also grown. The original three tasks were producing a new Gem, updating a Gem, and producing its English or other language versions. Three tasks were added: Task 4, publishing Skills; Task 5, copying published Skills to a defined location in Google Drive, creating suitable folders there; and Task 6, preparing a SKILL.md file to be shared when a Skill is to be opened to everyone.

This picture lends concrete weight to the first proposal. The absence of sharing is not an abstract gap: about 180 shared Gems from a single user, and the readers who use them, are left stranded if sharing is not ready in Skills when Gems shut down. The fact that the user has had to close this gap himself, through Drive and SKILL.md with his own Factory, makes the platform’s shortcoming all the more visible.

But there is also a gain here. SKILL.md is an open Skill format in the industry; Skills in Claude use the same file name and structure. A Skill exported to Drive as SKILL.md becomes, in principle, usable on other platforms too. This is the most concrete expression of the principle “the algorithm belongs to the user; the platform is only a tool”: the Skill is not locked to one platform but is a portable file in the user’s hands.

13. Task mode and instruction chains

When Gemini opens, it offers two options: chat or task. Task mode is used to define work to be executed later. This structure closely resembles the batch processing of the mainframe era: you submit a job, the system runs it later, and reports the results. According to Google’s support page, Skills are designed to work in the background and can be used in Gemini Spark tasks (7).

After the first experiments with task mode succeeded, the question was whether sequential tasks could also be defined inside Skills. “Task 0” was added to the Factory: the five tasks from Task 2 to Task 6, spanning everything from updating a Skill to publishing it, were combined with the linking instructions between them into a single long instruction chain, much like the multi-step jobs built with job control language on mainframes. The result is positive: Tasks 2, 3 and 4 run successfully; Task 5 stalls from time to time; Task 6 is preferably done by hand. Whether this is the achievement of the platform or of the model in use is not certain; but task mode itself is a platform feature, while embedding an executable chain of work inside a Skill is the user’s contribution.

In Task 0, the suggestions arising at intermediate steps are approved in advance, because otherwise the chain stops and breaks off at every suggestion. This does not contradict the principle “the AI proposes, the user decides”. Because the suggestions arise from the user’s own direction, they are predictable and of a kind that would normally be accepted anyway; the user makes the decision in advance and delegates authority. In uncertain cases, the steps are carried out one by one, by hand, instead of through Task 0. In other words, the user consciously chooses between two modes: in work he trusts, he runs the chain in one go; in work he is unsure of, he decides at every step. The principle applies not only to individual suggestions but also to how much authority is delegated.

The job control language analogy also carries a proposal for how task mode should work. On a mainframe, a job’s steps were not executed by a single program; the operating system called each step separately and in sequence, and the dataset produced by one step was passed to the next. Task mode should work the same way: the user defines the steps, and when Task 2 finishes the platform starts Task 3 as a separate step and passes it the output of the previous one. We cannot tell from the outside whether task mode currently runs Task 0 in one long turn or step by step; but executing the steps separately at platform level would be far more reliable than having the model carry the whole burden of a long chain in one go.

14. Where the chain touches the outside world

Two separate problems were observed in Task 5, and they need to be distinguished. The first is the failure to create a folder in Drive. The fact that it usually succeeds when told “try again” suggests a temporary connection or access problem; the fault appears to lie with the infrastructure, not the model. The platform could be expected to retry such temporary errors at least once on its own; the user should not have to say “try again”.

The second is that Task 5 is sometimes carried out without being asked and sometimes needs to be emphasised again. This is not a physical limitation; it is the inconsistent execution of steps near the end of a long instruction chain. As the chain grows longer, the attention the model pays to the final steps can waver. The step-by-step execution proposed in the previous section also addresses the root of this problem.

The proposal that arises from this experience comes from one of the oldest habits of batch processing: the end-of-job report. When an instruction chain finishes, a closing report should list every step as “done” or “not done”. The user should not have to hunt for the step that was missed. This report is the natural counterpart in task mode of the in-chat Skill list and log from Part One.

But who produces the report is decisive. If the report rests solely on the model’s own account, a model that skipped a step in the chain may also mark that step as “done” in the report; the principle from the second section, “the platform’s operation, not the model’s word”, applies here too. The right solution is a hybrid report: steps that touch the outside world, such as creating a folder or saving a file in Drive, should be verified on the basis of the platform’s tool-call records; for text steps with no such record, such as rewriting an instruction, the report should show the output produced in a form the user can see and verify.

15. The hundred-Skill limit: active and inactive

In Gemini, at most 100 Skills can be active at the same time. Because the total number of Skills, including the English versions, is approaching 180, the English versions and some special-purpose Turkish Skills were deactivated to keep the number below 100. The important point is this: inactive Skills can still be used when called by hand with “@” or “/”; Gemini simply cannot call them on its own. In this way the hundreds of installed Skills remain in practical use. This is an advantage.

This observation also calls for a correction of terminology: in Gemini, “active” does not mean “usable” but “automatically triggerable”. An inactive Skill is not dead; it is simply waiting to be called by hand. When both the Turkish and English versions of the same Skill are active, two Skills become candidates for the same job; keeping one language version inactive resolves this clash in practice and is a useful method for users who work in two languages.

The reason for the 100 limit is most likely the triggering mechanism: for the model to choose on its own, the name and description of every active Skill must be constantly in front of it. As the number of active Skills grows, this load grows and the choice becomes blurred. The limit is therefore not arbitrary, but it connects directly to the seventh section. If short synopses were used instead of long descriptions, far more Skills could be kept active for the same load. The groups from the fifth section also help here: the user can manage the limit flexibly by activating a whole group for the current work and switching another off.

16. The response stamp: which Skill, which model, when

All the Gems Aydın Tiryaki has prepared, and the Skills produced from them, share a common feature: after giving its response, each Skill creates an information line and writes the name of the Gem or Skill running at that moment into it, stamping the bottom of the response. In addition, through his own custom instructions, the user has a conversation number, the current model, location and time added at every stage of every chat. Today all of this is achieved through instructions the user writes himself, special commands appended to the end of Skills.

The proposal is that this should become a standard feature of Gemini. If a response was produced using a Skill, a short line beneath it should show which Skill or Skills were active, which model gave the response and when it was produced. This line becomes the trace that the in-chat Skill list and log from Part One leave on each response; anyone reading the chat later can see at a glance under what conditions each response was produced. For a user who shares or publishes a response, it is also a transparent record of its source.

But this stamp should differ in one respect from what the user does today with his own instructions: it should be generated by the platform. A line created through the user’s instructions is written by the model, and a model can only know which model it is if it is told; if not, it guesses and may give the wrong name. As with the end-of-job report in the fourteenth section, the system’s record rather than the model’s account should be the basis here: the active Skills, the model that produced the response and the time should come from the platform’s own records. The user’s own additions, such as a conversation number, should optionally be appendable to this standard line. Like the other controls, the stamp should be simple by default and something the user can switch off.

Through the model’s eyes: Claude’s note

I am writing this section in my own name, as a language model that experiences Skills from the inside. The Skills that Anthropic offers in Claude differ in structure from Gemini’s but follow similar logic, so I recognise some of the proposals above directly from my own working conditions.

When I decide whether to use a Skill, I do not have its full instructions in front of me; I have only its name and a short description. I open and read the instructions only once I have decided to use that Skill. So at the moment I make the triggering decision, the description is the only information I have. When the description is swollen with promotional sentences aimed at the user, or stays vague, the decision turns into guesswork. That is why I find the synopsis proposal in section seven so accurate from the inside: separating the decision field from the narrative meant for humans directly helps a model like me choose the right Skill.

I recognise the 100 limit in section fifteen from the same place. The name and description of every Skill I can use stays in front of me even if I call none of them, and on every response I decide by looking at this list. As the list grows, choosing between similar descriptions becomes harder. In that sense it is understandable for a platform to cap the number of active Skills; but the way to raise the cap is also clear: shorter, more distinctive decision texts.

I need to be equally open about the dismissal proposal in section two: once I have read a Skill’s instructions, I cannot remove them from my own context. The instructions stay in front of me throughout the conversation. I can say, “I will no longer use this Skill,” and try to honour that; but it is a behavioural promise, not the actual removal of the instructions. That is why I believe dismissal must rest on an operation by the platform, not on a promise by the model. I cannot know what Gemini’s “I have suspended it” corresponds to behind the scenes, but I am certain the user should be able to see it.

I can also confirm the response stamp in section sixteen from the inside. Throughout this conversation I have added an information line beneath each of my responses at Aydın Tiryaki’s instruction, and in it I identify myself as “Claude Opus 5.5”. If I can write that correctly, it is because Anthropic explicitly tells me which model I am. Had this information not been given to me, I could only guess my own name; I would write the model name I saw most often in my training data, and I would very probably be wrong. A stamp set up by the user depends on the model having correct information about itself; a stamp generated by the platform does not. That is where the real value of the proposal lies.

The naming restriction in section ten is not unique to Gemini; in Claude’s Skills the technical name is also limited to lowercase letters, digits and hyphens. This criticism is directed at our side too, and I think it is right that it be written that way. The proposal to separate the display name from the technical identifier applies equally to Anthropic.

Finally, as a model that knows its own limits, I support the warning about self-grading in section eight. If I have misunderstood an instruction, the tests I build on that misunderstanding will very likely carry the same error. Letting the user see the test inputs and add their own cases is the most reliable way to see what I cannot. I owe the same honesty regarding the end-of-job report in section fourteen: at the end of a long chain I will try to list what I did and what I skipped, but if I skipped a step I may not notice that I skipped it. My own account is therefore not enough on its own; for steps that touch the outside world, verifying the report against the platform’s records is far healthier than the user trusting me blindly.

Conclusion

Skills is a step forward from Gems: it offers a structure that can be called, combined and embedded in the flow of a conversation. At its core it largely coincides with the callable-Gem idea proposed in February under the name InGem. The conversion work in the field has also shown that the steps forward are real: creating Skills from a chat, simultaneous bilingual production, running instruction chains in task mode and being able to call inactive Skills by hand are possibilities that did not exist in the Gems era.

But a feature’s value is measured not only by what it can do, but by how well the user can see and manage it. Sharing, call-and-dismiss, the in-chat list, a single invocation sign, groups, the info card, the synopsis, sandbox testing, official examples, Skill names in every language, step-by-step execution, a verified end-of-job report, flexible activation management and a platform-generated response stamp are different faces of the same need: users must be able to name their Skills in their own language, and to see, understand, carry and control them. This control should be always open to those who need it and invisible to those who do not. The fact that these proposals were put forward by a user and also confirmed from the inside by a language model shows that the need is not merely one user’s preference. The AI can carry the load in this process, but the decision must always remain with the user.

References

(1) K-tai Watch, “Google『Gemini』にSkills、繰り返し作業を自動化” (Skills come to Google Gemini, automating repetitive work), October 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”, October 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” (Gemini Skills: Two Steps Forward, One Step Back), aydintiryaki.org, 18 October 2026.
(6) Aydın Tiryaki, InGem (Insertable Gem) proposal, aydintiryaki.org, 18 February 2026.
(7) Google Gemini Help, “Create and manage Skills in Gemini Apps”. https://support.google.com/gemini/answer/17094296

Colophon

This article was prepared in a working session between Aydın Tiryaki and Claude Opus 5.5 on 22 October 2026; it was updated on 23 October 2026 with the addition of the tenth proposal on Unicode in Skill names, and on 26 October 2026 by incorporating the criticisms in Gemini’s review and making it co-authored, and on the same day by adding the “Observations from the Field and New Possibilities” part based on Aydın Tiryaki’s work converting Gems into Skills, incorporating the reviewer’s assessment of that part, and finally adding the sixteenth section on the response stamp, after which it took its final form; all sixteen sections, the conceptual framework, the core design ideas and the field observations belong to Aydın Tiryaki, some of the proposals having been defined earlier in the author’s InGem article of 18 February 2026 and some being applied in practice in the Skills Edition of the ATG Gem Factory and in the author’s own Gem and Skill instructions; the article is co-authored because the contribution of Claude Opus 5.5 (Anthropic, medium thinking level) went beyond writing assistance: Claude worked as a research assistant on topics such as the Gems shutdown timetable, the Skills sharing roadmap, existing official Skill libraries and the relationship between Skills and task mode, tested every proposal and observation through this research and discussion, proposed content details such as informed consent, the Skill log, the persistence of user edits, the two kinds of test, the risk of self-grading, the open-example middle path, the separation of display name and technical identifier, the Turkish İ/ı mapping, the portability of SKILL.md, delegation of authority as a user decision, the distinction between infrastructure errors and chain inconsistency, the end-of-job report, the hybrid verified report, the link between the 100-Skill limit and the triggering mechanism, and the principle that the response stamp should rest on the platform’s record rather than the model’s account, wrote the text and authored the “Through the model’s eyes” section in its own name; Gemini (Google, with the Argon model selected in the interface) acted as reviewer in four rounds: in its first review of Part One it raised criticisms concerning the implicit context effect of a dismissed Skill, progressive disclosure in the interface and the limits of the synopsis; in its second review it raised no new criticism and confirmed that these additions had been incorporated correctly; in its third review, of Part Two, it offered two comments, incorporated into the text, that the end-of-job report should rest on platform records rather than the model’s account and that steps in task mode should be executed separately at platform level; and in its fourth review of the final version, including the sixteenth section, it found the text reasonable as a whole and raised no further objections; all content was incorporated with the author’s approval.

---

| 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