Gemini skills need separate checks for app and Workspace availability
The date once advertised for Workspace’s Scheduled Release is no longer a launch promise. Google’s 13 October correction separates two rollout tracks.
What happened
Google’s 13 October update started the Gemini app skills rollout while delaying Workspace skills until further notice.
Why it matters
A reusable instruction format does not make availability, migration and administrative controls identical across surfaces.
Teams expecting Google Workspace skills on 19 October should revisit the official 13 October correction. Google says the Gemini app rollout began on 13 October, with completion expected by mid-November. Skills in Workspace, for both Rapid and Scheduled Release domains, were delayed until further notice. This is a six-day-old correction with an immediate scheduling consequence, not a new 19 October release.
Separate the surfaces
The same update says sharing Gemini app skills and integration with Drive will come later. It points administrators to Workspace skill controls, while saying there are no admin controls for skills in the Gemini app. Those statements do not establish identical availability or policy enforcement across the two products.
Google’s migration guidance describes reusable Markdown-based instructions but says skills do not currently sync between the app and Workspace; users must recreate them for use across both. Its timeline table still includes earlier Workspace dates. The dated delay notice should therefore take precedence over treating that table as evidence that a launch happened. Neither source is an inspection of your tenant.
A bounded readiness check
Our proposed next action is to record the exact surface, account edition and observed feature availability before scheduling a migration. Have an administrator separately check the relevant control, and have a workflow owner test one non-sensitive example in that surface. Keep the existing process available until the replacement behaves as required. This is a proposed check, not a tested guarantee of reliability.
For a copied instruction, retain its owner, version and attached-knowledge requirements. Recheck those inputs after manual recreation; a shared file format does not demonstrate matching data access or permissions. Do not announce organisation-wide readiness because one user can see a feature.
The earlier skills dependency analysis explains package governance. This update adds a narrower boundary: the place where an instruction is used has its own rollout and control state. Train and migrate against observed availability, while leaving unconfirmed release dates unconfirmed.