Première session : l’onboarding mené par l’agent

Utilisez la CLI : pour de meilleurs résultats, utilisez toujours Claude Code CLI ou Codex CLI plutôt que les applications de bureau.

Une fois votre espace de travail et votre tableau de bord prêts, votre agent suit ONBOARDING.md, remplit les fichiers à partir de sources vérifiées et réutilise les réponses existantes. Si une session s’interrompt, onboarding.json et SESSION.md conservent l’action suivante.

Phases 1–2 : orientation et un espace privé

L’agent expose d’abord le plan : comprendre le produit, connecter le navigateur et la boîte mail de vérification, convenir de la façon dont il peut publier fiches et badges de site, et préserver la configuration pour les sessions futures. Il demande le nom, l’URL et le dossier de code local du premier produit, et les lit avant toute autre question. Il vérifie aussi ce qu’il peut réellement faire dans cette session — un terminal seul ne contrôle pas le navigateur, et le kit interdit de revendiquer des outils que la session ne peut pas appeler.

La phase 2 donne à vos données un espace privé. Si l’agent est encore dans le dépôt de livraison acheté, il initialise l’espace de travail indépendant du démarrage en trois étapes et vous aide à configurer votre propre remote privé. Il dit clairement que les identifiants stockés, si vous y consentez, vivent dans ce dépôt privé — lisibles par quiconque y a accès, y compris à son historique — et jamais dans le dépôt de livraison. Propriétaire, dépôt, contrôle de visibilité et choix d’identifiants vont dans workspace.json ; avec un gestionnaire de secrets, seules des références sont enregistrées. Il demande aussi une seule fois si les problèmes peuvent être signalés automatiquement aux mainteneurs de LaunchRepo sous forme d’issues GitHub, secrets et adresses e-mail retirés ; la réponse est enregistrée dans workspace.json et peut être modifiée plus tard dans les réglages du tableau de bord.

Phase 3 : le brief produit et votre date de lancement

L’agent exécute scripts/new-product.py avec un slug court en minuscules et remplit product.json — le fichier de contexte produit que lit chaque playbook — à partir de vos réponses, puis rédige le texte produit dans copy.md au cours d’un court atelier de rédaction : audience, problème, différenciateur, fonctionnalités réelles, tarifs ou essai, stade de lancement, vraies captures d’écran et logo. Le texte obtenu vous est soumis pour corrections. Deux règles vous protègent des fiches embarrassantes : aucune capacité déduite d’un concurrent, aucune fonctionnalité prévue décrite comme disponible. Les inconnues restent vides.

Cette phase demande aussi quand les premiers lancements doivent être en ligne et s’il existe une date avant laquelle rien ne doit paraître — en avertissant clairement que les annuaires gratuits mettent les soumissions en file de modération et que publier peut prendre des semaines, pas des jours. Votre réponse devient earliest_launch_date dans product.json, la date de lancement au plus tôt que record.py fera respecter ensuite.

identity.json recueille ensuite le nom public, l’e-mail de contact, le pseudonyme, les faits d’organisation et la méthode de connexion préférée que vous autorisez, en séparant l’e-mail privé de votre compte de l’adresse de contact publique. Avant que tout cela n’atteigne une fiche, l’agent mène le court briefing de représentation.

Phase 4 : Chrome et la boîte mail

Avec le guide de connexion à Chrome, l’agent vous accompagne sur la page de débogage à distance de Chrome et les éventuelles permissions macOS, puis fait un test de fumée visible sur une page publique. L’agent utilise l’accès à la boîte mail que vous avez déjà autorisé et ne vous demande de vous connecter que s’il ne parvient pas à l’atteindre ; il confirme qu’il s’agit du bon compte sans copier de messages. Les e-mails de vérification finalisent inscriptions et fiches ; le périmètre d’accès à la boîte mail est donc consigné dans authorizations.json. Transmettre les codes à la main reste un repli accepté, enregistré comme relais humain plutôt que comme accès automatisé.

Phase 5 : les permissions, convenues une fois par produit

L’agent demande où vit le code du site du produit, comment il se déploie, quelle branche est en production et quelle est l’URL canonique. Puis la question qui évite le plus de friction ensuite : peut-il ajouter un badge d’annuaire officiel au pied de page de ce produit, commiter, pousser et redéployer ? Périmètre, réponse, date, dépôt et branche autorisés vont dans authorizations.json. Un « non » ne bloque pas les annuaires qui n’exigent aucun badge. Le même fichier consigne si inscriptions gratuites, soumissions finales gratuites et certaines actions sur les e-mails de vérification sont autorisées. Les dépenses restent à zéro, et une autorisation pour un produit ne s’étend jamais à un autre.

Phases 6–7 : planifier une exécution, puis suivre sa progression

Configuration terminée, l’agent exécute doctor.py, en distinguant configuration manquante et permissions délibérément refusées. Ouvrez le planificateur d’exécution et commencez avec 10 nouvelles soumissions confirmées et un seul worker navigateur. Un second worker est une option avancée pour plus tard, une fois le contrôle séparé des navigateurs testé ; une machine plus puissante ne suffit pas à le justifier. L’agent choisit des playbooks pertinents parmi les voies actuellement prêtes et gratuites, justifie le choix, propose une exécution plus petite s’il existe moins de voies adaptées, et prend une plateforme à la fois : chercher une fiche existante, vérifier la destination, préparer un texte exact, confirmer que rien n’est facturé, soumettre dans le cadre autorisé, enregistrer le résultat réel. Un bon premier résultat est souvent une soumission en modération, pas une page en ligne — voir le guide d’enregistrement des résultats.

Utilisez /goal si votre agent le prend en charge, avec le prompt d’exécution enregistré ; sinon, collez le prompt comme un message normal. L’objectif est de continuer à travailler sur l’exécution convenue plutôt que de s’arrêter après le premier résultat. Une nouvelle soumission confirmée, en modération, en file, programmée ou en ligne, compte une fois par plateforme. Les brouillons, les fiches existantes, les voies payantes et les relais humains ne comptent pas. L’agent enregistre chaque résultat, ne ferme que la fenêtre attribuée à cette soumission après avoir enregistré ses preuves, et continue avec des alternatives adaptées. Il préserve les formulaires non enregistrés et les relais humains.

Pour mettre en pause ou clore la session, l’agent met à jour onboarding.json avec les seules vérifications réellement observées, écrit les preuves non sensibles et les étapes ouvertes dans SESSION.md, place les dates de relance dans FOLLOW-UP.md, et résume ce qui est fait, en attente, à votre charge et à venir. Un contrôle de confidentialité git s’exécute avant chaque push. Le test d’une bonne première session : l’agent suivant continue sans rien réenregistrer ni redemander les permissions permanentes. La page comment ça marche montre où cela se situe dans le flux global.