Ein Launch-Lauf von Anfang bis Ende

Das Runbook des Toolkits beschreibt einen Launch als wiederholbare Schleife statt als einmaliges Ereignis: ein wahrheitsgetreues Briefing bauen, einen kleinen Batch wählen, eine Plattform nach der anderen bearbeiten, das Beobachtete erfassen, beim nächsten Mal fortsetzen, ohne etwas zu wiederholen. Diese Anleitung folgt einem Lauf durch diese Schleife. Sie setzt voraus, dass die Setup-Anleitungen erledigt sind – der Workspace existiert, der Browser ist verbunden, und das Onboarding hat deine Berechtigungen festgehalten. Der gesamte Ablauf, Produkt → Agent → Verzeichnisse → Tracker, ist auf der Seite So funktioniert es gezeichnet.

1. Mit einem wahrheitsgetreuen Briefing beginnen

Jeder Lauf beginnt in product.json und copy.md: Name, kanonische URL, Zielgruppe, verifizierte Funktionen, eine Preisübersicht und ein Prüfdatum. Das Runbook ist streng bei den kleinen Lügen, die sich einschleichen: Eine Testphase mit Guthabenlimit ist eine Testphase, auch wenn der Einstieg kostenlos ist; ein Pflichtfakt, den du nicht kennst, wird als unbekannt erfasst, nicht geraten; Screenshots zeigen die echte Oberfläche, sind aus Originalen skaliert und auf Qualität geprüft; Kundenzahlen oder Testimonials anderer werden nicht wiederverwendet. Bereite aus diesen Fakten ein quadratisches Logo sowie eine kurze und eine lange Beschreibung vor. Der Agent leitet Fähigkeiten nie von einem Wettbewerber ab.

2. Drei bis fünf Plattformen wählen

Der Playbook-Index lässt den Agenten nach Zielgruppe und Voraussetzung wählen. Beginne mit drei bis fünf, nicht mit fünfzig. Bedingte Playbooks – ein KI-Verzeichnis, das eine echte KI-Fähigkeit verlangt, ein Firmenverzeichnis, das vom Owner freigegebene Unternehmensfakten will – sind nützliche mitgelieferte Orientierung, kein Versprechen, dass jedes Produkt einen kostenlosen Platz bekommt. Für jede gewählte Plattform liest der Agent das vollständige Playbook, bevor er navigiert, prüft die bestehende Tracker-Zeile, durchsucht das Verzeichnis nach Produktname und Domain und sieht sich das angemeldete Konto an. Ein bestehender Eintrag, der dir gehört, wird beansprucht oder bearbeitet, nicht dupliziert; ein unklarer früherer Versuch wird geklärt, bevor ein neuer beginnt. Der Artikel zum Launch ohne Budget zeigt, wie so ein Batch auf echten Plattformen aussah.

3. Eine Plattform nach der anderen

Die sechs Schritte des Runbooks für jede Plattform:

1. Aktuelles Formular, Preise, Eignung, Kontolimit und nötige Einwilligung erneut prüfen.
2. Nur verifizierte Texte und echte Assets vorbereiten; jedes importierte Feld validieren.
3. Gespeicherte Felder erneut öffnen oder den Entwurf in der Vorschau ansehen, um zu bestätigen, dass er erhalten blieb.
4. Endsumme und optionale Extras prüfen. Nach der Standardrichtlinie bei jeder verlangten Zahlung anhalten. Ist ein Badge Pflicht, die erfasste Website-Freigabe prüfen, das offizielle Markup verwenden und die deployte öffentliche Seite verifizieren, bevor es bestätigt wird.
5. Im Rahmen der Freigabe des Owners einreichen; das resultierende Dashboard und Moderationsetikett ansehen; eine nicht-sensible Zusammenfassung behalten.
6. Ergebnis und nächste Aktion sofort erfassen, dann weiter.

„Sofort“ leistet in Schritt 6 viel Arbeit. Das Toolkit betrachtet eine Verzeichniseinreichung als unfertig, bis ihr Ergebnis im Tracker steht, denn ein Agent, der zehn Ergebnisse am Ende einer Sitzung erfasst, wird sich an mindestens eines falsch erinnern.

4. Status aus Belegen wählen

Der Status kommt aus dem, was beobachtet wurde, nicht aus dem, was versucht wurde. Ein Danke-Bildschirm ist nicht live. Eine erreichbare Seite mit dem Etikett Pending approval ist submitted_pending_review. Ein bestätigter Slot mit ausstehender Freigabe ist scheduled, mit dem Vorbehalt in der Notiz und einem --launch-date am oder nach der Untergrenze. Eine verlangte Zahlung ist deferred_paid, und nichts wird gekauft. Die vollständige Tabelle, der Befehl und die Notizregeln stehen in der Anleitung zum Erfassen von Ergebnissen.

5. Fortsetzen, nicht wiederholen

Die nächste Sitzung beginnt mit dem Lesen des Trackers. Übergaben an Menschen und geplante Launches, deren Verifizierung fällig ist, kommen zuerst, dann ausstehende Einreichungen, deren Prüffenster abgelaufen ist. Kein Plattform-SLA wird erfunden; nennt ein Verzeichnis keine Zeitangabe, wird ein Nachfassdatum mit dir vereinbart. Erneut einzureichen, um in der Warteschlange vorzurücken, ist verboten – stattdessen wird der bestehende Eintrag erneut geprüft. Echte Projekte und Browser-Belege bleiben privat; bei mehreren Agenten bekommt jeder ein eigenes Browser-Profil und eine eigene Plattformzuweisung, und der Tracker koordiniert nur die lokalen Schreibvorgänge.

Wie ein realistischer erster Lauf aussieht

Drei bis fünf Plattformen, eine Agentensitzung und ein Tracker, in dem ungefähr steht: einmal submitted_pending_review, einmal scheduled mit ausstehender Freigabe, einmal prepared_needs_human, das darauf wartet, dass du ein CAPTCHA löst, einmal deferred_paid. Womöglich null live am ersten Tag – die kostenlosen Wege veröffentlichen nach dem Zeitplan des Verzeichnisses, Wochen später, und genau deshalb gibt es die Untergrenze. Das ist kein gescheiterter Lauf; so sieht die Warteschlange von innen aus. Eine erzählte Version mit einem konkreten Agenten findest du in der Claude-Code-Anleitung oder auf der Codex-Seite.