GEO Agent Training — Modulübersicht

Ziel

Die beiden können nach dem Modul erklären, was beim Klick auf «Audit starten» im GEO Agent tatsächlich passiert — und welches der vier Systeme dabei welche Aufgabe übernimmt.

Roter Faden

Architektur ist keine Naturkonstante, sondern eine Entscheidung mit Vor- und Nachteilen.

Analogien

Teppanyaki-Restaurant

Client vs. Server — der Koch arbeitet vor deinen Augen, trotzdem sind Küche und Gast getrennte Rollen

Restaurant

CSR vs. SSR — fertiger Teller aus der Küche oder Zutaten zum Selbstzusammenbauen am Tisch

Interaktion & Übungen

• Einstiegsfrage als Vorher/Nachher-Check: «Wie stellt ihr euch vor, dass die App technisch funktioniert?» — am Modulende nochmal gestellt
• Auflösungsfrage zur klassischen Verwechslung: Frontend/Backend ist nicht dasselbe wie Client/Server
• Frage «Was passiert, wenn du die App öffnest?» mit anschliessender Auflösung
• Drei interaktive HTML-Demos zum Selberklicken statt Frontalvortrag

Artefakte

• PPTX mit 24 Slides, Speaker Notes auf jedem Slide
• Demo 1: Request/Response-Flow · Demo 2: Button-Klick Schritt für Schritt · Demo 3: vollständige Architektur, inaktive Knoten werden abgedunkelt
• Zwei Einzelslides: die vier Applikationsschichten, CSR vs. SSR

Prework für das Folgemodul

Video zur Web-Developer-Roadmap.

Ziel

Fachbegriffe aus dem Engineering-Alltag einordnen können, die DevTools selbst öffnen und lesen, und wissen, wo im Stack welche Geheimnisse liegen.

Aufbau-Entscheidung

Block 6 (GitHub & Build Flow) steht bewusst nach der Frontend-Architektur. Das erzeugt die Brücke: erst sehen, wie komplex eine App wird — dann verstehen, warum es Git überhaupt gibt.

Analogien

Stromnetz

Internet vs. Web — das Netz ist nicht dasselbe wie die Geräte, die daran hängen

Hausbau

HTML = Rohbau, CSS = Innenausbau, JavaScript = Haustechnik

Restaurant

API — die Speisekarte sagt, was du bestellen darfst, nicht wie gekocht wird

Zugabfahrtstafel

Komponenten & State — die Tafel zeigt immer den aktuellen Zustand, ohne dass jemand sie neu baut

Festival

Secrets & Tokens — Bändeli am Handgelenk, Backstage-Pass, Gültigkeitsdauer

Hands-on

• Eigene HTML-Seite bauen — Rohbau selbst anfassen statt nur ansehen
• DevTools Netzwerk-Tab: einen echten Request des GEO Agents mitlesen
• Secrets-Landkarte: gemeinsam eintragen, welches Geheimnis in GitHub, Cloudflare, Supabase und n8n liegt

Abschluss

• Quiz mit 7 Fragen, Musterantworten in den Speaker Notes hinterlegt
• Glossar zweispaltig
• Prework für Modul 3: Fireship-«100 Seconds»-Videos zu Supabase, n8n und Cloudflare plus zwei Hands-on-Aufgaben

Stand

Alle 43 Slides sind gebaut, alle sieben Blöcke sind gehalten.

Ziel

Am Ende läuft bei beiden der eigene Dev-Server, und sie wissen, welches Claude-Werkzeug für welche Aufgabe gedacht ist.

Roter Faden

Es ist überall dasselbe Modell. Was sich unterscheidet, ist wie viel Kontext es bekommt und was es anfassen darf.

Dieser Satz trägt das ganze Modul — und ist gleichzeitig die Vorlage für Modul 4, wo aus «Kontext und Zugriff» die Unterscheidung Modell / API / Produkt / Agent wird.

Setup-Verifikation

Jeder hakt die Checkliste selbst ab, jeder Punkt braucht einen sichtbaren Beweis: Repo geklont und auf develop, npm run dev läuft im Browser, Supabase-Dev-Login funktioniert, Claude Code antwortet im Repo auf «was macht dieses Projekt?», n8n MCP liefert die Workflow-Liste (nur lesend), Testbranch lässt sich pushen.

Der Setup-Teil ist erfahrungsgemäss der fragilste — Buddy-Prinzip eingeplant: wer fertig ist, hilft dem anderen.

Die Claude-Landschaft

Claude Chat

Gespräch, Kontext nur im Chat — Denken, Texte, Erklärungen

Projects

Chat plus eigene Wissensbasis und Memory — wiederkehrende Arbeit mit gleichem Kontext

Artifacts

Erzeugt eigenständige Dateien und kleine Apps im Chat — Prototypen, Visualisierungen

Claude Code

Arbeitet direkt im Repo, liest und schreibt Dateien, führt Befehle aus

Cowork

Agentisch wie Code, aber für Nicht-Code-Arbeit — nur theoretisch behandelt

Connectors / MCP

Anbindung an externe Systeme wie n8n, Supabase, Google Drive

Übungen

• Dasselbe Prompt einmal im leeren Chat, einmal im GEO-Agent-Project — den Unterschied im Output selbst sehen
• Claude Code risikofrei, nur lesend: «Erklär mir, was in dieser Komponente passiert», «Wo im Repo wird der Audit gestartet?»
• Snippet-Preview-Artifact bauen
• Präsentation erstellen über /superpowers:brainstorming

Werkzeugkasten

Zehn benannte SEO-Skills statt einer abstrakten Aufzählung: SEO-Audit, Technical SEO, On-Page, Keyword-Clustering, Content-Strategie, Content-Brief, AI-Visibility/GEO, Schema-Markup, Internal Linking, Broken Links.

Vergleich Claude / ChatGPT / Gemini

Als Tabelle über sechs Kriterien. Die Stärken der anderen Werkzeuge werden offen benannt — kein Werbeslide.

Bewusst ausgeklammert

• Git-Konzepte — die gehören nach Modul 2, Block 6
• Terminal-Befehle auf Slides — stattdessen Verweis auf diagnose-und-plugins.md
• Cowork praktisch — nur erklärt, nicht geübt

Abschluss

Die drei Regeln für gutes Prompten, die Kernregel «Output reviewen statt blind übernehmen», eine Danger-Zone-Karte und ein Cheat-Sheet zum Mitnehmen.

Ziel

Ein Ablauf, den die beiden jedes Mal gleich abarbeiten können — damit der Einstieg ins Feature-Bauen nicht an der Frage «womit fange ich an?» scheitert. Am Ende des Tages hat jeder eine eigene Änderung auf einer Adresse, die man verschicken kann.

Roter Faden

Zuerst: Was baue ich? Dann: Wie baue ich es?

Der Text, den sie im ersten Block schreiben, geht anschliessend unverändert in den Brainstorming-Dialog mit dem Agent. Keine Trockenübung, sondern eine durchgehende Kette.

Block 1 — Was baue ich?

Ausgangspunkt ist ein Wunsch, wie er real ankommt: «die Ergebnisseite ist unübersichtlich». Der Satz beschreibt ein Gefühl, kein Ergebnis — und ist damit kein Auftrag.

• Was heisst «fertig»? Ein Satz, den zwei Personen unabhängig voneinander abhaken könnten
• Vertikal statt horizontal schneiden — ein schmaler Durchstich durch alle Schichten statt «erst die ganze Datenbank»
• Die kleinste sichtbare Änderung: nicht die einfachste, sondern die kleinste, die jemand bemerkt
• Wo die eigene Grenze verläuft — Text, Darstellung und Zustände gehen allein; Datenmodell, n8n, Edge Function und Auth nicht

Statt eines vorgegebenen Übungsfeatures gibt es einen Kriterienfilter, den sie auf ihre eigene Idee anlegen: sichtbar, Frontend-only, klein, prüfbar, und etwas, das sie selbst stört. Fallback-Ideen liegen in den Speaker Notes.

Git in der Praxis

Modul 2, Block 6 liefert das Warum. Hier kommt das Wie — was passiert, wenn man selbst oder der Agent auf die Tasten drückt.

• Vier Zustände, nicht drei: Arbeitsverzeichnis → Staging → lokales Repo → Remote. Kernsatz: nach dem Commit ist die Arbeit immer noch nur auf dem eigenen Rechner
• Remote ist das Repo auf GitHub, origin nur sein Spitzname. Der lokale Ordner ist eine vollständige Kopie, kein Fenster auf den Server
• Branch als Zeiger, nicht als kopierter Ordner — räumt die häufigste Fehlvorstellung ab
• Pull an genau einer Stelle: auf develop, bevor der Feature-Branch entsteht
• Der Agent committet für dich — deshalb git status, git diff und git branch --show-current vor jedem Push selbst lesen können
• Neun Befehle, getrennt in Schauen (ungefährlich, jederzeit) und Tun (verändert etwas) — die Schau-Befehle bleiben in eigener Hand, den Rest darf der Agent übernehmen
• Pannenhilfe für vier Situationen: falscher Branch, vergessener Pull, Merge-Konflikt, ungefragter Commit

Übung: Leitplanken einrichten

Jeder im eigenen Repo: in .claude/settings.json ein deny auf Push nach main und ein ask auf Commit und Push. Danach ausprobieren — den Agent bitten zu pushen und sehen, dass er es nicht kann.

Offen benannt: das ist ein Schutz gegen Versehen, keine Sicherheitsgrenze. Der echte Riegel wäre eine Regel auf GitHub selbst.

Das Feature-Rezept — acht Schritte

1. Startpunkt sauber machen — develop pullen, Feature-Branch anlegen, prüfen statt glauben
2. Kontext geben — betroffene Dateien, CLAUDE.md, Dev-Server
3. /superpowers:brainstorming mit dem Text aus dem ersten Block
4. Plan schreiben lassen, lesen, freigeben
5. Lokal entwickeln — Browser, DevTools Console und Netzwerk-Tab, Testsuite
6. Stagen, committen, pushen
7. Preview-URL des Branches prüfen
8. Pull Request nach develop

Schritt 1, 4 und 7 bekommen mehr Gewicht als die übrigen. 1 und 4 sind die Stellen, an denen es real schiefgeht — eine Korrektur im Plan kostet zwei Minuten, dieselbe Korrektur nach der Umsetzung eine halbe Stunde.

Der Aha-Moment

Die Preview-URL. Sie entsteht bereits durch den Push, nicht erst durch den PR. Die eigene Änderung auf einer echten Adresse zu sehen und sie jemandem schicken zu können, ist der Punkt, an dem der Workflow von abstrakt zu greifbar kippt.

Spielregeln

• Feature-Branch → PR nach develop → Preview des Branches
• Der Merge nach develop passiert durch Engineering, nicht durch sie
• main ist tabu

Bewusst ausgeklammert

• Git Worktrees — Superpowers schlägt sie nach der Design-Freigabe vor, wir lehnen ab und bleiben beim normalen Feature-Branch
• TDD-Vertiefung — die Testsuite im Repo wird genutzt, aber nicht erklärt
• Merge nach main

Material

• Rezept-Karte: acht Schritte, pro Schritt die eine Frage, die man sich stellt
• Befehlsübersicht: Schauen und Tun getrennt, plus Standardablauf
• Pannenhilfe: sechs Situationen mit Rezept

Stand

32 Slides und drei Anhänge, gebaut und gehalten.

Ziel

Sich auf allen Plattformen selbst zurechtfinden — und im Fehlerfall wissen, wo man nachschaut, statt zu fragen.

Der rote Faden

Ein einzelner Audit-Request wird von Hand durch alle Plattformen verfolgt: vom Klick in der App über den Build, der die App überhaupt dorthin gebracht hat, bis zum Ergebnis in der Datenbank. Kein Plattform-Rundgang nebeneinander, sondern eine Spur durch alle.

Was pro Plattform drankommt

GitHub

Repo-Struktur von audit-interface, Commits und Branches lesen, Pull Requests, wo der Build ausgelöst wird

Cloudflare

Das Pages-Projekt, Preview- gegen Production-Deployment, Build-Logs, was nach dem Merge passiert

Supabase

Tabellen und RLS, Auth-Nutzer, die Edge Function und ihre Logs, Realtime-Kanäle, Storage

Herkunft

Ursprünglich als Block in Modul 3 geplant und dort aus Platzgründen gestrichen. Danach als eigenes Modul geführt und gehalten.

Verhältnis zu Modul 6

n8n war hier bewusst nur eine Station auf dem roten Faden. Die Vertiefung folgt in Modul 6.

Ziel

Ein konkretes Audit-Ergebnis selbständig bis zu dem Node oder Prompt zurückverfolgen können, der dafür verantwortlich war. Damit werden aus «das Ergebnis ist schlecht» konkrete, adressierbare Rückmeldungen ans Engineering.

Inhalt

• Aufbau des Audit-Workflows — welcher Node macht was, und in welcher Reihenfolge
• Nodes und ihre Verbindungen, inklusive der DataForSEO-Anbindung
• Das Executions-Log lesen: wo steht der Input, wo der Output, wo der Fehler

Hands-on Log-Tracing

Jeder bekommt ein reales Audit-Ergebnis und sucht im Executions-Log die Stelle, an der es entstanden ist. Kein Nachbauen, kein Ändern — nur Lesen und Finden.

Regeln auf der geteilten Instanz

• Ohne ausdrückliche Freigabe nur lesende Operationen
• Der n8n-API-Key wird persönlich verteilt und landet niemals in Git

Verhältnis zu Modul 5

n8n bekommt hier die Tiefe. Im Plattform-Deep-Dive tauchte es nur als eine Station auf dem roten Faden auf.

Anlass

Aus dem Team kam die Frage, warum die Gemini-Web-App bessere Ergebnisse liefert als der eigene n8n-Workflow — und warum man nicht einfach per API auf diese App zugreifen kann. Dahinter steckt eine Lücke zwischen Modell, API und fertigem Produkt. Genau die schliesst dieses Modul.

Aufbau in vier Schritten

1 · Was ein LLM wirklich kann — und was nicht. Ein Modell sagt Token vorher. Sonst nichts: kein Internet, kein Gedächtnis, keine Dateien, keine Codeausführung. Alles, was in der Gemini-App sichtbar ist, wurde darum herum gebaut.

2 · Was ein Chat-Produkt tatsächlich ist. Die Gemini-App aufgeschnitten: Modell + versteckter System-Prompt + Search-Grounding + Datei-Parser + Code-Interpreter + Bildgenerierung + Gedächtnis + UI + Sicherheitsfilter. Das ist ein Agent mit Werkzeugen — dasselbe Architekturmuster wie der eigene n8n-Workflow, nur von Google gebaut.

3 · Die Modell-Landschaft. Reasoning- vs. Standardmodelle und was «Thinking» wirklich tut · Modellgrössen und der Dreiklang Qualität, Tempo, Kosten · Kontextfenster und warum «gib ihm einfach alles» keine Lösung ist.

4 · Warum unser Workflow anders aussieht. One-Shot statt Gespräch · erzwungener strukturierter Output, weil die App JSON braucht und keinen schönen Fliesstext · Token- und Kostenlimit · kein Mensch, der nachschärft · muss bei hundert Audits hundertmal dasselbe Format liefern.

Die Auto-Analogie

Motor

Das Modell

Motor mit Anschlüssen

Die API

Fertiges Auto

Die Gemini- oder ChatGPT-App — mit Navi, Assistenzsystemen, Werkstattnetz

Selbstfahrendes Auto

Der Agent — unser n8n-Workflow, der einen Auftrag eigenständig abarbeitet

Wer den Motor kauft, bekommt kein Navi mitgeliefert. Und man kann kein fertiges Auto in ein anderes Auto einbauen.

Ehrliche Nuance

Manches davon gibt es an der API — Grounding-Optionen, Tool-Definitionen. Aber es muss ausdrücklich angefordert und bezahlt werden. Es ist nicht «einfach da». Der Tausch lautet: weniger Komfort, dafür Kontrolle, Reproduzierbarkeit und Integration ins eigene Produkt.

Bewusste Setzungen

• Kein Live-Vergleich der Werkzeuge — auf Wunsch gestrichen
• Die Modell-Landschaft vermittelt ein Bewertungsraster, keine Rangliste. Ranglisten sind in drei Monaten peinlich; konkrete Modellnamen werden vor dem Bau frisch recherchiert.

Abschlussfrage

Nennt zwei Stellen im GEO Agent, an denen ihr ein Chat-Produkt nicht einsetzen könntet — und warum. Erwartbar: kein Trigger, kein garantiertes Format, keine DB-Anbindung, keine Nachvollziehbarkeit, Datenschutz.

Stand

Slidetexte stehen (rund 24 Slides), das PPTX ist noch nicht gebaut.