LaunchRepoUsa la CLI: per ottenere i risultati migliori, usa sempre Claude Code CLI o Codex CLI invece delle app desktop.
Quando workspace e dashboard sono pronti, il tuo agente segue ONBOARDING.md, compila i file partendo da fonti verificate e riutilizza le risposte che esistono già. onboarding.json e SESSION.md conservano la prossima azione se una sessione si interrompe.
Fasi 1–2: orientamento e una sede privata
L’agente comincia spiegando il piano: capire il prodotto, collegare il browser e la casella di posta per le verifiche, concordare come può pubblicare schede e badge sul sito web, e conservare la configurazione per le sessioni future. Ti chiede nome, URL e cartella locale del codice del primo prodotto, e li legge prima di chiederti qualsiasi altra cosa. Verifica anche cosa può fare davvero in questa sessione: un terminale da solo non equivale al controllo del browser, e il toolkit vieta di dichiarare strumenti che la sessione non può richiamare.
La fase 2 dà ai tuoi dati una sede privata. Se l’agente si trova ancora nel repository di consegna che hai acquistato, inizializza il workspace indipendente creato dall’avvio in tre passaggi e ti aiuta a configurare un tuo remote privato. Ti dice chiaramente che le credenziali di accesso salvate, se acconsenti a salvarle, stanno in quel repository privato, leggibili da chiunque vi abbia accesso (cronologia compresa), e mai nel repository di consegna. Proprietario, repository, verifica della visibilità e scelta delle credenziali finiscono in workspace.json; se usi un secret manager, vengono salvati solo i riferimenti.
Fase 3: il brief di prodotto e la data di lancio
L’agente esegue scripts/new-product.py con uno slug breve in minuscolo e compila product.json, il file di contesto del prodotto che ogni playbook legge, a partire dalle tue risposte: pubblico, problema, elemento distintivo, funzionalità reali, prezzi o prova, fase di lancio, screenshot autentici e logo. I testi risultanti ti vengono mostrati perché tu li corregga. Due regole ti proteggono da schede imbarazzanti: le funzionalità non vengono mai ricavate da un concorrente, e quelle pianificate non vengono mai descritte come disponibili. Ciò che non si sa resta vuoto.
In questa fase l’agente chiede anche quando devono andare online i primi lanci e se esiste una data prima della quale non deve uscire nulla, con un avvertimento chiaro: le directory gratuite mettono gli invii in coda per la revisione, e la pubblicazione può richiedere settimane, non giorni. La tua risposta diventa earliest_launch_date in product.json, la data minima di lancio che record.py farà rispettare in seguito.
Poi identity.json raccoglie il nome pubblico, l’email di contatto, il nickname e i dati sull’organizzazione che autorizzi, tenendo separata l’email privata del tuo account dall’indirizzo di contatto pubblico. Prima che uno qualsiasi di questi dati arrivi su una scheda, l’agente svolge il breve briefing di rappresentazione.
Fase 4: Chrome e la casella di posta
Seguendo la guida alla connessione con Chrome, l’agente ti accompagna nella pagina del debug remoto di Chrome e negli eventuali permessi di macOS, poi esegue un test visibile su una pagina pubblica. Nella tua casella di posta web accedi tu, nel browser collegato; l’agente verifica che sia l’account previsto senza copiare messaggi. Le email di verifica completano registrazioni e schede, quindi l’ambito dell’accesso alla posta viene registrato in authorizations.json. Inoltrare i codici a mano è un’alternativa supportata, registrata come passaggio di consegne a una persona e non come accesso automatizzato.
Fase 5: permessi, concordati una volta per prodotto
L’agente chiede dove si trova il codice del sito del prodotto, come avviene il deploy, qual è il branch di produzione e qual è l’URL canonico. Poi arriva la domanda che più di tutte ti evita attriti in seguito: può aggiungere un badge di directory ufficiale nel footer di quel prodotto, fare commit, push e un nuovo deploy? Ambito, risposta, data e repository e branch consentiti finiscono in authorizations.json. Un “no” non blocca le directory che non richiedono badge. Lo stesso file registra se sono autorizzate le registrazioni gratuite, gli invii finali gratuiti e specifiche azioni sulle email di verifica. La spesa resta a zero, e un’autorizzazione data per un prodotto non si estende mai a un altro.
Fasi 6–7: pianifica una run e conservane i progressi
Completata la configurazione, l’agente esegue doctor.py, che distingue ciò che manca nella configurazione dai permessi che hai negato di proposito. Apri il pianificatore delle run e parti con 10 nuovi invii confermati, al massimo 2 in parallelo. La raccomandazione basata sull’hardware locale è un punto di partenza; usa un solo worker se la memoria scarseggia, se la macchina è sotto carico o se non è disponibile un controllo del browser separato. Prima di lavorare in parallelo, l’agente verifica che ogni worker abbia una propria piattaforma assegnata e un workspace del browser isolato. Sceglie i playbook pertinenti, spiega perché sono adatti e inizia da un percorso gratuito accessibile: cercare una scheda esistente, verificare la destinazione, preparare testi accurati, confermare che non venga addebitato nulla, inviare entro i permessi concessi, registrare l’esito reale. Un buon primo risultato è spesso un invio in revisione più che una pagina live: vedi la guida alla registrazione degli esiti.
Usa /goal se il tuo agente lo supporta, con il prompt della run salvato; altrimenti incolla il prompt come un normale messaggio. L’obiettivo è continuare a lavorare sulla run concordata, invece di fermarsi dopo il primo risultato. Un nuovo invio confermato in attesa di revisione, in coda, programmato o live conta una volta per piattaforma. Bozze, schede già esistenti, percorsi a pagamento e passaggi di consegne a una persona non contano. L’agente registra ogni esito, chiude solo la finestra assegnata a quell’invio dopo averne salvato le prove e prosegue con alternative adatte. Conserva i moduli non salvati e i passaggi di consegne a una persona.
Per mettere in pausa o chiudere la sessione, l’agente aggiorna onboarding.json solo con i controlli che ha effettivamente osservato, scrive prove non sensibili e passaggi aperti in SESSION.md, inserisce le date di follow-up in FOLLOW-UP.md e riassume cosa è fatto, cosa è in sospeso, cosa aspetta te e cosa viene dopo. Prima di ogni push viene eseguito un controllo di privacy su git. Il test di una buona prima sessione: il prossimo agente può continuare senza registrare di nuovo nulla e senza chiedere due volte i permessi permanenti. La pagina su come funziona mostra dove si colloca tutto questo nel flusso complessivo.