A production experience, cross-platform portability, and a Turkish term for “Skills”

Aydın Tiryaki & Claude Opus 5.5 & ChatGPT (GPT-6) & Gemini 4 Argon

Introduction

Every major AI platform has offered its users a way to build their own custom assistants. ChatGPT had GPTs, Gemini had Gems, and Claude had Projects, and all three met the same need: defining instructions, rules and workflows for a particular task once, then reusing them again and again. Their forms differed. GPTs and Gems were designed as customized assistants, while Claude Projects were workspaces that brought instructions, knowledge and conversations together. What they shared was a single limitation: each was tied to its own platform. A GPT would not run in Gemini, and a Gem could not be moved to Claude as it was. The design knowledge a user had invested in them stayed locked inside the platform’s format.

That picture is now changing. Platforms are beginning to converge on a common format built around the open Agent Skills standard and its SKILL.md file structure (1). Claude has offered this structure under the name Skills for some time. ChatGPT is one of more than 70 platforms that have integrated the standard (2). Gemini has joined the movement with its own Skills announcement. This convergence does not replace custom assistants in the same way on every platform: Gems are being retired in Gemini, while Claude Projects continue to exist alongside skills. But instructions describing how a task should be done can now be packaged independently of any one platform, within an open and shared standard.

This article examines that convergence on three levels. The first is my own experience. Gems were my main interest, and before that I had built and publicly shared many GPTs. Over eight months I developed nearly a hundred Gems and then moved the collection to Gemini’s new Skills structure. That experience serves as a concrete case within the broader picture. The second level is the process of discussing this experience with three AI systems. ChatGPT turned a conversation we had into a working draft, Gemini wrote a critical commentary on it, and Claude evaluated both and checked the platforms’ limits against their documentation. Every later version went back to ChatGPT and Gemini for review. The third level is a naming proposal: for the Turkish rendering of “Skills”, I propose “yapay zekâ yordamı” (AI procedure) instead of “beceri”, the word that is starting to take hold in Turkish interfaces. I expect this term to shorten over time to simply “yordam”.

In this English version I use “skill” and “skills” throughout, as English readers know them. The Turkish naming question is discussed in Section 9. Where Skills appears as a product name (Gemini Skills, for instance), I keep the original.

A note on method: every claim in this article rests on one of three levels of evidence. The first is what official documentation says: the standard’s recommendations, the limits platforms publish, and their transition timelines. The second is what I have observed in my own account: sharing options, the number of active skills, how the models behave. The third is what has not yet been tested: how long skills perform, and how a single-file structure compares with a multi-file one. This separation keeps my personal experience from turning into a general claim about platforms while still letting it count as evidence. ChatGPT proposed the distinction during the review process. The same process showed that the first level is not sufficient on its own either: official documents from the same company can contradict each other, and different copies of the same document can carry different information (see Section 4). For this reason, access dates are recorded for every online source.

1. A case study: from Gems to skills

I have been developing Gems on Gemini for about eight months, and my collection has grown to nearly a hundred. These are not short prompts. Each one is a complete system defining the order in which a task is carried out, the rules it must follow, and the kind of output it should produce.

After Gemini announced its Skills feature, I began converting my Gems into skills. The work took a little over a week. My most striking observation was that I found no functional difference between a Gem and a skill large enough to force me to rewrite my content from scratch. Instead of redesigning each Gem, I adapted its content to the new structure.

Google has announced that Gems will be converted into skills automatically (3). I chose not to wait for that and converted my Gems by hand, putting each one through a review round and improving it with suggestions from Gemini Argon. An automatic conversion moves a Gem into a new format; a manual conversion is an opportunity to rethink it in light of what the new structure makes possible.

A Gem’s value lies in its content, not in its name on the platform. The principle that “the algorithm belongs to the user; the platform is only a tool” found a concrete expression here: I was able to move to a new system without losing the design knowledge I had built up over months. This does not mean the two structures are identical in every technical detail. It shows that, in my area of use, the difference lies mostly in how the structure is presented, loaded and invoked.

The conversion also exposed a limit. In Gemini, at most 100 skills can be active at the same time. This is both something I observed in my own account and something Google’s help documentation states: you can create as many skills as you like, but only 100 can be active at once (3). Because each of my Turkish skills has an English counterpart, the total comes to around 180. I therefore keep the English versions and some special-purpose Turkish skills disabled and call them manually with @ or / when needed. That is my observation in my own account. Google’s documentation, by contrast, describes disabling one skill in order to enable another once the limit is reached, and does not say whether disabled skills can be invoked manually (3). This behaviour will be verified separately in the test plan. For a user who maintains a bilingual collection, this limit directly shapes day-to-day work.

2. Separating the production system from the skills it produces

The Gem Factory, which I began developing in February, was the production tool I used to build Gems. Without changing its name, I adapted it to skill production and began running it as “Skills Editions”. There are therefore two distinct products:

1. The production system: Gem Factory/Skills Editions, which I use to create new skills.
2. The skills it produces: tools built with this system to carry out specific tasks.

This distinction also determines the choice of model. Production means analysing long, complex instructions, weighing many rules together, and creating a new product. Use means applying a workflow that has already been defined.

The Gem Factory’s instructions have grown over time; some of my skill texts reach 30,000–40,000 characters. When working with instructions of that size, I use the Argon model in Gemini. Argon has its own problems, and its high quota consumption is a significant drawback. Even so, in my own work I have seen a clear improvement on production tasks compared with Pro 3.1, which I used before. The skills it produces, on the other hand, I have also run with Gemini Flash 3.8, and skills of normal size worked well.

This is not a claim that one model is generally superior; it reflects my experience with my own tasks. The practical conclusion, however, does generalise: using a skill may not require the most powerful model used to create it.

3. Common ground: the Agent Skills standard and progressive loading

Skills are not just a feature to compare across Gemini, Claude and ChatGPT. Coding agents and other tools support similar structures too. The common ground in this area is the open Agent Skills standard and its SKILL.md file structure. Under the standard, a skill is a folder containing at least one SKILL.md file. The file begins with a header carrying the name and description fields, followed by the body of instructions (1). The instructions of a Gem, a GPT or a Project can now be packaged in this shared, open format.

The standard itself quickly moved beyond the control of any single company. Anthropic announced Agent Skills on 16 October 2025 and published it as an open standard on 18 December 2025 (4). On 22 October 2026 it handed the standard over to the Agentic AI Foundation under the Linux Foundation. By then, more than 70 agent platforms, including ChatGPT, Cursor, GitHub Copilot and VS Code, had integrated it. According to the announcement, engineers from Anthropic, Google, OpenAI and other companies will maintain the standard from now on as individuals (2). The common ground is thus becoming common institutionally as well.

There is also concrete evidence of portability. According to Google’s help documentation, Gemini can import skills created on other platforms by uploading their SKILL.md files; for now this option is available only in Gemini’s Mac app and web app (3). The shared format, in other words, works not just on paper but as a direct import route on at least one platform.

The most valuable point in Gemini’s commentary concerns how this structure works. The system does not load the long bodies of hundreds of skills into the model at the start. It reads only their names and descriptions, picks the skill that matches the user’s request, and brings the full body into context only when that skill is activated. This is correct, and it is set out in the standard itself (1). Progressive loading turns the description field into the skill’s “front door”. A skill with a poorly written description may never be called, however good its instructions are.

A common file format, however, does not guarantee the same behaviour on every platform. When a skill is moved to another platform, the following can change:

• The limit and role of the description field
• The format rules for the name field and how Turkish characters are handled (see 9.6)
• How instructions are loaded
• Automatic selection and manual invocation methods
• The number of skills that can be active at the same time
• Access to additional files
• The ability to run code or scripts
• How consistently the model applies long instructions
• Sharing and distribution options

The real test of portability is therefore not whether the file uploads, but whether the skill behaves as expected.

4. The description field: the first concrete limit on portability

In Gemini Skills, the description field is limited to 1,000 characters. I write my descriptions close to that limit, in the 950–1,000 character range, packed with information. Gemini’s commentary judged this strategy to be the factor that directly determines successful selection under progressive loading. That holds for Gemini, but the strategy may not carry over to other platforms unchanged.

The standard sets an upper limit of 1,024 characters for the description field (1). In Claude, the picture turned out to be more complicated than expected, because two of Anthropic’s official documents contradict each other on this point. Anthropic’s help centre gives a maximum of 200 characters for a skill description (5). The current version of Claude’s developer documentation, by contrast, gives the standard’s 1,024-character limit and makes no mention of 200 characters at all (6). Both documents were accessed on 27 October 2026.

The two documents also differ on the name format. The help centre gives a human-friendly example name with spaces and capitals, “Brand Guidelines” (5). The developer documentation requires the name to contain only lowercase letters, numbers and hyphens, and to match the skill’s folder name (6).

The original working draft stated that in Claude, anything in the description beyond 200 characters is ignored. In Claude’s assessment this was most likely a misreading: what the help centre describes is not part of the text going unread, but a length limit that must be met at upload. A platform applying a narrower limit than the common standard is not a breach of the standard; it is a choice within the standard’s upper bound. The contradiction between the two official documents, however, leaves open the question of which limit the claude.ai interface actually enforces.

This section carries its own correction history. In Version 2, the limit was based on secondary sources. In Version 3, following ChatGPT’s review, it was described as confirmed by official documentation. But the 200-character statement attributed to the developer documentation in that version came from Claude relying on an old copy in a search engine index rather than opening the page directly. ChatGPT’s next review caught the error; the current version of the page says 1,024 characters. The fact that the indexed copy contained the 200-character statement may reflect an earlier version of the developer documentation, but when the change was made cannot be determined from the available information. The first level of evidence was thus shaken on two fronts: official documents can contradict each other, and different copies of the same document can carry different information. That is why access dates are recorded, and why a real upload test will have the final word.

The test will confirm one of two possibilities. If the claude.ai interface does enforce a 200-character limit, any description over 200 characters will need to be shortened considerably; descriptions close to 1,000 characters will have to be cut to about a fifth of their length. If the interface allows 1,024 characters, descriptions can be carried over with minor adjustments. Whichever is confirmed, the result will be the first concrete row in the portability table.

On the ChatGPT side, the instruction field limits I knew from building GPTs should not be confused with the new skill structure. The file-based skill structure differs from the old GPT instruction field, and the conditions under which long texts can be used there will be examined separately.

5. The instruction body: a question of architecture, not limits

In Gemini Skills I encountered no visible character limit for the instruction body, and I was able to run instructions of 30,000–40,000 characters. Both the original draft and Gemini’s commentary treated this as a question of “limits”. Claude’s assessment drew attention to something both had missed: for the body, the standard sets a design principle rather than a limit.

According to the standard’s section on progressive loading, the body, which is loaded into context in full when the skill is activated, should ideally stay under 5,000 tokens; the main SKILL.md file should stay under 500 lines, with detailed reference material moved into separate files (1). Claude’s developer documentation adopts the same 500-line recommendation and notes that Claude reads the whole of SKILL.md every time the skill loads (6). These are recommendations, not mandatory limits. The standard also states that there are no format restrictions on the body (1). During the review process, ChatGPT argued that these figures did not appear in the standard. When the relevant section was re-examined, however, the recommendations were found to be stated explicitly, and ChatGPT acknowledged in its later reviews that its earlier objection was wrong. The confusion arose because the “no format restrictions” statement and the length recommendations sit in different sections of the standard. Since Turkish text is heavy in token terms, a 30,000–40,000 character instruction sits well above the recommendation.

The real portability question, then, is not “will a long text be accepted?” It is whether a single-piece Gem instruction should be split into the multi-file structure the standard envisages. That question affects the production method too: the Gem Factory might need to produce a main file with linked reference files rather than single-piece instructions. Whether splitting reduces rule loss in long instructions can only be established by comparative testing.

Gemini raised a strong counter-argument in its review. In a multi-file structure, additional files are read only when needed, which requires the model to take a separate file-reading step. If, as in the Gem Factory, most of an instruction consists of an integrated workflow, pruning barriers and formatting rules that must be followed strictly at every step, splitting those rules into separate files could lead the model to skip some files and break the rules. In that case, a single-piece structure remains a strong option, because it removes both the cost of calling extra files and the risk of their not being read.

The two views meet in the standard’s own logic. The standard recommends moving not everything into separate files, but detailed reference material (1). A design principle follows: the core workflow and mandatory rules that must be applied in full on every run stay in the main file; only tables, examples and static data consulted under particular conditions go into separate files. This principle, too, is not yet a proven result but a hypothesis to be tested comparatively.

6. Technical acceptance, behavioural fidelity, and a model’s knowledge of itself

AI systems sometimes give inconsistent information about their own features, character limits or ways of working. I have observed this many times, particularly with Gemini. So I do not automatically trust what a model says about its own capabilities; where something can be tested numerically, I verify it in practice.

This approach requires separating three kinds of information:

1. The limit stated in official documentation.
2. The limit the interface actually accepts.
3. The extent to which the model applies the content it has accepted.

Uploading a file does not mean every rule in it will be applied fully in every task. Technical acceptance and behavioural success are different measures.

Gemini’s commentary added a technical explanation to this section. In its view, rules being skipped in long instructions may stem from attention dispersing over a long context and from output limits; the dispersal of attention is known in the literature as the “lost in the middle” effect (7). Claude agreed that this addition fits the third level, but pointed out that it merges two separate issues. A model giving wrong information about its own limits is a reliability problem. A model skipping rules it has accepted is a problem of attention and execution. The two have different causes and different remedies. Output limits, moreover, explain output being cut off rather than rules being skipped. Tests should therefore record “rule not applied” and “output not completed” as distinct error types. Gemini also found this distinction sound in its later review.

The writing of this article itself provided a live example for this section. In the info line of its first commentary, Gemini identified itself as “Gemini 3.1 Pro”, although the model in use was Argon. After a note on this was added to the article’s colophon, Gemini began writing “Gemini 4 Argon” in parentheses in the info line of its later replies, while continuing to describe itself as “Gemini Pro” at the start of the line. Gemini explained this by saying that the info-line rule asks for the working mode and the model version separately, and that it reflected the user’s explicit statement in the text into the version field. But this, too, is a model’s account of its own behaviour; it should be read as Gemini’s own interpretation, not as verified information. The same case therefore illustrates both points in this section: a model can misreport its own identity, and its explanation of why it did so also needs to be tested separately.

The same caution applies to how AI systems read documents. During the review of this article, each of the three AI systems made a different kind of error, and each error was exposed by another’s scrutiny:

• Gemini misreported its own model name in its info line: an error of self-knowledge.
• ChatGPT overlooked the standard’s section on progressive loading and dismissed the length recommendations it contains (Section 5): an error of incomplete reading.
• Claude quoted its own company’s developer documentation from an old copy in a search engine index rather than from the current page (Section 4): an error of currency.

These three examples are not enough to compare the overall reliability of the three systems; they are too few and too selective to support any conclusion about which is more reliable. What they show is something else: why, on questions of platform limits, one should rely on primary documents and real tests rather than on any single AI’s statement. Mutual scrutiny exposed not only the AI systems’ errors but also a weakness in the first level of evidence itself: two of Anthropic’s official documents contradicted each other. This is one of the reasons the article was produced with several AI systems, through mutual review, under human direction.

7. Distribution: two steps forward, one step back

One reason I converted my Gems into skills was to keep my production going. I had previously built and publicly shared many GPTs. But restrictions on creating and publishing GPTs affected the future of my work in that area. When the first working draft of this article was written, Gemini Skills had no public sharing option either. My skills were usable, but they could not reach a wider audience directly.

Google, for its part, announced at the end of September 2026 that some Gem features would come to skills, including sharing and adding files from Google Drive and Gemini Notebook (8). Google’s help documentation, accessed on 27 October 2026, still says these features are coming “in the coming weeks” (3). This is an announcement; to what extent the feature has actually reached personal accounts will be established separately through observation in my own account.

I sum this up as “two steps forward, one step back”. The skill structure made it easier to carry my Gems over without rewriting them and to adapt my production system; in production terms, that is progress. The lack of sharing, however, is a step back in distribution. Better production tools do not mean that sharing has improved to the same degree. This assessment will be revisited once the sharing feature becomes available.

I therefore plan to publish instruction texts both in the appendices of my articles and in linked public Google Drive folders. I already keep my skills on Drive, each in its own folder named after the skill, with its SKILL.md file inside. My plan is to write a separate article for each skill, include that day’s version of the skill text in the article, and give a public link to the skill’s Drive folder. The link points to the folder rather than the file so that later updates can be followed at the same address. The Turkish article will link to the Turkish skill’s folder and the English article to the English one; the article copy, images and videos will sit in the same folder. I have also added a separate task to the Gem Factory that prepares share-ready copies of skills. Gemini suggested incorporating this distribution structure into the text.

Even when a platform does not make a tool discoverable, publishing the text itself makes access independent of the platform. Anyone can study the text and adapt it to their own environment; thanks to the import route described in Section 3, a SKILL.md file can also be uploaded directly to Gemini. Gemini considered this a strong strategy for escaping platform lock-in and added a fair warning: unlike sharing a closed link, open text can be copied directly. Every published skill text should therefore come with an open licence setting out the terms of use and redistribution. The standard includes an optional licence field, which can hold the licence name or a reference to a licence file bundled in the skill package (1). The full terms of the licence, however, should sit in the licence’s own text, for example in a licence file added to the package.

8. Discoverability: being in the documentation versus being visible

I knew about ChatGPT’s GPTs, Claude’s Projects and Gemini’s Gems. Even so, I only learned about the skills approach by researching it after Gemini’s announcement. Anthropic, however, had announced Agent Skills on 16 October 2025 (4). A similar structure had thus existed for about a year before Gemini’s announcement. I also learned only later that the common standard had been published on 18 December 2025 (4) and that more than 70 platforms, ChatGPT among them, had already integrated it (2).

From this I cannot conclude that companies deliberately keep their features in the background. But the fact that even a heavy user like me remained unaware of this structure for a year shows the gap between a feature existing in technical documentation and being discoverable by users. Documentation alone is not enough for users to learn a technology. What a feature does, what it adds to existing ways of working, and under what conditions it can be used also need to be presented clearly.

9. A Turkish term for “Skills”: not “beceri” but “yapay zekâ yordamı”

9.1. The problem with “beceri”

In the Turkish interfaces of these platforms, “Skills” is rendered as “beceri”, the dictionary equivalent of “skill”. In dictionary terms it is an understandable choice. In everyday Turkish, however, its associations are not limited to ability and craft; it can also be pulled towards slang and sexual connotations, and towards insinuating meanings in ethical or interpersonal contexts. When choosing a word for a serious technical concept, one has to consider not only dictionary accuracy but also how the word sounds to the ear.

When Gemini Skills was first announced, I sent this view to Google as feedback. At the time I did not know that Claude and ChatGPT had similar structures or that the common standard had been published. My criticism is not that three companies using the same word is necessarily wrong. My point is that when a technical term is brought into Turkish, its cultural and semantic associations must also be taken into account.

9.2. Criteria for a Turkish equivalent

Gemini described the localisation teams’ choice of “beceri” as an understandable reflex, since most near-synonyms are already in use for other technical layers. This is correct, and it also sets the criteria a Turkish equivalent should meet:

• It should be short and fit Turkish’s suffix system easily: “yordamlar” (skills), “yordamım” (my skill), “yordamı çağırmak” (to call the skill).
• It should not clash with an established technical term. “Yetenek” already renders capability, “işlev” function, “araç” tool, “eklenti” plugin, and “talimat” and “yönerge” instructions.
• It should capture the essence of the concept: a packaged, reusable method describing how a task is done.
• It should not carry unwanted everyday associations. “Marifet” and “hüner” (both roughly “knack” or “talent”) fail this test because they lend themselves to ironic use.

Among the candidates that emerged in my earlier conversations with AI systems were “yordam” and “yetenek”. Claude pointed out a tension in Gemini’s commentary: Gemini said that “yetenek” was reserved for capability, yet also offered it as an option for Skills. Gemini agreed with this point in its later review. By these criteria, “yetenek” fails the second test, while “yordam” meets all four.

9.3. Why “yordam”?

The dictionary meaning of “yordam” is method or procedure. That is exactly what an AI skill does: it tells the AI by what method a task should be done.

The word also has deep roots in software. Turkish-speaking programmers liked and used “altyordam”, the Turkish term for subroutine. As someone who has been programming since 1976, my own preference was for “sub program”. That preference actually matched FORTRAN’s own terminology, since FORTRAN groups SUBROUTINE and FUNCTION together under the heading “subprogram”. Looking back, though, I accept that “altyordam” was a very fine word for the software world.

The only likely objection is possible confusion with the software meaning: a reader might mistake an AI skill for a routine written in code. There are two answers. First, saying “yapay zekâ yordamı” (AI procedure) on first mention establishes the context. Second, the confusion is not as wrong as it seems, because a skill can also contain scripts and code files (1). The software meaning does not block the new meaning; it bridges to it. First there were subroutines that told a computer how to do a task; now there are skills that tell an AI how to do a task in natural language. The analogy also fits my view that “the algorithm belongs to the user”: a skill’s value lies not in the language it is written in or the platform it runs on, but in the method it describes.

9.4. From “yapay zekâ yordamı” to “yordam”

The proposal has two stages. At first, the term should be used in its long form, “yapay zekâ yordamı”, to make the context clear; on first mention in a text one can write “yapay zekâ yordamı (Skill)”. My expectation is that the term will shorten naturally over time to “yordam”. Starting long and then shortening is the natural way terms settle into a language; in Turkish, “cep telefonu” (pocket phone) became simply “cep” in everyday speech, much as “mobile phone” became “mobile” in British English. And because “yordam” is less widely used in software today than it once was, I expect the risk of confusion to fade and the word to find a far more prominent place in the world of AI.

I should stress that this is a prediction. The word’s linguistic suitability can be argued for; whether it spreads depends on users and technical communities adopting it. Realistically, the platforms have already established “beceri” in their interfaces, and a new term will not easily pass into general use. The surest way for a term to take hold is through an accumulation of texts that use it consistently. This article and my future writing will be the start of that accumulation.

9.5. Towards a glossary

If skills are truly going to occupy an important place in the AI world, one word will not be enough. A small Turkish glossary will also be needed, covering concepts such as the description field, the instruction body, reference files, progressive loading, Gems and agents. I plan to prepare that glossary as a separate piece of work.

9.6. The problem of Turkish characters in technical names

The place of Turkish in skills is not only a question of terminology. Here two things need to be kept apart by level of evidence: what the standard says, and what Gemini does in practice.

What the standard says (first level): the Agent Skills standard limits a skill’s name to lowercase letters, numbers and hyphens. The name cannot begin or end with a hyphen, cannot contain consecutive hyphens, and must match the skill’s folder name (1). Although the standard’s wording refers to “unicode lowercase alphanumeric characters”, the parenthesis gives only a–z and 0–9 as examples; the text does not make clear whether letters specific to Turkish fall within this definition. This is an interpretation of the standard’s wording. Google’s documentation likewise requires names in Gemini to be written in lowercase with hyphens and the folder name to match the skill name, and states that the name will be updated automatically to the correct format when the skill is created (3).

What Gemini does in practice (second level): in my own account, Gemini performs this conversion itself, turning Turkish-specific letters such as ç, ğ, ı, ö, ş and ü into their nearest ASCII equivalents. I do not need to do this by hand; as a result, the technical names of my skills and their Drive folders are created without Turkish characters and with hyphens. The outcome is a two-layer naming system: on one side a technical name without Turkish characters, on the other a visible name with Turkish characters used in descriptions and texts. Under the conversion rule Gemini applies in my account, for example, the name “ATG Gem Fabrikası” becomes “atg-gem-fabrikasi” at the technical layer.

For my generation, used to working without Turkish characters since the early days of computing, this is not especially strange; for many years we wrote Turkish texts using the nearest ASCII letters. For younger generations, it may well seem odd. In my view, this is a situation that should not exist. I touched on this in an earlier piece of work as well. The ambiguity in the standard’s wording makes the handling of names with Turkish characters across platforms something that needs separate testing (third level).

10. The plan ahead

According to the timeline Google has published, Gems in personal accounts transition to skills and become read-only on 17 November 2026: they remain accessible but can no longer be used or edited, and new Gems cannot be created. On 17 December 2026 they are removed from Gemini apps entirely (3). I am waiting for this timeline. After 17 November I will work more intensively on skills and move my production to other platforms in stages.

In the first stage, I will organise my collection in Gemini and preserve the instructions and version information. According to Google, some files will not carry over during the transition (3); I will download those before 17 December.

In the second stage, I will examine description fields, instruction limits, active-skill limits and file upload conditions on Claude, ChatGPT and other suitable platforms. The first task in this stage will be a real upload test in the claude.ai interface with 200- and 1,024-character descriptions, to resolve the contradiction between Anthropic’s two documents. I will also test whether each platform rejects names with Turkish characters, converts them automatically, or accepts them as they are. My observation that disabled skills in Gemini can be invoked manually with @ or / will be verified by testing whether re-enabling is required. Gemini’s route for importing SKILL.md files from other platforms will be tried as well. The status of skill sharing in Gemini personal accounts will be checked in this stage. Whether long instructions should be split into reference files will also be decided here. Every documentation check will record its access date.

In the third stage, I will run comparative tests using the same sample inputs. These tests will look not only at whether the text is accepted, but at whether mandatory rules are applied, whether the output is complete, and what types of error occur. Skipped rules and cut-off outputs will be recorded separately. The tests will also compare a single-piece version of the same skill with a version that keeps mandatory rules in the main file and moves reference data into separate files.

At the end of this work I want to produce a compatibility table for each platform, showing clearly which skills can be moved directly, which need adaptation, and which features cannot be matched on another platform.

Conclusion

Custom assistants were the product of a period in which AI platforms offered users the means to build their own tools, but each was tied to its own platform. The common skills standard loosens that dependence through an open, shared format, and handing the standard to a neutral foundation makes the shift durable. For me, the move from Gems to AI skills is more than a change of name or file format: it is the experience of adapting eight months of accumulated production knowledge to a new way of working while preserving it.

Five conclusions emerge from this process. First, the requirements of a production system and those of the skills it produces are not the same; a skill created with a powerful model can be used with a more economical one. Second, a common standard does not guarantee the same behaviour; even a basic value such as the description limit can differ by a factor of five between platforms, though whether that difference is actually enforced in Claude has yet to be tested. Third, for long instructions the real question is architecture rather than limits; structures that keep mandatory rules in the main file and move reference data out may be needed, but this is still a hypothesis to be tested. Fourth, a new technology does not necessarily bring progress on every front; a structure that makes production easier can create new constraints on distribution. Fifth, even official documentation is not sufficient evidence on its own; two documents from the same company can contradict each other, and different copies of the same document can carry different information. Documentation should therefore be recorded with access dates and checked against real tests.

For the Turkish rendering of this concept, I propose “yapay zekâ yordamı” rather than “beceri”. The term draws on the Turkish software tradition of “altyordam”, and I expect it to shorten over time to simply “yordam”.

My real aim is not just to produce hundreds of tools, but to turn them into a body of knowledge that can be used, examined and developed sustainably across platforms. Rather than depending entirely on one platform, preserving and publishing my instructions, production methods and test results is the foundation of that aim.

References

(1) Agent Skills, “Specification”. https://agentskills.io/specification (Accessed: 27 October 2026)
(2) Anthropic, “Donating Agent Skills to the Agentic AI Foundation”, 22 October 2026. https://www.anthropic.com/news/donating-agent-skills-to-the-agentic-ai-foundation (Accessed: 27 October 2026)
(3) Google, Gemini Apps Help, “About the transition from Gems to skills”. https://support.google.com/gemini/answer/18560919 (Accessed: 27 October 2026)
(4) Anthropic, “Equipping agents for the real world with Agent Skills”, 16 October 2025, with an update dated 18 December 2025. https://www.anthropic.com/research/equipping-agents-for-the-real-world-with-agent-skills (Accessed: 27 October 2026)
(5) Anthropic, Claude Help Center, “How to create custom skills”. https://support.claude.com/en/articles/12512198 (Accessed: 27 October 2026)
(6) Anthropic, Claude Docs, “Create custom skills”. https://www.claude.com/docs/skills/how-to (Accessed: 27 October 2026)
(7) Nelson F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts”, Transactions of the Association for Computational Linguistics, 2024. https://aclanthology.org/2024.tacl-1.9/ (Accessed: 27 October 2026)
(8) Android Authority, “Gemini Skills are expanding to free accounts as Google prepares to sunset Gems”, September 2026. https://www.androidauthority.com/gemini-skills-expand-free-accounts-3716627/ (Accessed: 27 October 2026)

Colophon

Title: From Custom Assistants to a Common Standard: Gems, GPTs, Projects and AI Skills
Subtitle: A production experience, cross-platform portability, and a Turkish term for “Skills”
Authors: Aydın Tiryaki & Claude Opus 5.5 & ChatGPT (GPT-6) & Gemini 4 Argon
Type: Experience-based assessment and terminology proposal
Language: English. This English version was rewritten by Claude Opus 5.5 from the final Turkish text (Version 6) as an adaptation rather than a literal translation. Turkish examples are kept with English glosses, and the Turkish naming discussion in Section 9 is preserved in full.
Status: Final version. Gemini declared full agreement on Versions 4 and 5; ChatGPT considered the text ready for publication once the minor corrections it proposed for Version 5 were made. These corrections were made in Version 6. At the author’s decision, the text was finalised without being submitted to the review cycle again.

Contributions:

• Aydın Tiryaki: Owner of the subject, the experience and the ideas. Eight months of Gem production; the manual, improved conversion of nearly a hundred Gems into skills; the Gem Factory/Skills Editions production system; observations on model use; account observations on the 100-active-skill limit and on invoking disabled skills manually; the observation that Gemini converts skill names to ASCII automatically, and the two-layer naming practice; the distribution plan based on Drive folders. The criticism of the word “beceri”, the proposal of “yapay zekâ yordamı”, and the prediction that the term will evolve into “yordam”. Personal testimony on “altyordam” and his preference for “sub program”, the generational observation about working without Turkish characters, the work plan and the publication strategy. He set the article’s scope, title, structure, authorship arrangement, colophon format and production method, managed the review traffic between the AI systems, and made the decision to finalise the text.
• ChatGPT (GPT-6): Held a conversation on skills with Aydın Tiryaki and turned it into the original twelve-section working draft; the experience-based sections of the article rest on that draft. Reviewed Version 2: proposed checking Claude’s description limit against primary documentation, correcting the Gem transition timeline, the standard’s chronology, the conceptual distinction between Claude Projects and assistants, adding the 100-active-skill limit, and not presenting the terminology prediction as a definite outcome; proposed the method note based on three levels of evidence. Reviewed Version 3: caught that the 200-character statement Claude had attributed to the developer documentation did not match the current page; proposed correcting the licence-field wording, using Anthropic’s original announcement as the primary source, adding naming rules to the portability criteria, citing a source for the “lost in the middle” effect, recording access dates for sources, and stating that three errors are not enough to compare the systems’ overall reliability. Reviewed Version 4: proposed not presenting the inference that the documentation “changed recently” as established, separating the standard’s rule and Gemini’s conversion behaviour by level of evidence in 9.6, adding manual invocation of disabled skills to the test plan, giving access dates for all sources, and narrowing the “for the first time” claim. Reviewed Version 5: proposed explicitly tying the example in 9.6 to Gemini’s conversion rule, limiting “every skill” in Section 4 to descriptions over 200 characters, checking the governance statement against its source once more, and re-verifying the Gem dates before publication; recorded the repetition in the colophon as a question of publication strategy rather than accuracy. In later reviews, explicitly acknowledged that its Version 2 objection that the standard contains no 5,000-token and 500-line recommendations was wrong.
• Gemini 4 Argon: Wrote a critical commentary on the working draft. Its points on progressive loading, attention dispersal in long contexts, the localisation rationale for “beceri”, and the licensing and intellectual-property risk of sharing open text entered the article. Reviewed Version 2: proposed the counter-argument in favour of a single-piece structure, moving the model-name note into Section 6 as a live example, adding the year to the 17 November date, and incorporating the Drive-folder distribution structure. From Version 3 onwards, reminded that the author uses skill names without Turkish characters and with hyphens, and proposed adding the two-layer naming. In its review of Version 5, stated that under progressive loading the technical names of active skills are loaded into its own conversation context and that it read the name “atg-gem-fabrikasi” from that context, thereby correcting Claude’s statement that “Gemini cannot see your account”. Declared full agreement on Versions 4 and 5. Note: In the info line of its first reply, Gemini identified itself as “Gemini 3.1 Pro”; the model used was Argon. In later replies it wrote “Gemini 4 Argon” in parentheses but kept “Gemini Pro” at the start of the line. Gemini does not report its model correctly in its info line.
• Claude Opus 5.5: Main writing environment. Evaluated the working draft and Gemini’s commentary. Verifying the Agent Skills standard and platform limits through web research, treating body length as a question of architecture, and the critique of two points in Gemini’s commentary are Claude’s. Contributed to grounding the “yordam” proposal in “altyordam” and FORTRAN, and proposed the title options. Compared the Version 2 reviews against primary sources and refuted ChatGPT’s 5,000-token and 500-line objection with the standard’s own text; reconciled the single-file versus multi-file debate in a design principle based on the standard’s logic. In Version 3, made the error of quoting the developer documentation from an old copy in a search engine index; following ChatGPT’s warning, opened the documents directly, acknowledged the error, and in the process found that Anthropic’s help centre and developer documentation contradict each other on both the description limit and the name format, that Gemini can import SKILL.md files from other platforms, and that the standard’s name definition is ambiguous. After Version 5, withdrew its overly categorical statement that Gemini could not see skill names, following Gemini’s correction, and checked the governance statement against its source again. Wrote every version of the article and adapted this English version from the final Turkish text.

Production process and method:
The article was produced through an iterative consensus method between three AI systems.

1. Start: Aydın Tiryaki’s conversation with ChatGPT was turned by ChatGPT into the first working draft.
2. First review: The draft was passed to Gemini, and Gemini’s critical commentary was obtained.
3. Main writing: The draft and Gemini’s commentary were passed to Claude. Evaluation, source verification, the terminology discussion and the writing of the article took place in Claude. The main text was kept in Claude.
4. Review cycle: Each version written in Claude was passed by Aydın Tiryaki separately to ChatGPT and Gemini for review. Their reviews were brought back to Claude, discussed, and a new version was written. The cycle continued until the author and the three AI systems reached agreement.
5. Expansion: The option of bringing other AI systems into the review cycle was kept open; it was not used for this article.
6. Finalisation: After the fourth review round, the author decided to keep the colophon as it was and to finalise the text as the final version.
   At every stage, the author decided which suggestions entered the text.

Review rounds:

• Round 1 (on Version 2): Gemini (exchange #2) and ChatGPT (exchange #18) reviewed Version 2 separately. Claude compared the two reviews against primary sources and prepared a synthesis (exchange #9).
• Round 1 supplement (on the synthesis): Gemini (exchange #3) and ChatGPT (exchange #19) reviewed Claude’s synthesis. Gemini supported it; ChatGPT withdrew its judgement on the 5,000-token and 500-line question and proposed the three levels of evidence. Claude evaluated these replies (exchange #10).
• Round 2 (on Version 3): Gemini (exchange #4) and ChatGPT (exchange #20) reviewed Version 3. Claude re-checked the documents by opening them directly, acknowledged its own error and prepared a synthesis (exchange #12).
• Round 2 supplement (on the synthesis): Gemini (exchange #5) and ChatGPT (exchange #21) reviewed the synthesis; both agreed on the content. Claude asked for the author’s confirmation (exchange #13). The author confirmed that Gemini automatically converts Turkish characters in skill names to their nearest ASCII equivalents.
• Round 3 (on Version 4): Gemini (exchange #6) declared full agreement on Version 4. ChatGPT (exchange #22) said no major rewrite was needed and proposed limited corrections, which were made in Version 5.
• Round 4 (on Version 5): Gemini (exchange #7) reiterated its full agreement and corrected one of Claude’s statements. ChatGPT (exchange #23) proposed four minor corrections and considered the text ready for publication once they were made. Claude evaluated these suggestions (exchange #16). The author decided to keep the colophon as it was and to finalise the text; the corrections were made in Version 6.
• Suggestions not adopted: Gemini’s suggestion to explain the 100-active-skill limit as a mathematical consequence of progressive loading (“100 × 1,000 characters”) was not adopted, because Google has not given a rationale for the limit and 1,000 characters is a maximum, not an average. The term “GFU1 injection” used by Gemini was left out because it is the author’s internal production term and not informative for general readers; Gemini supported this decision. Gemini’s suggestion that articles might not include the full skill text was not adopted because it conflicted with the author’s plan; Gemini withdrew it. The grandiose framing of the three AI errors as a “triumph” of the method was not used, since three examples cannot support such a generalisation. ChatGPT’s publication-strategy suggestion to move the process details of the colophon into a separate appendix was not implemented, following the author’s decision to keep the colophon as it was.

Version history:

• Version 1 (27.10.2026): First draft written in Claude.
• Version 2 (27.10.2026): The title was broadened to cover all platforms’ custom assistants, and a subtitle was added. The introduction was rebuilt for this scope, the Gem experience was positioned as a case within the broader picture, and a paragraph tying this framework together was added to the conclusion. The process description in the colophon was expanded and a version history added.
• Version 3 (27.10.2026): Results of the first review round incorporated. The Projects distinction, ChatGPT’s adoption of the standard and the method note were added to the introduction. The difference between automatic and manual conversion and the 100-active-skill limit were added to Section 1. The standard’s chronology and its handover to the foundation were added to Section 3. In Section 4 the 200-character limit was grounded in official documents. In Section 5 the nature of the recommendations was clarified, and ChatGPT’s objection and its resolution, Gemini’s counter-argument and the synthesis principle were added. The model-name case and the document-reading error were added to Section 6. Google’s sharing announcement and the Drive distribution structure were added to Section 7. Section 8’s chronology was updated. In 9.4 the terminology prediction was presented as the author’s expectation. In Section 10 the Gem timeline was corrected. The references were reorganised.
• Version 4 (27.10.2026): Results of the second review round incorporated. The limits of the first level of evidence and access dates were added to the method note. In Section 1 the 100-active-skill limit was supported by Google’s documentation. The chronology based on Anthropic’s original announcement, Gemini’s SKILL.md import route and the naming-rules item were added to Section 3. Section 4 was rebuilt around the contradiction between Anthropic’s two documents and Claude’s corrected error, with the outcome tied to a real upload test. The 500-line recommendation in Claude’s developer documentation was added to Section 5. The “lost in the middle” source and the paragraph cautiously comparing the three AI errors were added to Section 6. In Section 7 the licence-field wording was corrected, and the sharing wording in Google’s current documentation and the import route were added. In Section 8 the source was replaced with the primary announcement. A new subsection, 9.6, was added. Upload, naming and import tests were added to Section 10. A fifth conclusion was added. The references were renumbered.
• Version 5 (27.10.2026): Results of the third review round incorporated. The “for the first time” claim was narrowed to the format provided by the open, shared standard. The statement that documents “change over time” was narrowed to different copies of a document carrying different information. In Section 1, manual invocation of disabled skills was marked as the author’s observation. In Section 4 the inference about when the developer documentation changed was rewritten cautiously. In Section 5 it was clarified that Claude’s documentation adopts the 500-line recommendation from the standard. In Section 7 Google’s announcement and the account observation were clearly separated. 9.6 was split into two levels of evidence and the standard’s additional naming rules were added. A disabled-skill test was added to Section 10. Access dates were given for all sources.
• Version 6, final (27.10.2026): Results of the fourth review round incorporated. In Section 3 the governance statement was corrected to match the future tense of the source. In Section 4 the 200-character scenario was narrowed to descriptions over 200 characters. In 9.6 the technical name example was explicitly tied to the conversion rule Gemini applies in the account. The finalisation decision, the fourth round, Gemini’s correction and the open questions were added to the colophon. At the author’s decision, the colophon was kept in research-log form.
• English version (27.10.2026): Adapted from Version 6 by Claude Opus 5.5.

Verification notes: Anthropic’s help centre gives 200 characters for the description, Claude’s developer documentation gives 1,024 (both accessed on 27.10.2026). The 100-active-skill limit in Gemini is confirmed both by the author’s account observation and by Google’s documentation. Manual invocation of disabled skills and Gemini’s automatic ASCII conversion of skill names are the author’s observations; the name “atg-gem-fabrikasi” also matches the name Gemini reports reading from its own conversation context. The Gem transition dates (17 November and 17 December 2026) are based on Google’s documentation as accessed on 27.10.2026 and will be re-checked before publication. Gemini’s own explanation of its model-name behaviour has not been verified. Model names (Argon, Pro 3.1, Flash 3.8) are given as the author uses them.

Open questions: The following were unresolved at the time of writing and are left to the work plan in Section 10.

1. Whether the claude.ai interface actually enforces a 200-character or a 1,024-character limit on the description field, and whether it rejects or truncates a description that exceeds the limit.
2. Whether an earlier version of Claude’s developer documentation contained the 200-character statement, and when the change was made.
3. Whether skill sharing in Gemini has become available in the author’s personal account.
4. Whether disabled skills in Gemini can always be invoked manually with @ or /, or whether re-enabling is required.
5. How skill names with Turkish characters are handled on Claude, ChatGPT and other platforms, and whether the “unicode” wording in the standard’s name definition covers Turkish-specific letters.
6. How Gemini’s route for importing SKILL.md files created on other platforms works with the author’s skills.
7. Under what conditions long instructions can be used in ChatGPT’s file-based skill structure.
8. The comparative performance of a single-piece skill structure versus a multi-file structure that keeps mandatory rules in the main file and moves reference data out.
9. The accuracy of Gemini’s own explanation of its model-name behaviour in the info line.
10. Which open licence will be used for published skill texts.

| 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 ░ | ░ Özel Asistanlardan Ortak Standarda: Gem’ler, GPT’ler, Projeler ve Yapay Zekâ Yordamları (Skills)│ From Custom Assistants to a Common Standard: Gems, GPTs, Projects and AI Skills ░ 27.10.2026