Von Gems zu Skills: Gemini-Anpassungen werden zu wiederverwendbaren Arbeitsabläufen
Googles schrittweiser Übergang ist mehr als eine neue Bezeichnung. Bereiten Sie Anweisungen, Referenzdateien und Prüfbeispiele vor, bevor Sie ein vertrautes Gem in einen kombinierbaren Skill überführen.
Originalillustration der Redaktion. Sie zeigt die Idee wiederverwendbarer Anweisungen, keinen Screenshot von Gemini und keine interne Architektur.
Personalisierung wird zu einem der interessantesten Bereiche der KI für Verbraucher. Ein nützlicher Assistent weiß nicht nur viel; er erinnert sich daran, wie eine Person wiederkehrende Aufgaben angegangen haben möchte. Ein Recherchebriefing, eine redaktionelle Prüfung und eine Projektübergabe brauchen unterschiedliche Maßstäbe. Diese Maßstäbe in jedem Gespräch zu wiederholen ist mühsam, und sie unausgesprochen zu lassen führt zu uneinheitlichen Ergebnissen.
Googles Übergang von Gems zu Skills greift dieses Problem auf. Statt jede angepasste Assistenz als völlig separates Ziel zu behandeln, können wiederverwendbare Anweisungen Teil des bereits laufenden Gesprächs werden. Auf der Oberfläche wirkt diese Änderung klein, hat aber größere Auswirkungen darauf, wie Menschen ihre Arbeitsabläufe organisieren. Sie bringt auch Migrationsarbeit mit sich: Ein vertraulicher Anweisungssatz ist nicht automatisch gut definiert, portabel und überprüfbar.
Der Rollout unterscheidet sich je nach Kontotyp
Google plant den Rollout von Skills in der Gemini-App ab dem 13. Oktober 2026; der Abschluss wird bis Mitte November erwartet. Der Workspace-Rollout beginnt am 5. Oktober. Die Freischaltung erfolgt schrittweise, daher kann die Verfügbarkeit je nach Konto variieren. Ankündigung von Google Workspace
Laut Googles Hilfe beginnt der Übergang von Gems zu Skills für private Konten im November 2026. Für Workspace-Konten startet er im März 2027 bei Business-, Enterprise- und Non-Profit-Konten und im Juni 2027 bei Education-Konten. Die Umstellung erfolgt schrittweise; prüfen Sie die Hinweise für Ihr Konto und wenden Sie sich bei verwalteter Verfügbarkeit an Ihren Administrator. Hilfe zum Übergang von Gems zu Skills
Ein Skill sollte eine wiederholbare Aufgabe beschreiben
Google beschreibt Skills als wiederverwendbare Anweisungen, die chatübergreifend eingesetzt, ausdrücklich ausgewählt oder bei passender Relevanz angewandt und für komplexere Aufgaben kombiniert werden können. Die aktuelle Anleitung zur Erstellung unterstützt eine Datei SKILL.md im Stammverzeichnis mit optionalem unterstütztem Referenzmaterial und nennt Einschränkungen für externe Aktionen hochgeladener Skripte. Dadurch ist es wichtig, eine Anweisungssammlung von einem uneingeschränkten Programm mit Berechtigung zur Bedienung von Websites zu unterscheiden. Skills für Gemini-Apps erstellen und verwalten
Der einfachste Fehler ist, jeden langen Prompt in einen Skill zu verwandeln. Länge ist nicht das entscheidende Merkmal. Ein nützlicher Skill hat eine erkennbare Aufgabe, eine klare Eingabe, einen Standard für die Ausgabe und Bedingungen, unter denen er nicht handeln sollte. Fehlen diese Elemente, kann die automatische Wiederverwendung eine Unklarheit wiederholen, statt Zeit zu sparen.
Stellen wir uns eine hypothetische Anpassung namens „Recherchebriefing“ vor. Sie sollte nicht nur „Sei gründlich“ sagen. Sie könnte eine Forschungsfrage, ein Stichtagsdatum, Links zu Primärquellen und die Unterscheidung zwischen bestätigten Befunden und Interpretation verlangen. Sie könnte verbieten, eine Quelle zu erfinden, wenn Belege fehlen. Solche Anforderungen machen das Ergebnis leichter überprüfbar und die Aufgabe leichter erkennbar.
Betrachten wir nun eine separate Anpassung für den „Redaktionsstil“. Sie könnte kurze Absätze, klare Sprache und konsistente Überschriften vorgeben. Sie von den Beleganforderungen zu trennen, kann die Wiederverwendung flexibler machen. Ein Nutzer könnte denselben Belegstandard auf eine technische Untersuchung und ein Nachrichtenbriefing anwenden und dabei unterschiedliche Schreibstile wählen. Darin liegt der Reiz der Kombination, sofern sich die Anweisungen nicht widersprechen.
Erfassen Sie die Absicht, bevor Sie den Text kopieren
Notieren Sie vor dem Überführen eines Gems, was es gut macht. Für welche Aufgaben verwenden Sie es? Welche Informationen stellen Sie gewöhnlich bereit? Welche Teile des Ergebnisses korrigieren Sie immer? Welche Referenzdateien sind unverzichtbar, und welche wurden vor Monaten für eine einmalige Aufgabe hinzugefügt? Diese Bestandsaufnahme ist wertvoller, als einen Prompt zu bewahren, dessen zufällige Komplexität niemand versteht.
Trennen Sie dauerhafte Regeln von vorübergehendem Kontext. „Die Behauptung eines Unternehmens von einer unabhängigen Messung unterscheiden“ ist eine dauerhafte Rechercheregel. „Unser Start ist nächsten Donnerstag“ ist vorübergehender Kontext und kann schon mit dem nächsten Kalenderwechsel falsch sein. Eine wiederverwendbare Anweisung sollte nicht stillschweigend alte Fakten in eine neue Aufgabe tragen, nur weil sie einmal nützlich waren.
Prüfen Sie, ob Beispiele private Informationen enthalten. Ein echter Kundenname, eine interne Adresse oder ein noch nicht veröffentlichter Geschäftsplan kann als bequemes Beispiel in den ursprünglichen Prompt geraten sein. Daraus folgt nicht, dass es in eine wiederverwendbare Konfiguration gehört. Ersetzen Sie unnötige Einzelheiten durch neutrale Beispiele und schützen Sie erforderliches sensibles Material durch passende Konto- und Zugriffsregeln.
Die Bestandsaufnahme sollte auch unausgesprochene Annahmen ermitteln. Vielleicht prüfte eine Kollegin immer die endgültigen Zahlen, oder Sie stellten vor Beginn stets ein Quelldokument bereit. Wenn der neue Arbeitsablauf den Skill in vielen Gesprächen verfügbar macht, gelten diese Annahmen womöglich nicht mehr. Machen Sie daraus ausdrückliche Anforderungen, statt zu hoffen, dass der umgebende Kontext gleich bleibt.
Bewahren Sie eine portable Referenzkopie auf
Originale Migrations-Checkliste. Der Vergleich ist ein vorgeschlagener Prüfprozess und kein von Google berichtetes Migrationsergebnis.
Eine portable Kopie bietet etwas, das sich bei einer Oberflächenänderung prüfen lässt. Sie kann Name, Zweck, Anweisungen, Liste der Referenzdateien und einige Beispielaufgaben enthalten. Verwenden Sie gewöhnliche Formate, die sich ohne Abhängigkeit von einem Produkt lesen lassen. Das verspricht keine universelle Importkompatibilität; es bewahrt die Bedeutung der Anpassung, auch wenn sich der Importmechanismus unterscheidet.
Notieren Sie bei Referenzdateien, warum jede Datei enthalten ist und wann sie zuletzt geprüft wurde. Ein Richtliniendokument kann für eine Organisation maßgeblich und anderswo irrelevant sein. Ein Styleguide kann veralten. Eine Tabelle enthält womöglich Informationen, die nicht außerhalb des Teams geteilt werden dürfen. Der Dateiname allein erfasst solche Einschränkungen selten.
Bewahren Sie die ursprüngliche Konfiguration auf, während Sie den Kandidaten bewerten. Eine Migration kann den Wortlaut erhalten und dennoch das Verhalten verändern, weil sich das umgebende Modell, die Werkzeuge oder der Gesprächskontext unterscheiden. Eine Referenz für die Rückkehr zur alten Version hilft, ein Anweisungsproblem von einer Plattformänderung zu trennen. Sie verhindert auch, dass eine hastige Überarbeitung zur einzigen überlebenden Fassung wird.
Verwechseln Sie Portabilität nicht mit uneingeschränkter Weitergabe. Eine Konfiguration kann lizenziertes Referenzmaterial oder private Informationen enthalten. Dass sie in eine Textdatei passt, macht es nicht automatisch angemessen, sie zu veröffentlichen oder an einen anderen Dienst zu senden. Prüfen Sie Inhalt und Ziel, bevor Sie einen Skill mit Kollegen teilen oder einen von einem unbekannten Autor importieren.
Eine kleine Vorlage ist leichter zu prüfen als ein riesiger Prompt
Das folgende Beispiel ist eine eigene, bewusst minimale Recherchevorlage. Sie ist Inhalt zur Anpassung in einem lokalen Editor und kein auszuführender Shell-Befehl. Sie behauptet nicht, dass Google genau diese Überschriften verlangt, und sollte vor dem Import mit der aktuellen Plattformanleitung abgeglichen werden.
---
name: source-linked-research
description: Einen Recherchebrief verfassen, der Belege von Interpretationen trennt.
---
# Eingaben
- Forschungsfrage und Zielgruppe.
- Stichtag sowie zugelassene Quellen oder Suchumfang.
# Methode
- Bei faktischen Produktbehauptungen Primärquellen bevorzugen.
- Ankündigungen, Messungen und persönliche Analysen getrennt kennzeichnen.
- Fehlende Belege markieren, statt Fakten oder Zitate zu erfinden.
# Ausgabe
- Haupterkenntnis, unterstützende Links und offene Fragen.
- Keine externe Übermittlung oder Veröffentlichung ohne gesonderte Freigabe.
Der Wert liegt nicht im konkreten Wortlaut, sondern in der sichtbaren Vereinbarung. Leser können die Eingabe erkennen, die Regel für fehlende Belege prüfen und sehen, dass eine Veröffentlichung eine getrennte Aktion ist. Künftige Bearbeiter können eine Anforderung ändern, ohne eine Seite voller unabhängiger Persona-Anweisungen entwirren zu müssen.
Halten Sie Beispiele klein genug, um einen Fehler offenzulegen. Bei quellenverknüpfter Recherche sollte es einen Fall mit widersprüchlichen Terminen und einen Fall ohne Primärquelle für eine Behauptung geben. Bei der Dokumentenprüfung sollte eine Datei mit einer mehrdeutigen Anforderung enthalten sein. Eine Vorlage, die nur mit einfachen, vollständigen Eingaben funktioniert, belegt wenig über den Alltag.
Betten Sie keine Geheimnisse, Zugangstoken oder uneingeschränkten Werkzeuganweisungen in eine Skill-Datei ein. Eine wiederverwendbare Anweisung sollte die Aufgabe beschreiben und nicht als Speicher für Zugangsdaten dienen. Benötigt eine Aufgabe Zugriff auf private Informationen, gehört dieser Zugriff in die geeigneten Berechtigungs- und Kontrollen der Plattform. Bequemlichkeit sollte sensible Informationen nicht unsichtbar in einer Konfiguration verbergen.
Skills zu kombinieren kann auch Konflikte zusammenführen
Kombinierbarkeit ist attraktiv, weil echte Aufgaben mehrere Dimensionen haben. Ein Bericht braucht vielleicht einen Recherchestandard, einen Hausstil und eine zielgruppengerechte Erklärung. Doch Anweisungen können sich widersprechen: Eine verlangt eine kurze Antwort, eine andere eine umfassende Prüfung; eine fordert entschiedene Empfehlungen, eine andere, ungelöste Unsicherheit deutlich zu benennen. Ein nützlicher Arbeitsablauf erkennt den Konflikt, statt einen willkürlichen Kompromiss zu erzeugen.
Beginnen Sie mit zwei ergänzenden Skills, bevor Sie viele hinzufügen. Prüfen Sie, ob der Belegstandard die Stilvorgabe übersteht und ob die Ausgabe für die Zielgruppe geeignet bleibt. Ändert sich das Ergebnis unerwartet, testen Sie jeden Skill einzeln. Andernfalls wird ein Fehler schwer zuzuordnen, und Nutzer reagieren womöglich darauf, indem sie noch mehr Anweisungen auf einen wachsenden Stapel legen.
Eine ausdrückliche Aktivierung kann während der Evaluierung nützlich sein. Automatische Relevanzauswahl ist praktisch, wenn sie funktioniert, kann aber weniger sichtbar machen, welche Anweisungen angewandt wurden. Halten Sie bei einer folgenreichen Aufgabe fest, welchen Skill Sie verwenden wollten, und prüfen Sie, ob das Ergebnis ihm folgt. Das ist eine Prüfeempfehlung und keine Behauptung, eine bestimmte Oberfläche biete einen vollständigen Anweisungsverlauf.
Halten Sie den Umfang eng genug, damit ein Skill nicht auf unpassende Arbeit angewandt wird. Eine Regel für „Finanzrecherche“ sollte kein kreatives Gespräch stillschweigend umformen. Eine Kundendienstvorlage sollte eine persönliche Frage nicht in ein formelles Ticket verwandeln. Gute Personalisierung schließt ein zu erkennen, wann die Anpassung irrelevant ist.
Vergleichen Sie Aufgaben, bevor Sie den alten Ablauf aufgeben
Eine praktische Migrationsprüfung verwendet dieselben wenigen Eingaben vor und nach der Änderung. Nehmen Sie einen gewöhnlichen Fall, eine unvollständige Eingabe und einen Grenzfall auf, der früher korrigiert werden musste. Vergleichen Sie den Inhalt und nicht nur die Formatierung. Wurden notwendige Einschränkungen bewahrt? Wurden fehlende Details erfunden? Blieb die Grenze für externe Aktionen erhalten?
Prüfen Sie bei einem Rechercheablauf jeden wichtigen Link in einer Beispielausgabe. Bei einem redaktionellen Ablauf kontrollieren Sie, ob die beabsichtigte Bedeutung die Überarbeitung übersteht. Bei einer internen Übergabe bestätigen Sie, dass Zuständigkeiten und offene Fragen nicht zu abgeschlossenen Aufgaben werden. Diese Prüfungen sollten zur Aufgabe passen, statt sich auf einen einzigen allgemeinen „Qualitätswert“ zu verlassen.
Notieren Sie Datum, Kontotyp und Konfigurationsversion des Vergleichs. Das erleichtert spätere Untersuchungen. Verschlechtert sich ein Ergebnis nach einem Update, können Sie fragen, ob sich die Anweisung, das Quellenmaterial oder die Plattform geändert hat. Ohne einen Referenzpunkt beginnt jede Untersuchung mit einer unsicheren Erinnerung daran, wie die Dinge früher funktionierten.
Für den persönlichen Gebrauch braucht es dafür kein großes Evaluierungssystem. Eine kurze Checkliste und einige gespeicherte Beispiele reichen womöglich, um offensichtliche Regressionen zu entdecken. Teams mit folgenreichen Arbeitsabläufen benötigen möglicherweise eine formellere Prüfung, doch das Prinzip bleibt dasselbe: Eine Migration ist abgeschlossen, wenn das beabsichtigte Verhalten überprüft wurde, nicht bloß, wenn eine Datei importiert ist.
Personalisierung braucht Verantwortung ebenso wie Komfort
Der Übergang weist auf eine umfassendere Zukunft hin, in der Nutzer wiederverwendbare Arbeitsweisen zwischen Aufgaben mitnehmen, statt jedes Mal mit einem leeren Prompt zu beginnen. Das kann wertvoll sein. Es kann auch eine neue Art angesammelter Software schaffen: Anweisungssätze und Referenzsammlungen, die wichtige Entscheidungen beeinflussen, obwohl sie nicht wie herkömmliche Anwendungen aussehen.
Jemand muss für diese Sammlung verantwortlich sein. Wer aktualisiert die Referenzdateien? Wer prüft einen gemeinsam genutzten Skill nach einer Richtlinienänderung? Wer entscheidet, ob eine importierte Anweisung angemessen ist? Diese Fragen lassen sich leicht vertagen, solange Anpassung wie beiläufiges Prompting wirkt. Sie werden schwerer zu ignorieren, wenn dieselbe Konfiguration täglich im Team wiederverwendet wird.
Für Einzelpersonen kann die Verantwortung überschaubar sein: lesbare Kopien aufbewahren, veraltete Annahmen entfernen und folgenreiche Ergebnisse überprüfen. Für Organisationen kann sie genehmigte Konfigurationen, Zugriffsregeln und einen Prüfprozess erfordern. Keine der Lösungen sollte Personalisierung als Korrektheitsgarantie behandeln. Auch ein vertrauter Assistent kann einen unbekannten Fehler machen.
Überführen Sie den Arbeitsablauf, nicht nur den Namen
Die nützlichste Vorbereitung besteht darin, die Aufgabe Ihres Gems zu bewahren und ihre Anforderungen ausdrücklich zu machen. Heben Sie eine Referenzkopie auf, identifizieren Sie die benötigten Dateien, trennen Sie stabile Regeln von vorübergehenden Fakten und testen Sie den Kandidaten mit repräsentativen Eingaben. Richten Sie sich anschließend nach den Rollout-Informationen für Ihr tatsächliches Konto, statt eine globale Frist anzunehmen.
Skills können Anpassungen wiederverwendbarer und kombinierbarer machen. Der Nutzen entsteht aus klaren Vereinbarungen und sorgfältiger Prüfung, nicht allein aus dem Wort „Skill“. Je persönlicher KI-Werkzeuge werden, desto wertvoller ist eine Konfiguration, die Sie verstehen, pflegen und überprüfen können. Dieses Verständnis zu übertragen ist wichtiger, als einen Prompt in einen neuen Bildschirm zu kopieren.
Migrationsentscheidungen an einem Ort festhalten
Für Leser, die Recherche, Konfigurationsnotizen und Prüfentscheidungen organisieren, ist Telli.sh ein optionaler Arbeitsbereich. Eine Prüfnotiz erstellen.