LaunchRepoUsa o CLI: para obteres os melhores resultados, usa sempre o Claude Code CLI ou o Codex CLI em vez das aplicações de desktop.
Com o espaço de trabalho e o painel prontos, o teu agente segue o ONBOARDING.md, preenche ficheiros a partir de fontes verificadas e reaproveita respostas que já existem. O onboarding.json e o SESSION.md guardam a próxima ação se uma sessão parar.
Fases 1–2: orientação e uma casa privada
O agente começa por explicar o plano: entender o produto, ligar o browser e a caixa de correio de verificação, acordar como pode publicar listagens e badges no site, e preservar a configuração para sessões futuras. Pede nome, URL e pasta de código local do primeiro produto e lê-os antes de perguntar mais. Verifica também o que consegue realmente fazer nesta sessão — um terminal sozinho não é controlo do browser, e o kit proíbe alegar ter ferramentas que a sessão não consegue invocar.
A fase 2 dá aos teus dados uma casa privada. Se o agente ainda estiver no repositório de entrega comprado, inicializa o espaço de trabalho independente que o arranque em três passos cria e ajuda-te a configurar o teu remoto privado. Diz claramente que dados de login guardados, se consentires em guardá-los, vivem nesse repositório privado — legíveis por quem tiver acesso, incluindo ao histórico — e nunca no repositório de entrega. Dono, repositório, verificação de visibilidade e escolha de credenciais vão para o workspace.json; com um gestor de segredos, só se guardam referências. Pergunta também, uma única vez, se os problemas podem ser comunicados automaticamente aos mantenedores do LaunchRepo como issues no GitHub, sem segredos nem endereços de e-mail; a resposta fica guardada no workspace.json e pode ser alterada mais tarde nas Definições do painel.
Fase 3: o briefing do produto e a tua data de lançamento
O agente corre scripts/new-product.py com um slug curto em minúsculas, preenche o product.json — o ficheiro de contexto do produto que todos os playbooks leem — a partir das tuas respostas e escreve o texto do produto no copy.md num curto workshop de copy: público, problema, diferenciador, funcionalidades reais, preço ou trial, fase de lançamento, capturas de ecrã genuínas e logótipo. O texto resultante é-te mostrado para correções. Duas regras protegem-te de listagens embaraçosas: capacidades nunca são derivadas de um concorrente, e funcionalidades planeadas nunca são descritas como disponíveis. O que não se sabe fica vazio.
Esta fase pergunta também quando devem os primeiros lançamentos ficar online e se há uma data antes da qual nada pode ser publicado — com o aviso claro de que os diretórios gratuitos põem as submissões em fila de revisão e publicar pode levar semanas, não dias. A tua resposta torna-se earliest_launch_date no product.json, a data mínima de lançamento que o record.py impõe mais tarde.
O identity.json capta depois nome público, e-mail de contacto, alcunha, factos da organização e método de início de sessão preferido que autorizas, mantendo o e-mail privado da conta separado do endereço de contacto público. Antes de isto chegar a uma listagem, o agente faz o curto briefing de representação.
Fase 4: o Chrome e a caixa de correio
Seguindo o guia de ligação ao Chrome, o agente guia-te pela página de depuração remota do Chrome e pelas permissões do macOS que surjam, e faz uma verificação rápida visível numa página pública. O agente usa o acesso à caixa de correio que já autorizaste e só te pede para iniciares sessão se não conseguir chegar à caixa de correio; confirma que é a conta pretendida sem copiar mensagens. Os e-mails de verificação concluem registos e listagens, por isso o âmbito do acesso à caixa de correio fica registado em authorizations.json. Reencaminhar códigos à mão é um recurso suportado, registado como passagem para humano e não como acesso automatizado.
Fase 5: permissões, acordadas uma vez por produto
O agente pergunta onde vive o código do site do produto, como faz deploy, qual o branch de produção e qual o URL canónico. Depois, a pergunta que mais fricção poupa: pode adicionar um badge de diretório oficial ao rodapé desse produto, fazer commit, push e novo deploy? Âmbito, resposta, data e o repositório e branch permitidos vão para o authorizations.json. Um «não» não bloqueia os diretórios que não precisam de badge. O mesmo ficheiro regista se registos gratuitos, submissões finais gratuitas e ações específicas em e-mails de verificação estão autorizados. A despesa fica a zero, e uma autorização para um produto nunca se estende a outro.
Fases 6–7: planear uma execução e guardar o progresso
Com a configuração feita, o agente corre o doctor.py, separando configuração em falta de permissões recusadas de propósito. Abre o planeador da execução e começa com 10 submissões novas confirmadas e um worker de browser. Um segundo worker é uma opção avançada para mais tarde, depois de testado o controlo de browsers separados; hardware mais potente, por si só, não o justifica. O agente escolhe playbooks relevantes entre as vias prontas e gratuitas do momento, explica o encaixe, propõe uma execução mais pequena se houver menos vias adequadas e reserva uma plataforma de cada vez: procurar uma listagem existente, verificar o destino, preparar texto exato, confirmar que nada é cobrado, submeter dentro da autorização, registar o resultado real. Um bom primeiro resultado é muitas vezes uma revisão submetida e não uma página live — vê o guia de registo de resultados.
Usa /goal se o teu agente o suportar, com o prompt da execução guardado; caso contrário, cola o prompt como mensagem normal. O objetivo é continuar a trabalhar na execução acordada, em vez de parar depois do primeiro resultado. Uma submissão nova confirmada que aguarda revisão, está em fila, agendada ou live conta uma vez por plataforma. Rascunhos, listagens já existentes, vias pagas e passagens para humano não contam. O agente regista cada resultado, fecha apenas a janela atribuída a essa submissão depois de guardar a evidência, e continua com alternativas adequadas. Preserva formulários por guardar e passagens para humano.
Para pausar ou fechar a sessão, o agente atualiza o onboarding.json apenas com verificações que observou de facto, escreve evidência não sensível e passos em aberto no SESSION.md, põe as datas de acompanhamento no FOLLOW-UP.md e resume o que está feito, pendente, à tua espera e a seguir. Uma verificação de privacidade do git corre antes de cada push. O teste de uma boa primeira sessão: o agente seguinte consegue continuar sem registar nada de novo nem pedir permissões permanentes duas vezes. A página como funciona mostra onde isto entra no fluxo completo.