LaunchRepoGebruik de CLI: Gebruik voor de beste resultaten altijd Claude Code CLI of Codex CLI in plaats van desktop-apps.
Zodra je werkruimte en dashboard klaarstaan, volgt je agent ONBOARDING.md, vult hij bestanden op basis van geverifieerde bronnen en hergebruikt hij antwoorden die er al zijn. onboarding.json en SESSION.md bewaren de volgende actie als een sessie stopt.
Fasen 1–2: oriëntatie en een eigen plek voor je data
De agent begint met uitleg over het plan: het product begrijpen, de browser en de verificatiemailbox koppelen, afspreken hoe hij vermeldingen en websitebadges mag publiceren, en de setup bewaren voor volgende sessies. Hij vraagt naar de naam, URL en lokale codemap van het eerste product en leest die voordat hij iets anders vraagt. Ook controleert hij wat hij in deze sessie werkelijk kan: een terminal alleen is nog geen browserbesturing, en de toolkit verbiedt om tools te claimen die de sessie niet kan aanroepen.
Fase 2 geeft je data een eigen, privéplek. Werkt de agent nog in de gekochte leveringsrepository, dan initialiseert hij de onafhankelijke werkruimte die de start in drie stappen aanmaakt en helpt hij je een eigen private remote in te richten. Hij zegt duidelijk dat opgeslagen inloggegevens – als je toestemming geeft om ze op te slaan – in die privérepository staan, leesbaar voor iedereen met toegang, ook in de geschiedenis, en nooit in de leveringsrepo. Eigenaar, repository, controle van de zichtbaarheid en de keuze voor het opslaan van inloggegevens gaan naar workspace.json; met een secret manager worden alleen verwijzingen opgeslagen.
Fase 3: de productbrief en je lanceerdatum
De agent draait scripts/new-product.py met een korte slug in kleine letters en vult product.json – het productcontextbestand dat elk playbook leest – met jouw antwoorden: doelgroep, probleem, onderscheidend vermogen, echte functies, prijs of proefperiode, lanceerfase, echte screenshots en logo. De tekst die daaruit voortkomt, krijg je te zien om te corrigeren. Twee regels beschermen je tegen gênante vermeldingen: functionaliteit wordt nooit afgeleid van een concurrent, en geplande functies worden nooit als beschikbaar beschreven. Wat onbekend is, blijft leeg.
In deze fase vraagt de agent ook wanneer de eerste lanceringen live moeten gaan en of er een datum is waarvóór niets gepubliceerd mag worden – met de duidelijke waarschuwing dat directory’s met een gratis route inzendingen in een beoordelingswachtrij zetten en dat publicatie weken kan duren, geen dagen. Je antwoord wordt earliest_launch_date in product.json: de ondergrens voor de lanceerdatum die record.py later afdwingt.
Daarna legt identity.json de openbare naam, het contactadres, de bijnaam en de organisatiegegevens vast die jij toestaat, waarbij het privé-e-mailadres van je accounts gescheiden blijft van het openbare contactadres. Voordat daarvan iets in een vermelding terechtkomt, doet de agent de korte presentatiebriefing.
Fase 4: Chrome en de mailbox
Aan de hand van de gids voor de Chrome-verbinding loodst de agent je door de remote-debuggingpagina van Chrome en eventuele macOS-rechten, en voert hij daarna een zichtbare smoketest uit op een openbare pagina. In de gekoppelde browser log je zelf in op je webmail; de agent controleert of het het juiste account is, zonder berichten te kopiëren. Verificatiemails ronden registraties en vermeldingen af, dus de reikwijdte van de mailboxtoegang wordt vastgelegd in authorizations.json. Codes met de hand doorgeven is een ondersteunde terugvaloptie en wordt vastgelegd als overdracht aan jou, niet als geautomatiseerde toegang.
Fase 5: toestemmingen, één keer per product afgesproken
De agent vraagt waar de code van de productwebsite staat, hoe die wordt gedeployd, welke branch productie is en wat de canonieke URL is. Dan volgt de vraag die later de meeste frictie scheelt: mag hij een officiële directorybadge aan de footer van dat product toevoegen, committen, pushen en opnieuw deployen? Reikwijdte, antwoord, datum en de toegestane repository en branch gaan naar authorizations.json. Een ‘nee’ blokkeert geen directory’s die geen badge vereisen. Hetzelfde bestand legt vast of gratis registraties, gratis definitieve inzendingen en specifieke acties in verificatiemails zijn toegestaan. De uitgaven blijven op nul, en toestemming voor het ene product geldt nooit voor een ander.
Fasen 6–7: een run plannen en de voortgang bewaren
Is de setup klaar, dan draait de agent doctor.py, dat onderscheid maakt tussen setup die ontbreekt en toestemming die jij bewust hebt geweigerd. Open de runplanner en begin met 10 nieuwe bevestigde inzendingen, met maximaal 2 tegelijk. De aanbeveling op basis van je lokale hardware is een startpunt; gebruik één worker als het geheugen krap is, de machine druk bezet is of aparte browserbesturing niet beschikbaar is. Voordat er parallel wordt gewerkt, controleert de agent of elke worker een eigen toegewezen platform en een geïsoleerde browseromgeving heeft. Hij kiest relevante playbooks, legt uit waarom ze passen en begint met een toegankelijke gratis route: zoeken naar een bestaande vermelding, de bestemming verifiëren, kloppende tekst voorbereiden, controleren dat er niets in rekening wordt gebracht, indienen binnen de toestemming en de werkelijke uitkomst vastleggen. Een goed eerste resultaat is vaak een ingediende inzending die wacht op beoordeling, en geen live pagina – zie de gids over uitkomsten vastleggen.
Gebruik /goal als je agent dat ondersteunt, met de opgeslagen runprompt; plak de prompt anders als gewoon bericht. Het doel is om door te werken aan de afgesproken run, in plaats van na het eerste resultaat te stoppen. Een bevestigde nieuwe inzending die wacht op beoordeling, in een wachtrij staat, is ingepland of live is, telt één keer per platform. Concepten, bestaande vermeldingen, betaalde routes en overdrachten aan jou tellen niet mee. De agent legt elke uitkomst vast, sluit na het opslaan van het bewijs alleen het venster dat aan die inzending is toegewezen en gaat verder met geschikte alternatieven. Niet-opgeslagen formulieren en overdrachten aan jou laat hij staan.
Om de sessie te pauzeren of af te sluiten, werkt de agent onboarding.json alleen bij met controles die hij echt heeft waargenomen, schrijft hij niet-gevoelig bewijs en openstaande stappen naar SESSION.md, zet hij opvolgdatums in FOLLOW-UP.md en vat hij samen wat klaar is, wat nog loopt, wat op jou wacht en wat de volgende stap is. Vóór elke push draait een privacycontrole in Git. De toets voor een goede eerste sessie: de volgende agent kan verder zonder iets opnieuw te registreren of twee keer om vaste toestemmingen te vragen. Op de pagina over hoe het werkt zie je waar dit in het geheel past.