LaunchRepoEste é o guia que gostava de ter tido antes do meu próprio lançamento: o que acontece de facto, e por que ordem, quando apontas o Claude Code ao repositório da LaunchRepo e lhe pedes que lance o teu produto em diretórios. Segue os documentos do repositório — START.md, ONBOARDING.md e BROWSER-SETUP.md — em linguagem simples, assinalando onde tu tens de agir. Nada é tão específico do Claude Code que não funcione com o Codex ou o Cursor; as páginas de agentes cobrem as diferenças. O Claude Code é simplesmente o que eu uso.
Duas expectativas a definir. Primeira: isto não é um lançamento com um clique. O agente faz o trabalho repetitivo, mas és tu que ligas o browser, aprovas os textos, resolves os CAPTCHA e confirmas o que está online. Segunda: nenhum passo abaixo promete uma listagem — cada diretório decide por si o que publica, e muitos planos gratuitos demoram semanas.
Passo 0: o que precisas
- O repositório. Depois da compra recebes um convite para um repositório privado no GitHub. Clona-o.
- Python 3.10 ou mais recente em macOS ou Linux. O tracker, o painel e os scripts auxiliares são Python puro, sem dependências para instalar.
- Claude Code com uma integração de browser. Um terminal sozinho não preenche formulários; a configuração de browser do repositório usa o Chrome DevTools MCP, que precisa de Node.js para o
npx. - Chrome 144 ou mais recente, com a tua conta Google e a tua caixa de correio com sessão iniciada — as que queres que os diretórios conheçam.
- Os factos do teu produto: nome, URL, uma descrição real, preços, fase de lançamento, capturas genuínas e um logótipo. Não desejos de marketing; o que existe hoje.
Passo 1: o prompt inicial
Abre a pasta clonada no Claude Code e cola o prompt do START.md, exatamente como está escrito:
Read AGENTS.md, then follow “Start the dashboard for the owner”. Create my private workspace if I do not have one yet, start the dashboard, and give me the link.
O prompt está em inglês e fica em inglês; o agente fala contigo na tua língua assim que tiver lido as instruções. O que acontece a seguir é determinístico: o agente lê o AGENTS.md, cria um espaço de trabalho privado ao lado do clone — os teus produtos e credenciais nunca vivem no repositório entregue —, arranca o painel local e responde com um link 127.0.0.1. Abre-o. Tudo o resto pode ser feito nesse separador ou no chat; os formulários do painel escrevem os mesmos ficheiros que o agente lê.
Se preferires fazê-lo tu próprio, o repositório documenta dois comandos: um inicializa o espaço de trabalho, o outro arranca o painel. Uma flag --demo serve um espaço descartável com um produto fictício para espreitares primeiro.
Passo 2: a entrevista de onboarding
O ONBOARDING.md diz ao agente para conduzir a tua primeira sessão uma fase de cada vez e ler os ficheiros existentes antes de perguntar algo duas vezes. Na prática, parece uma entrevista.
Onde estamos. O agente explica o que é o espaço de trabalho e pergunta o nome, o URL e a pasta local com o código ou as notas do teu primeiro produto. Inspeciona essas fontes antes de perguntar mais e determina o teu sistema operativo, o teu agente e que ferramentas de browser consegue chamar — está proibido de afirmar ter ferramentas que a sessão não tem.
Uma casa privada. O agente ajuda-te a criar o teu próprio remoto privado para o espaço de trabalho e explica, sem rodeios, que as credenciais reutilizáveis guardadas lá podem ser lidas por toda a gente com acesso a esse repositório, incluindo o histórico. Tu decides se as credenciais vão para o espaço de trabalho, para um gestor de segredos (só referências) ou para lado nenhum. O ficheiro do espaço de trabalho regista essa escolha.
O produto. Um script cria uma pasta de produto a partir de um slug curto; depois o agente preenche o product.json com as tuas respostas: público, problema, diferenciador, funcionalidades reais, preços ou teste gratuito, fase de lançamento, capturas e logótipo. Um workshop de texto transforma isso em copy.md com variantes para diferentes limites de campo. O desconhecido fica vazio — o agente tem instruções para não derivar capacidades da concorrência nem transformar funcionalidades planeadas em disponíveis.
Esta fase também define a data mais cedo de lançamento. Muitos diretórios gratuitos põem as submissões numa fila de revisão; a confirmação pode demorar semanas. O agente pergunta se há uma data antes da qual nada deve ser publicado, escreve-a no product.json, e o tracker recusa marcar o que quer que seja como agendado antes dessa data.
Identidade. O identity.json guarda o nome público, o e-mail que queres que os diretórios usem, a tua alcunha e os factos da organização que estás disposto a publicar. Segue-se uma breve sessão de briefing de relações públicas, em que corriges a forma como o agente te descreve antes de algo disso chegar a uma listagem pública.
Passo 3: ligar o Chrome e a tua caixa de correio
É o passo que as pessoas saltam antes de se perguntarem porque é que o agente não inicia sessão. O agente precisa de um browser que possas ver e supervisionar. O BROWSER-SETUP.md dá duas vias.
Via A: o teu Chrome existente. Verifica chrome://version (144+), abre chrome://inspect/#remote-debugging no Chrome que queres que o agente use e ativa lá a depuração remota. Depois acrescenta o Chrome DevTools MCP à configuração MCP do Claude Code com --autoConnect. Dispara uma ação inofensiva a partir do agente e aprova tu próprio o pedido de ligação do Chrome, na janela certa. Um processo MCP a correr não prova acesso ao browser; um separador visível a mexer-se, sim.
Via B: um perfil dedicado. Arranca o Chrome com um diretório de dados de utilizador próprio dentro do espaço de trabalho e uma porta local de depuração remota, inicia sessão nas contas necessárias nessa janela e aponta a configuração MCP a --browserUrl em vez de --autoConnect. Nunca os dois ao mesmo tempo, nunca com a porta exposta para lá do localhost.
No macOS, concede apenas as permissões de Automatização, Acessibilidade ou Gravação de ecrã de que a tua integração realmente precisa; uma ligação DevTools pura normalmente não precisa de nenhuma. O pedido de ligação do Chrome pode voltar depois de religar — é um controlo de segurança, não um erro, e o repositório diz ao agente para não prometer que desaparece.
Depois o teste de fumo: o agente abre um separador novo, navega para a página inicial pública de um diretório, lê o título principal e diz-te que separador usou. Tu vês a mesma janela. A seguir inicia sessão num diretório-alvo e verifica no menu da conta se a identidade é a certa — completar um OAuth não prova que a sessão está iniciada no site de destino. Por fim confirma o acesso à caixa de correio, porque os e-mails de verificação são a forma de concluir registos de conta. Reencaminhar códigos à mão é um recurso suportado; o tracker regista-o como passagem humana, não como acesso automatizado.
Passo 4: permissões, uma vez por produto
Antes de submeter o que quer que seja, o agente lê o WEBSITE-AND-EMAIL.md e faz um punhado de perguntas que não voltará a fazer: onde vive o código do teu site, como é feito o deploy, que branch é produção, se pode acrescentar ao rodapé os badges exigidos por alguns diretórios e fazer push, e se registos gratuitos, submissões finais gratuitas e as ações concretas com e-mails de verificação estão autorizados. As respostas, a data e o âmbito exato vão para o authorizations.json. O gasto fica em zero — o agente tem ordem para recusar todos os upsells pagos.
Recusar os badges não é problema; apenas exclui os diretórios que os exigem. O que não deves fazer é estender as permissões de um produto a outro. O ficheiro é por produto, de propósito.
Passo 5: o primeiro resultado útil
Agora o agente corre o doctor.py, que separa configuração em falta de permissões que recusaste, e escolhe do índice de playbooks e do catálogo três a cinco diretórios que encaixem no teu produto — explica o encaixe e os pré-requisitos e começa por uma via gratuita acessível. Para cada diretório, o playbook conduz o mesmo ciclo: procurar primeiro uma listagem existente, verificar que é o site certo, preparar o texto dentro dos limites dos campos, confirmar que nada custa dinheiro, submeter só dentro da tua autorização e registar o resultado real.
Conta com passagens de testemunho. Um CAPTCHA, uma verificação em dois passos, um estado de conta pouco claro ou um badge obrigatório param a execução: o agente regista prepared_needs_human, o painel lista a plataforma em «precisa de ti», e tu terminas esse passo no teu próprio browser. É de propósito — o repositório proíbe contornar ou fazer alterações furtivas.
Um bom primeiro resultado é muitas vezes uma submissão em revisão, não uma página online. É normal.
Passo 6: o que os estados do tracker significam
Cada resultado passa pelo record.py para o submissions.csv, e o painel mostra os mesmos onze estados. Cada um está ligado a uma observação mínima, para que um «feito» não possa ser inflacionado. Nas minhas palavras:
- draft — o trabalho está preparado, mas a submissão final não foi confirmada.
- prepared_needs_human — algo específico bloqueia e só tu podes agir: CAPTCHA, 2FA, uma conta pouco clara.
- submitted_pending_review — a plataforma recebeu explicitamente a submissão e a moderação ainda está pendente.
- queued — a plataforma confirmou uma posição na fila ou um estado de lista de espera.
- scheduled — a plataforma confirmou uma data de lançamento igual ou posterior à tua data mais cedo; qualquer aprovação pendente fica na nota.
- live — uma listagem pública foi verificada sem etiqueta de pendente. Precisa do URL público e da tua confirmação.
- already_listed — uma listagem pública existente foi encontrada e verificada; mesmo requisito de URL e atestação que live.
- blocked — elegibilidade, capacidade da conta ou um facto obrigatório em falta impedem o progresso.
- deferred_paid — a única via utilizável exige pagamento; nada foi comprado.
- not_a_fit — o produto não cumpre os critérios de público ou de listagem.
- unavailable — a via ou a plataforma não podem ser usadas neste momento; o problema observado fica anotado.
Daqui saem três consequências. Um ecrã de agradecimento não é live. Uma caixa de distribuição a parceiros num site não conta como segunda submissão até a segunda plataforma confirmar. E scheduled num plano gratuito pode ainda demorar semanas a ser publicado. O guia de acompanhamento de estados explica como manter tudo isso separado.
Passo 7: deixar um espaço de trabalho retomável
No fim de uma sessão, o agente atualiza a lista de onboarding apenas com o que observou de facto, escreve evidência não sensível e passos em aberto no SESSION.md, põe as próximas datas no FOLLOW-UP.md e corre uma verificação de privacidade do git antes de fazer push para o teu remoto privado. A sessão seguinte — a tua ou a de outro agente — lê primeiro o tracker, prioriza as passagens de testemunho e os lançamentos agendados a verificar, e depois as submissões pendentes cuja janela de revisão já passou. Volta a verificar os registos existentes em vez de submeter outra vez para subir numa fila.
Essa capacidade de retomar é todo o ponto. O teu segundo produto reutiliza a configuração do browser, a identidade, o padrão de autorizações e os playbooks; só o product.json e os textos são novos.
Para onde ir a seguir
A página do Claude Code tem o mesmo prompt inicial, a lista de passagens e as notas de browser num só ecrã. Como funciona mostra os seis passos com o vídeo do fundador. O catálogo de diretórios é onde podes ler alguns playbooks públicos antes de decidir, e a página de preço é onde o repositório se compra, uma vez.
Fontes: START.md, ONBOARDING.md, BROWSER-SETUP.md e RUNBOOK.md no repositório da LaunchRepo (notas de versão no changelog); o prompt inicial é citado literalmente de prompts/start.md. Não são dados números de tempo ou de resultados porque nenhum foi medido entre clientes.