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.

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.

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 7, 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, für 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

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, und wo der Build ausgelöst wird
• Cloudflare — das Pages-Projekt, Preview- gegen Production-Deployment, Build-Logs, und 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 Ablauf, den die beiden jedes Mal gleich abarbeiten können — damit der Einstieg 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.

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. Daraus wird eine prüfbare Anforderung: vertikal statt horizontal geschnitten, so klein wie möglich, aber sichtbar. Statt eines vorgegebenen Übungsfeatures gibt es einen Kriterienfilter für die eigene Idee — sichtbar, Frontend-only, klein, prüfbar, und etwas, das sie selbst stört.

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: Arbeitsverzeichnis → Staging → lokales Repo → Remote. Kernsatz: nach dem Commit ist die Arbeit immer noch nur auf dem eigenen Rechner
• Branch als Zeiger, nicht als kopierter Ordner — räumt die häufigste Fehlvorstellung ab
• Neun Befehle, getrennt in Schauen und Tun — die Schau-Befehle bleiben in eigener Hand, den Rest darf der Agent übernehmen
• Pannenhilfe für vier Standardsituationen: falscher Branch, vergessener Pull, Merge-Konflikt, ungefragter Commit

Übung dazu: in .claude/settings.json ein deny auf Push nach main und ein ask auf Commit und Push. Offen benannt: das ist ein Schutz gegen Versehen, keine Sicherheitsgrenze.

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, 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: eine Korrektur im Plan kostet zwei Minuten, dieselbe Korrektur nach der Umsetzung eine halbe Stunde. Der Aha-Moment ist die Preview-URL — sie entsteht bereits durch den Push, nicht erst durch den PR.

Spielregeln

Feature-Branch → PR nach develop → Preview des Branches. Der Merge nach develop passiert durch Engineering, main ist tabu. Bewusst ausgeklammert: Git Worktrees, TDD-Vertiefung, Merge nach main.

Material & Stand

32 Slides und drei Anhänge — Rezept-Karte, Befehlsübersicht, Pannenhilfe. Gebaut und gehalten.

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 4

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

Das Modell ist der Motor. Die API ist derselbe Motor, nur mit Anschlüssen, an die man etwas anbauen kann. Die Gemini- oder ChatGPT-App ist das fertige Auto — mit Navi, Assistenzsystemen und Werkstattnetz. Und der Agent, also unser n8n-Workflow, ist das selbstfahrende Auto, das 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.