Gemini Gems to skills migration: preserve and test a copy

A Gemini Gems to skills migration should begin with a preserved instruction copy and a small set of checks. After this exercise, you can prepare a transition record for one file-free Gem and, where your account has access, recreate its text instructions as a skill. A saved copy is not proof of a completed migration or identical future responses.

A Gem is a customized Gemini assistant guided by saved instructions. A skill is a reusable instruction set. This article concerns Gemini Apps, not a skill package for another agent platform. AI means artificial intelligence; the exercise transfers written guidance rather than training a separate model.

Content checked: 15 October 2026. Google's current documentation distinguishes account types and rollout conditions. The practical route assumes one existing Gem you own, with no Knowledge files. All sample requests below are fictional teaching material. No live migration, account test or measured productivity result is reported.

Which transition date applies to your account?

Google says the change begins in November 2026 for personal Google accounts. Its schedule lists March 2027 for Workspace business, enterprise and non-profit accounts, and June 2027 for education accounts. Do not interpret those periods as a promise that every account receives the same screen on a particular day.

The current skills guide requires an adult personal-account user, sign-in and Keep Activity enabled, and warns that access is rolling out gradually. It says work and school accounts are not supported yet. Do not move company material into a personal account to bypass that boundary. Without appropriate access, stop at a permitted local instruction copy and an unresolved transition note.

Google also describes an automatic transition. Preparing a copy is therefore not a claim that everyone must perform an urgent manual migration.

What should you preserve from the existing Gem?

Open your own Gem's editing view. Copy its name, description if present and full instruction text into a document. Record the account type, review date and whether the Knowledge section contains files. If files exist, do not call this text-only exercise a completed knowledge migration; that is a separate scope.

Open Notepad or another plain-text editor. Add headings for original Gem name, account type, instruction version, instructions, attached files, new skill name, test results and status. Paste the instruction text under its heading. Press Ctrl+S, choose Documents and save gem-transition-01.txt. Close and reopen it, checking that the final instruction sentence survived.

Do not improve the original while taking this first copy. Preserve what you are transferring, then make deliberate revisions in another version. Otherwise, a changed response might come from your rewritten rule rather than the platform transition. Use a storage location you are permitted to use; no real customer material is necessary for the examples here.

The custom instructions guide discusses reusable preferences in a different product. It is background reading, not the button map for this Gemini transition. Here, we are preserving one named assistant's instructions rather than changing global settings or promising that previous conversations become part of a new skill.

How do you recreate a text-only version?

Continue only where Skills is available in an appropriate personal account. In Gemini's sidebar, open Customize; if it is hidden, check More. Then open Skills. On that page choose Create, followed by Create manually. Google's current management guide documents that route; follow the actual account interface rather than an obsolete screenshot.

Enter a lower-case hyphenated name such as project-update-review-01. Write a description explaining when the instruction should be used, and paste the preserved text into the instructions field. Select Create. No file upload or ZIP preparation belongs in this example because you deliberately chose a Gem without Knowledge files.

Find the new name in the Skills list and reopen it to inspect the saved wording. Merely pasting text into a form does not prove that it was created. Google's Gem guidance also makes an important older-stage distinction: a preview response does not automatically save a Gem. Treat visible output and saved configuration as separate checkpoints.

If the menu is absent, record copy preserved, Skills access unavailable. Do not keep changing unrelated settings. The freelancer prompt examples can help frame a small task while you wait, but an ordinary chat trial is not evidence that a saved Gemini skill exists.

The following fictional rule is available for practising the test design. It is not a silent replacement for your original Gem. Using it instead means you are testing a new instruction version, which should be labelled accordingly.

You review short project updates. Use only the supplied notes. Respond with Confirmed work, Proposed next steps and Open questions. Never turn a suggestion into an approved commitment. Preserve supplied owners and dates exactly. If notes conflict, show the conflict and ask which source governs. Do not invent completion, deadlines or customer approval. A tidy update is a draft, not permission to send it.

Which three requests expose useful differences?

The three inputs and expected behaviours below apply to the sample project-update instruction above. For a Gem with a different purpose, choose one routine request, one incomplete request and one conflicting-input request that fit its preserved instructions. Write the acceptance criteria from those instructions before testing, and use identical inputs for the old and new versions. Do not rewrite your original Gem merely to make it pass the sample editor's tests.

Use the same three inputs with the old and new versions where both remain available. If the old Gem no longer opens, use a previously saved, checked response. If none exists, state that no before-and-after comparison was performed. You can still evaluate the new version against your written acceptance criteria.

First input: “Confirmed work: the sample image was selected. Proposed next step: review its caption. Owner: project coordinator.” The expected behaviour is to keep confirmed and proposed work separate. Reject an update claiming that the caption was reviewed or approved. Neither the selection of an image nor a fluent summary establishes that extra fact.

Second input: “We need an update on the caption review, but its status and owner were not supplied.” The expected behaviour is to ask about those gaps or mark them unconfirmed, not invent a finished task. Third input: “One note gives Tuesday as the delivery day; another says Thursday for the same delivery.” Expect a visible conflict and a question about the governing source.

To request a specific skill, type / in a chat, or @ where the updated shortcut is available, and select its name. Google documents both explicit selection and automatic use of relevant active skills. Observe which instructions affect the trial. If another skill appears to influence the result, note that limitation rather than claiming an isolated comparison.

For each request, save the version used, the observed response and one of three decisions: acceptable, needs correction or untested. Do not invent an improvement percentage. If a rule needs work, change one part and repeat the same request.

Which capabilities should not be assumed to transfer?

Google's transition page lists current limitations for skills, including tools such as Canvas and Deep Research that do not yet work in the same way. A copied text instruction is not proof that an entire tool-dependent workflow has moved successfully. That is why this exercise stays with a file-free text assistant.

Google says supported knowledge files will be included in the automatic transition. Do not turn that statement into a claim that your files have already arrived and been checked. For a file-based Gem, list the important documents and source-dependent questions separately. This article does not perform that file audit or certify every format.

Keep the old Gem until the replacement has been checked and you know which version to use. Record the name of any early manually created skill so it is not confused with later transition activity.

The NotebookLM source maintenance guide covers a related but different problem: checking revised documents and their downstream answers. Here, your primary object is the instruction itself. A source update, an instruction transfer and a change in tool support deserve separate status notes.

What should you finish within fifteen minutes?

1. Minutes one to three: identify the account and one file-free Gem. Expected output: an eligibility and scope note.
2. Minutes four to seven: copy the instructions into a local document and reopen it. Expected output: a readable preserved version.
3. Minutes eight to twelve: where eligible, create the skill and run the three requests. Expected output: observed responses and explicit differences.
4. Minutes thirteen to fifteen: update the transition record. Expected output: an honest stage-by-stage status.

This is a planning allowance, not a measured completion promise. If the trial runs longer, write copy saved, replacement untested. Reopen gem-transition-01.txt, paste the new name, three responses, decisions and unresolved work, then press Ctrl+S. Close and reopen the file. Also locate the saved skill again; a result you cannot find is not a completed retrieval check.

In my earlier writing about effectiveness and perfection, I described projects delayed while pursuing every detail. Applied here, the principle is to preserve and check one instruction before attempting to perfect every assistant at once. It is not a claim that I ran a Gemini migration or measured a productivity gain.

For a wider workflow handoff, the SOP guide helps define owners and completion checks. The artificial intelligence guide provides broader context. Today's outcome is either a preserved instruction with an explicit blocker or a recreated skill with three checked trials; do not label those two outcomes as the same stage.