LaunchRepoSobald der Workspace existiert und das Dashboard läuft, leitet der Agent die erste echte Sitzung. ONBOARDING.md weist ihn an, deine Sprache zu sprechen, eine Phase nach der anderen abzuarbeiten, Dateien aus deinen Antworten und verifizierten Quellen zu füllen und nie zweimal zu fragen, was er aus einer vorhandenen Datei lesen könnte. Bricht eine Sitzung ab, lassen onboarding.json und SESSION.md den nächsten Agenten bei der ersten unvollständigen Phase weitermachen. Hier ist, was jede Phase tut – und was der Agent ausdrücklich nicht tun darf.
Phasen 1–2: Orientierung und ein privates Zuhause
Der Agent erklärt zuerst den Plan: das Produkt verstehen, Browser und Verifizierungs-Postfach verbinden, vereinbaren, wie er Einträge und Website-Badges veröffentlichen darf, und das Setup für künftige Sitzungen bewahren. Er fragt nach Name, URL und lokalem Code-Ordner des ersten Produkts und liest diese, bevor er irgendetwas anderes fragt. Außerdem prüft er, was er in dieser Sitzung tatsächlich kann – ein Terminal allein ist keine Browser-Steuerung, und das Toolkit verbietet, Werkzeuge zu behaupten, die die Sitzung nicht aufrufen kann.
Phase 2 gibt deinen Daten ein privates Zuhause. Steckt der Agent noch im gekauften Auslieferungs-Repository, initialisiert er den unabhängigen Workspace, den der Start in drei Schritten anlegt, und hilft dir, ein eigenes privates Remote einzurichten. Er sagt klar, dass gespeicherte Zugangsdaten – falls du der Speicherung zustimmst – in diesem privaten Repository liegen, lesbar für jeden mit Zugriff, auch auf dessen Historie, und nie im Auslieferungs-Repository. Owner, Repository, Sichtbarkeitsprüfung und Entscheidung zu den Zugangsdaten landen in workspace.json; mit einem Secret-Manager werden nur Referenzen gespeichert.
Phase 3: das Produkt-Briefing und dein Launch-Datum
Der Agent führt scripts/new-product.py mit einem kurzen Slug in Kleinbuchstaben aus und füllt product.json – die Produkt-Kontextdatei, die jedes Playbook liest – aus deinen Antworten: Zielgruppe, Problem, Unterscheidungsmerkmal, echte Funktionen, Preise oder Testphase, Launch-Stadium, echte Screenshots und Logo. Den resultierenden Text bekommst du zur Korrektur gezeigt. Zwei Regeln schützen dich vor peinlichen Einträgen: Fähigkeiten werden nie von einem Wettbewerber abgeleitet, und geplante Funktionen werden nie als verfügbar beschrieben. Unbekanntes bleibt leer.
Diese Phase fragt auch, wann die ersten Launches live gehen sollen und ob es ein Datum gibt, vor dem nichts veröffentlicht werden darf – mit der klaren Warnung, dass kostenlose Verzeichnisse Einreichungen zur Prüfung in die Warteschlange stellen und die Veröffentlichung Wochen dauern kann, nicht Tage. Deine Antwort wird zu earliest_launch_date in product.json, dem frühesten Launch-Datum, das record.py später durchsetzt.
identity.json hält dann öffentlichen Namen, Kontakt-E-Mail, Nickname und die Organisationsfakten fest, die du freigibst, und trennt deine private Konto-E-Mail von der öffentlichen Kontaktadresse. Bevor davon etwas in einen Eintrag gelangt, führt der Agent das kurze Briefing zur Außendarstellung durch.
Phase 4: Chrome und das Postfach
Nach der Anleitung zur Chrome-Verbindung führt dich der Agent durch die Remote-Debugging-Seite von Chrome und etwaige macOS-Berechtigungen und macht dann einen sichtbaren Smoke-Check auf einer öffentlichen Seite. In dein Web-Postfach meldest du dich im verbundenen Browser selbst an; der Agent bestätigt, dass es das vorgesehene Konto ist, ohne Nachrichten zu kopieren. Verifizierungs-E-Mails schließen Registrierungen und Einträge ab, deshalb wird der Umfang des Postfachzugriffs in authorizations.json festgehalten. Codes von Hand weiterzugeben ist ein unterstützter Ausweg, erfasst als Übergabe an einen Menschen, nicht als automatisierter Zugriff.
Phase 5: Berechtigungen, einmal pro Produkt vereinbart
Der Agent fragt, wo der Code der Produkt-Website liegt, wie sie deployt wird, welcher Branch Produktion ist und wie die kanonische URL lautet. Dann die Frage, die später am meisten Reibung spart: Darf er ein offizielles Verzeichnis-Badge in den Footer dieses Produkts einbauen, committen, pushen und neu deployen? Umfang, Antwort, Datum sowie erlaubtes Repository und Branch kommen in authorizations.json. Ein „Nein“ blockiert keine Verzeichnisse, die kein Badge verlangen. Dieselbe Datei hält fest, ob kostenlose Registrierungen, kostenlose finale Einreichungen und bestimmte Aktionen mit Verifizierungs-E-Mails erlaubt sind. Ausgaben bleiben bei null, und eine Freigabe für ein Produkt gilt nie für ein anderes.
Phasen 6–7: ein echtes Ergebnis, dann ein fortsetzbarer Workspace
Ist das Setup fertig, führt der Agent doctor.py aus und trennt fehlendes Setup von Berechtigungen, die du bewusst verweigert hast. Er wählt drei bis fünf passende Playbooks, erklärt die Eignung und beginnt mit einem zugänglichen kostenlosen Weg: nach einem bestehenden Eintrag suchen, das Ziel verifizieren, korrekte Texte vorbereiten, bestätigen, dass nichts berechnet wird, im Rahmen der Freigabe einreichen, das echte Ergebnis erfassen. Ein gutes erstes Ergebnis ist oft eine eingereichte Prüfung statt einer Live-Seite – siehe die Anleitung zum Erfassen von Ergebnissen.
Zum Abschluss aktualisiert der Agent onboarding.json nur mit Prüfungen, die er tatsächlich beobachtet hat, schreibt nicht-sensible Belege und offene Schritte nach SESSION.md, trägt Nachfassdaten in FOLLOW-UP.md ein und fasst zusammen, was erledigt, ausstehend, von dir abhängig und als Nächstes dran ist. Vor jedem Push läuft eine Git-Privatsphäre-Prüfung. Der Test für eine gute erste Sitzung: Der nächste Agent kann weitermachen, ohne etwas erneut zu registrieren oder zweimal nach dauerhaften Berechtigungen zu fragen. Die Seite So funktioniert es zeigt, wo das im Gesamtablauf liegt.