Home › Skills in Workspace
A skill that works perfectly in the Gemini App can be completely absent from Workspace, and the reverse is equally true. This is not a bug and not a sync delay. They are two separate systems with two separate uploads, and confusing them produces the convincing impression that a correctly built skill is broken.
The rule: if you use both surfaces, upload every skill twice, enable it twice, and test it twice. There is no shared library and no propagation.
The format rules are identical on both sides. The same SKILL.md works in both. Only the upload and the enable step are separate.
| Thing | Shared? | Notes |
|---|---|---|
| The SKILL.md file itself | Yes, in effect | One file, uploaded to both |
The name and description rules | Yes | Identical. 64 and 1024 character limits on both |
| Supported file types | Yes | Text formats plus PDF, JPG, PNG |
| The 100 active / 100 MB limits | Yes, applied account-wide | Not doubled by having two surfaces |
| The uploaded skill list | No | Each surface has its own |
| Enabled or disabled state | No | Enabling in one does nothing to the other |
| Gems | No | Gems were never a Workspace feature |
The limits are account-wide, not per surface. If you upload the same skill to both surfaces, it counts once against your 100 active limit, not twice. You do not get 200.
The failure mode is specific and repeatable: you build a skill, test it in whichever surface you use most, it works, and you conclude it is fine. Then you open the other surface, ask for the same thing, and it does nothing.
At that point two explanations are equally consistent with the evidence, and the wrong one is more likely to be believed:
| Explanation | How likely | How to tell |
|---|---|---|
| The skill was never uploaded to this surface | Most likely | Check the skill list in this surface. If it is not there, that is the answer. |
| The file is wrong | Less likely | It works in the other surface with the identical file |
| The folder name does not match | Possible | Then it would fail in both surfaces, not one |
| The description is too vague | Unlikely | Then it would fail in both |
The diagnostic shortcut: if a skill works in one surface and not the other, the file is correct. Look for the upload, not the content.
The full troubleshooting path, including the three silent failures that affect both surfaces equally, is on why your skill never runs.
Before uploading twice, establish which surfaces you use. This is worth two minutes because maintaining two copies has a real cost.
| You use | Uploads needed | Effort |
|---|---|---|
| Only the Gemini App | One | None beyond the initial upload |
| Only Workspace | One, through Workspace | Same |
| Both, occasionally | Two | Double, but low frequency |
| Both, daily | Two | Highest — you now maintain a sync problem |
Worth reconsidering — Uploading to both surfaces daily means every edit has to be made twice. If one surface is only occasionally useful, the manual duplication is often the wrong trade. Pick the one you actually rely on.
Better — Upload to the surface you use daily. For the occasional need, accept that the skill is unavailable there, or set a reminder to update it when you next use that surface.
If you do upload to both, the risk is not the upload. It is editing one copy and forgetting the other.
Keep the master SKILL.md on disk. Both surfaces are copies of it. Never edit inside either surface.
A git repository gives you history and makes the diff between what you uploaded and what you have now obvious.
After an edit, re-upload to both surfaces in one sitting. Doing it immediately is the only reliable method.
Most skill interfaces show a last-modified date. If the two dates differ, you have drift.
This is a real advantage over Gems. Skills are files. You can keep them in git, diff them, and roll them back — none of which was possible with Gems, which stopped being editable on October 13, 2026.
Skills in a Workspace account are visible to the people who have access to that account, which has consequences for anything you built privately.
| Consideration | What to do |
|---|---|
| Other members can use your skill | Do not upload client instructions or commercial work to a shared Workspace without checking who is in it |
| Account-wide limits | Your 100 active and 100 MB apply across everything you upload |
| Admin controls | Some Workspace accounts restrict who can create skills. If upload fails with no file error, this may be why. |
| Admin visibility | Skills can be visible to Workspace admins regardless of who uploaded them |
For personal or client work, the Gemini App is the safer surface because visibility is scoped to one account. The validator on this site runs entirely in your browser for the same reason — the contents of your instructions are not sent anywhere.
Gems were a Gemini App feature. There was no equivalent in Workspace to migrate from, which means Workspace users reading about the November 17 shutdown may be trying to prepare for something they never had.
| Situation | What applies |
|---|---|
| Workspace only, never used Gems | Nothing to migrate. The shutdown does not affect you. |
| Both surfaces, used Gems in the App | Migrate the Gems, then upload the resulting skills to both |
| Workspace only, but skills already | Nothing changes. Skills are unaffected by the shutdown. |
The Gems vs Skills comparison covers the storage and activation differences, and the migration timeline covers the dates.
No. They are separate systems with separate uploads. This is the single most common cause of a skill appearing to be broken when it is correctly built.
No. The 100 active limit and the 100 MB total are account-wide, not per surface.
Skills uploaded to a Workspace account can be visible to administrators regardless of who uploaded them. For client work or anything commercially sensitive, use a personal surface.
Almost always because it was never uploaded to Workspace. If it is listed there and still does not fire, it may still be disabled — that is the default state after upload on both surfaces.
No. Gems were a Gemini App feature. If you never used Gems, the November 17 shutdown has nothing to do with you.
Not natively. You upload the same file twice. Keeping the master in git and re-uploading after each change is the practical approach.