Einen Gemini-Gem für wiederkehrende Engineering-Reviews nutzen

Nutze Gemini für ein gezieltes Engineering-Review, wenn du den relevanten Entwurf und seine Grenzen bereitstellen kannst. Ein Gem hilft, wenn dieselben Kriterien regelmäßig wiederkehren: API-Kompatibilität, Hintergrundaufträge oder das Entwurfsformat deines Teams.

Erprobe zuerst eine einzelne Aufgabe. Bewährt sich das Verfahren, speichere seine dauerhaften Regeln und Quellen in einem Gem.

Prüfe einen konkreten Entwurf

Dieser erfundene Entwurf enthält eine absichtliche Lücke:

Ein Worker empfängt einen Auftrag, schreibt das Ergebnis und bestätigt die Nachricht.
Die Queue darf Nachrichten mehrfach zustellen.
Jedes Ergebnis löst eine Kundenbenachrichtigung aus.
Der Entwurf erklärt nicht, wie ein wiederholter Auftrag erkannt wird.

Bitte um eine Prüfung:

Prüfe diesen Entwurf auf doppelte Benachrichtigungen. Verwende die angegebene Zustellgarantie und Reihenfolge. Beschreibe einen konkreten Fehlerablauf, schlage eine Erkennung wiederholter Arbeit vor und nenne offene Entscheidungen. Verweise bei jedem Befund auf die Anforderung. Erfinde keine Queue-Garantien.

Ein hilfreicher Befund beschreibt einen Worker, der das Ergebnis schreibt, vor der Bestätigung ausfällt und den Auftrag erneut erhält. Der Entwurf muss klären, wo die Kennung für wiederholte Aufträge gespeichert wird und wie das mit dem Senden der Benachrichtigung zusammenhängt. Das Wort „Idempotenz“ allein beantwortet diese Fragen nicht.

Speichere das Verfahren als Gem

Erstelle in Gemini im Web einen Gem mit Namen, Anweisungen und gepflegten Wissensdateien. Teste ihn in der Vorschau und speichere ausdrücklich; die Vorschau speichert die Konfiguration nicht.

Eine kurze Vorgabe reicht als Ausgangspunkt:

Prüfe Entwicklungsentwürfe gegen die gelieferten Anforderungen. Trenne beobachtete Fakten, Fehlerabläufe und Empfehlungen. Nenne für jeden wichtigen Befund Quelle und erforderliche Entscheidung. Kennzeichne fehlende Belege. Schließe mit ausführbaren Prüfungen für den Autor.

Ergänze echte Review-Kriterien und einen versionierten Architekturbrief. Der wechselnde Entwurf gehört in die aktuelle Aufgabe.

Übergib ein weiterverwendbares Ergebnis

Lass eine Tabelle mit Anforderung, Beleg, Fehlerablauf, Änderungsvorschlag und offener Entscheidung erstellen. Speichere die geprüfte Tabelle beim Entwurf.

Ein Coding-Agent erhält Originalanforderungen und akzeptierte Befunde. Der Review-Bericht zeigt noch nicht, dass der Code repariert ist. Für Repository-Zugriff und Ausführung geht es etwa mit Gemini CLI weiter.

Was schiefgeht

Ein allgemeiner Reviewer kann fehlende Anforderungen erfinden. Ein Gem mit alten Architekturdateien bewertet den falschen Entwurf. Ein Bericht kann auch „Duplikat“ wiederholen, ohne einen Weg zur doppelten Verarbeitung zu zeigen.

Verlange eine nachvollziehbare Abfolge, pflege die Quellen und lasse fehlende Anforderungen beim verantwortlichen Menschen entscheiden.

So prüfst du das Ergebnis

Lass den Gem den Beispielentwurf prüfen. Erwarte den Fehler zwischen Ergebnisschreiben und Bestätigung. Ergänze dann eine ausdrückliche Behandlung wiederholter Aufträge und prüfe, ob das Review auf die Änderung eingeht.

Öffne die genannten Belege. Die spätere Implementierung muss den Fall einer mehrfachen Zustellung mit ihren tatsächlichen Tests prüfen.