LaunchRepoNutze die CLI: Für die besten Ergebnisse verwende immer Claude Code CLI oder Codex CLI statt der Desktop-Apps.
Sobald dein Workspace und das Dashboard bereit sind, folgt dein Agent ONBOARDING.md, füllt Dateien aus verifizierten Quellen und verwendet vorhandene Antworten wieder. onboarding.json und SESSION.md bewahren die nächste Aktion, falls eine Sitzung abbricht.
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. Außerdem fragt er einmal, ob Probleme automatisch als GitHub-Issues an die LaunchRepo-Maintainer gemeldet werden dürfen, ohne Geheimnisse und E-Mail-Adressen; die Antwort wird in workspace.json gespeichert und lässt sich später im Dashboard unter Einstellungen ändern.
Phase 3: das Produkt-Briefing und dein Launch-Datum
Der Agent führt scripts/new-product.py mit einem kurzen Slug in Kleinbuchstaben aus, füllt product.json – die Produkt-Kontextdatei, die jedes Playbook liest – aus deinen Antworten und schreibt die Produkttexte in einem kurzen Text-Workshop nach copy.md: 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, Organisationsfakten und die bevorzugte Anmeldemethode 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. Der Agent nutzt den Postfachzugriff, den du bereits freigegeben hast, und bittet dich nur dann um eine Anmeldung, wenn er das Postfach nicht erreicht; er 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: einen Lauf planen und seinen Fortschritt bewahren
Ist das Setup fertig, führt der Agent doctor.py aus und trennt fehlendes Setup von Berechtigungen, die du bewusst verweigert hast. Öffne den Laufplaner und starte mit 10 neuen bestätigten Einreichungen und einem Browser-Worker. Ein zweiter Worker ist eine fortgeschrittene Option für später, sobald eine getrennte Browser-Steuerung getestet ist; stärkere Hardware allein rechtfertigt ihn nicht. Der Agent wählt passende Playbooks aus den aktuell sofort kostenlos nutzbaren Wegen, erklärt die Eignung, bietet einen kleineren Lauf an, wenn es weniger passende Wege gibt, und übernimmt eine Plattform nach der anderen: 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.
Nutze /goal, wenn dein Agent das unterstützt, mit dem gespeicherten Lauf-Prompt; sonst füge den Prompt als normale Nachricht ein. Das Ziel sorgt dafür, dass der Agent den vereinbarten Lauf weiter abarbeitet, statt nach dem ersten Ergebnis aufzuhören. Eine bestätigte neue Einreichung, die in Prüfung, in der Warteschlange, geplant oder live ist, zählt einmal pro Plattform. Entwürfe, bestehende Einträge, kostenpflichtige Wege und Übergaben an Menschen zählen nicht. Der Agent erfasst jedes Ergebnis, schließt nach dem Sichern der Belege nur das dieser Einreichung zugewiesene Fenster und macht mit passenden Alternativen weiter. Ungespeicherte Formulare und Übergaben an Menschen bleiben erhalten.
Zum Pausieren oder Beenden der Sitzung 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.