LaunchRepoUsa la CLI: para obtener los mejores resultados, usa siempre Claude Code CLI o Codex CLI en lugar de las apps de escritorio.
Con el espacio de trabajo y el panel listos, tu agente sigue ONBOARDING.md, rellena los archivos a partir de fuentes verificadas y reutiliza las respuestas que ya existen. onboarding.json y SESSION.md conservan la siguiente acción si una sesión se interrumpe.
Fases 1–2: orientación y un hogar privado
El agente empieza explicando el plan: entender el producto, conectar el navegador y el buzón de verificación, acordar cómo puede publicar fichas y badges en tu web, y conservar la configuración para futuras sesiones. Pide nombre, URL y carpeta de código local del primer producto, y los lee antes de preguntar nada más. También comprueba qué puede hacer realmente en esta sesión: un terminal a secas no es control del navegador, y el kit prohíbe atribuirse herramientas que la sesión no puede invocar.
La fase 2 da a tus datos un hogar privado. Si el agente sigue dentro del repositorio de entrega comprado, inicializa el espacio de trabajo independiente que crea el inicio en tres pasos y te ayuda a configurar tu propio remoto privado. Avisa sin rodeos de que los datos de acceso, si consientes en guardarlos, viven en ese repositorio privado —legibles por cualquiera con acceso, incluido a su historial— y nunca en el repositorio de entrega. Propietario, repositorio, comprobación de visibilidad y elección de credenciales van a workspace.json; con un gestor de secretos, solo se guardan referencias. También pregunta una sola vez si los problemas pueden notificarse automáticamente a los mantenedores de LaunchRepo como issues de GitHub, sin secretos ni direcciones de correo; la respuesta se guarda en workspace.json y puedes cambiarla más adelante en los ajustes del panel.
Fase 3: el briefing del producto y tu fecha de lanzamiento
El agente ejecuta scripts/new-product.py con un slug corto en minúsculas, rellena product.json —el archivo de contexto del producto que leen todos los playbooks— con tus respuestas y escribe el copy del producto en copy.md en un breve taller de copy: audiencia, problema, diferenciador, funciones reales, precio o prueba, fase de lanzamiento, capturas auténticas y logo. El copy resultante se te muestra para corregirlo. Dos reglas te protegen de fichas bochornosas: las capacidades nunca se derivan de un competidor, y las funciones planificadas nunca se describen como disponibles. Lo desconocido se queda vacío.
Esta fase también pregunta cuándo deberían salir los primeros lanzamientos y si hay una fecha antes de la cual nada puede publicarse, avisando claramente de que los directorios gratuitos ponen los envíos en cola de revisión y la publicación puede tardar semanas, no días. Tu respuesta se convierte en earliest_launch_date en product.json, la fecha mínima de lanzamiento que record.py hace cumplir más adelante.
identity.json recoge después el nombre público, el correo de contacto, el apodo, los datos de la organización y el método de inicio de sesión preferido que autorizas, y mantiene el correo privado de tu cuenta separado del contacto público. Antes de que nada de esto llegue a una ficha, el agente ejecuta el breve briefing de representación.
Fase 4: Chrome y el buzón
Siguiendo la guía de conexión con Chrome, el agente te guía por la página de depuración remota de Chrome y los permisos de macOS necesarios, y después hace una prueba de humo visible en una página pública. El agente usa el acceso al buzón que ya autorizaste y solo te pide que inicies sesión si no puede llegar a él; confirma que es la cuenta prevista sin copiar mensajes. Los correos de verificación completan registros y fichas, así que el alcance del acceso al buzón queda registrado en authorizations.json. Reenviar códigos a mano es una alternativa soportada, registrada como relevo humano y no como acceso automatizado.
Fase 5: permisos, acordados una vez por producto
El agente pregunta dónde vive el código de la web del producto, cómo se despliega, qué rama es producción y cuál es la URL canónica. Y luego la pregunta que más fricción ahorra: ¿puede añadir un badge de directorio oficial al pie de esa web, hacer commit, push y redesplegar? Alcance, respuesta, fecha y repositorio y rama permitidos van a authorizations.json. Un «no» no bloquea los directorios que no necesitan badge. El mismo archivo registra si se autorizan registros gratuitos, envíos finales gratuitos y acciones concretas sobre los correos de verificación. El gasto se queda en cero, y un permiso para un producto nunca se extiende a otro.
Fases 6–7: planificar una ejecución y conservar su progreso
Hecha la configuración, el agente ejecuta doctor.py, que separa lo que falta por configurar de los permisos que rechazaste a propósito. Abre el planificador de la ejecución y empieza con 10 envíos nuevos confirmados y un worker de navegador. Un segundo worker es una opción avanzada para más adelante, cuando ya se haya probado el control separado del navegador; un hardware más potente no basta para justificarlo. El agente elige playbooks relevantes entre las rutas listas y gratuitas del momento, explica el encaje, te ofrece una ejecución más pequeña si hay menos rutas adecuadas y reclama una plataforma cada vez: buscar una ficha existente, verificar el destino, preparar copy exacto, confirmar que no se cobra nada, enviar dentro del permiso concedido, registrar el resultado real. Un buen primer resultado suele ser una revisión enviada, no una página publicada; ver la guía para registrar resultados.
Usa /goal si tu agente lo admite, con el prompt de la ejecución guardada; si no, pega el prompt como un mensaje normal. El objetivo es seguir trabajando en la ejecución acordada en lugar de parar tras el primer resultado. Un envío nuevo confirmado que espera revisión, está en cola, programado o publicado cuenta una vez por plataforma. Los borradores, las fichas existentes, las rutas de pago y los relevos humanos no cuentan. El agente registra cada resultado, cierra solo la ventana asignada a ese envío después de guardar su evidencia y continúa con alternativas adecuadas. Conserva los formularios sin guardar y los relevos humanos.
Para pausar o cerrar la sesión, el agente actualiza onboarding.json solo con comprobaciones observadas de verdad, escribe evidencia no sensible y pasos abiertos en SESSION.md, apunta las fechas de seguimiento en FOLLOW-UP.md y resume qué está hecho, pendiente, esperándote y qué sigue. Antes de cada push corre una comprobación de privacidad de git. La prueba de una buena primera sesión: el siguiente agente puede continuar sin volver a registrar nada ni pedir dos veces los permisos permanentes. La página de cómo funciona muestra dónde encaja esto en el flujo completo.