LaunchRepoEsta é uma execução completa do LaunchRepo com Claude Code, pela ordem em que acontece: o prompt que colas, as perguntas que o agente te faz, a ligação ao browser, a execução planeada e cada estado que o tracker pode registar. Segue a versão 1.9.0 do toolkit, de 29 de setembro de 2026, e o output de terminal que aparece mais abaixo vem de uma execução real dos próprios scripts do toolkit a 30 de setembro de 2026. Se primeiro queres saber se o LaunchRepo encaixa de todo no Claude Code, a página do Claude Code responde a isso num só ecrã. O guia da execução de lançamento descreve a mesma execução para qualquer agente.
Em resumo: o Claude Code faz o trabalho repetitivo de ler playbooks, preencher formulários e escrever no tracker. Tu trazes quatro coisas que só uma pessoa pode trazer: os factos do teu produto, um Chrome com sessão iniciada, a tua aprovação dos textos, e os CAPTCHA e pedidos de verificação em dois passos que as plataformas reservam a humanos. Cada listagem continua a ser decisão do diretório, e as revisões gratuitas demoram muitas vezes semanas, por isso o objetivo de uma execução é um conjunto de submissões honestas e confirmadas, não páginas instantâneas.
A execução num relance
| Passo | O Claude Code faz | Tu fazes | Prova de que funcionou |
|---|---|---|---|
| 1. Prompt inicial | Cria o espaço de trabalho privado, arranca o painel | Colas um prompt | Abre-se um link 127.0.0.1 |
| 2. Onboarding | Entrevista-te, preenche product.json e copy.md |
Respondes, corriges, aprovas | Um briefing que assinarias |
| 3. Chrome | Configura o Chrome DevTools MCP, faz um teste visível | Ativas a depuração remota, aprovas o pedido do Chrome | Vês o separador mexer-se |
| 4. Permissões | Regista o âmbito uma vez por produto | Decides sobre badges, contas, e-mail | authorizations.json |
| 5. A execução | Planeia 10 submissões, uma plataforma de cada vez | Resolves as passagens quando te pedem | Contagem confirmada no painel |
| 6. Tracker | Regista cada resultado com evidência | Confirmas as listagens públicas | Um estado por plataforma |
| 7. Retomar | Guarda o progresso e as próximas datas | Nada, até à próxima sessão | O agente seguinte continua |
Passo 0: o que precisas
- O repositório. Depois da compra recebes um convite para um repositório privado no GitHub. Clona-o e abre a pasta no Claude Code.
- Git e Python 3.10 ou mais recente em Windows, macOS ou Linux. O tracker, o painel e os scripts auxiliares usam apenas a biblioteca padrão do Python, por isso não há nada para instalar. No Windows usas
py -3sempre que a documentação dizpython3. - Chrome, uma versão LTS atual do Node.js e o npm para a ligação ao browser. O toolkit liga-se através do Chrome DevTools MCP, e o modo
--autoConnectprecisa do Chrome 144 ou mais recente. - Os factos do teu produto: nome, URL, público, funcionalidades reais, preços tal como são hoje, fase de lançamento, capturas de ecrã genuínas e um logótipo.
O repositório recomenda usar o Claude Code como CLI num terminal em vez da aplicação de desktop. É esse o fluxo documentado, e o prompt inicial lembra-te disso uma vez.
Passo 1: o prompt inicial
Cola o prompt do START.md exatamente como está escrito:
Recommend Claude Code CLI or Codex CLI in a terminal instead of the desktop apps for best results. If session metadata confirms desktop hosting, explicitly advise me to switch to the CLI and resume this same private workspace. Do not infer the host from a CLI engine version alone. 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. Then lead ONBOARDING.md one phase at a time. Reuse recorded permissions instead of asking again unless their scope is missing or conflicting. Actually test my visible existing Chrome profile and intended identity as BROWSER-SETUP.md requires; use the OS fallback if needed. Use one platform/browser worker by default. Build the normal run only from suitable free-ready routes, keep research separate, and preserve any draft that needs one exact human CAPTCHA/2FA action. Never claim browser control bypasses or reduces those challenges.
O prompt fica em inglês; o Claude Code responde na tua língua assim que tiver lido as instruções. Cria um espaço de trabalho privado ao lado do clone, por isso os teus produtos e credenciais nunca vivem no repositório entregue. Depois arranca o painel local e responde com um link 127.0.0.1. Tudo o que vem a seguir pode acontecer nesse separador ou no chat, porque os formulários do painel escrevem os mesmos ficheiros que o agente lê.
Preferes espreitar antes de te comprometeres? python3 scripts/dashboard.py --demo serve um espaço de trabalho descartável com um produto fictício.
Passo 2: a entrevista de onboarding
O ONBOARDING.md tem sete fases, e o agente conduz uma de cada vez. Lê os ficheiros existentes antes de perguntar o que quer que seja, por isso uma segunda sessão nunca repete a primeira.
Onde estamos. O agente pergunta o nome, o URL e a pasta com o código ou as notas do teu primeiro produto, e inspeciona essas fontes antes de fazer mais perguntas. Também determina o teu sistema operativo e que ferramentas de browser consegue de facto chamar. As instruções são diretas aqui: um terminal sozinho não é controlo do browser, e o agente não pode afirmar ter ferramentas que a sessão não tem.
Uma casa privada. O Claude Code ajuda-te a criar o teu próprio remoto privado para o espaço de trabalho e explica que quaisquer dados de acesso guardados lá podem ser lidos por toda a gente com acesso a esse repositório, incluindo o histórico. Tu escolhes: credenciais no espaço de trabalho, referências a um gestor de segredos, ou nada. Também pergunta uma vez se os problemas podem ser comunicados aos mantenedores do LaunchRepo como issues no GitHub, sem segredos nem endereços de e-mail. Sem resposta, a resposta é não.
O produto. Um script cria a pasta do produto, depois o agente preenche o ficheiro de contexto do produto product.json com as tuas respostas e corre o workshop de texto, que produz o copy.md com variantes para diferentes limites de campo. O que é desconhecido fica vazio. Funcionalidades planeadas nunca passam a disponíveis.
Esta fase também define a tua data mínima de lançamento. Muitos diretórios gratuitos põem as submissões numa fila de revisão durante semanas, por isso o agente pergunta se há uma data antes da qual nada deve ficar online, e o tracker recusa depois qualquer registo scheduled anterior a ela.
Identidade. O identity.json guarda o nome público, o e-mail de início de sessão e os factos da organização que autorizas. Antes de algo disso chegar a uma listagem, o agente faz o briefing de representação: três frases curtas de exemplo sobre ti, mostradas tal e qual para as corrigires.
Passo 3: ligar o Chrome e a tua caixa de correio
É este o passo que faz tudo o resto funcionar. O agente precisa de um browser que possas ver e supervisionar, e o BROWSER-SETUP.md suporta exatamente um transporte: Chrome DevTools MCP através da depuração remota do Chrome. O guia de ligação ao Chrome percorre as duas vias.
Via A: o teu Chrome existente. Verifica chrome://version (144 ou mais recente), abre chrome://inspect/#remote-debugging no Chrome que queres que o agente use e ativa lá a depuração remota. Depois regista o servidor no Claude Code com claude mcp add; o guia de clientes do Chrome DevTools MCP tem a linha exata, e o repositório acrescenta-lhe --autoConnect. A própria documentação MCP do Claude Code explica os âmbitos, se quiseres o servidor só para este projeto.
Via B: um perfil dedicado. Se o controlo de depuração remota não existir ou a ligação automática falhar, o Chrome arranca com o seu próprio diretório de perfil dentro do espaço de trabalho e uma porta local de depuração, e a configuração usa --browserUrl em vez disso. Inicias sessão uma vez nessa janela. A porta nunca sai do localhost, e os cookies nunca são copiados.
Depois vem o teste visível. Abres um separador em branco no perfil pretendido, o agente navega para https://example.com/ e lê o título “Example Domain”, e tu confirmas que foi esse mesmo separador que se mexeu. Isso prova o controlo deste único separador através do Chrome DevTools Protocol, nada mais; um processo MCP a correr ou um ecrã de OAuth concluído não são prova. No macOS, uma ligação destas normalmente não precisa de nenhuma permissão de Acessibilidade, Automatização ou Gravação de ecrã. Depois do teu primeiro início de sessão real, o agente verifica no menu da conta se a identidade é a certa e confirma o acesso à caixa de correio, porque os e-mails de verificação concluem a maioria dos registos. Reencaminhar códigos à mão é um recurso suportado, que o tracker regista como passagem humana.
O Chrome pode voltar a mostrar o pedido de ligação depois de religar. É um controlo de segurança, e o agente tem instruções para nunca prometer que desaparece nem para contornar CAPTCHA.
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, e se pode acrescentar ao rodapé os badges de diretório exigidos, fazer commit e voltar a fazer deploy. Também pergunta se registos gratuitos, submissões finais gratuitas e as respetivas ações 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, e todos os upsells pagos são recusados.
Recusar os badges não é problema: apenas exclui os diretórios que os exigem. Cada produto recebe a sua própria autorização, por isso um sim para um produto nunca passa para o seguinte.
Passo 5: planear a execução e ver o contador
Agora o doctor.py separa a configuração em falta das permissões que recusaste, e o agente abre o planeador da execução. As predefinições são deliberadas: 10 submissões novas, um worker de browser, 150 minutos ativos no total e 15 por plataforma. Só vias prontas e gratuitas entram na fila: recentes, com evidência, a funcionar e gratuitas sem condições. As vias com condições aparecem à parte, com os respetivos pré-requisitos. Se houver menos vias adequadas prontas do que o teu objetivo, o agente propõe a execução mais pequena e verdadeira. Onde o Claude Code suporta /goal, o objetivo gerado é proposto para esse comando; caso contrário, o mesmo texto funciona como prompt normal.
Eis como é a execução no terminal. Criámos um espaço de trabalho novo e um produto em branco com os scripts do toolkit a 30 de setembro de 2026 e corremos os comandos documentados. As linhas abaixo foram copiadas dessa execução, encurtadas aos campos relevantes:
$ python3 scripts/run.py --project projects/my-product start --target 10 --total-minutes 150 --platform-minutes 15
"target": 10,
"parallel": 1,
"remaining": 10,
$ python3 scripts/run.py --project projects/my-product claim pitchwall --worker worker-1 --window window-1
$ python3 scripts/record.py --project projects/my-product pitchwall live --worker worker-1 --note 'Thank-you page shown' --next-action 'Open the public listing'
Tracker rejected input: Public states require a reviewed URL and --confirmed-public
$ python3 scripts/record.py --project projects/my-product pitchwall submitted_pending_review --worker worker-1 --note 'Dashboard confirms Under Review' --next-action 'Recheck after the stated review window'
Recorded pitchwall: submitted_pending_review
$ python3 scripts/run.py --project projects/my-product status
"completed_count": 1,
"remaining": 9,Há duas coisas que vale a pena ver. O tracker recusou chamar live a uma página de agradecimento: os estados públicos precisam de um URL verificado e da tua confirmação explícita. E o registo honesto, uma submissão em revisão, fez o contador passar de 10 em falta para 9. As confirmações de receção contam para o objetivo; não precisas de esperar semanas pela publicação para saber que a tua execução avançou.
Conta com passagens pelo caminho. Quando aparece um CAPTCHA, um pedido de verificação em dois passos ou um estado de conta pouco claro, o agente mantém o rascunho aberto, regista prepared_needs_human com exatamente uma ação para ti, e o painel lista-o em «precisa de ti». Resolves na mesma janela, e a execução continua.
Passo 6: o que os estados do tracker significam
Cada resultado passa pelo record.py para o submissions.json, e o painel mostra os mesmos onze estados. Cada um exige uma observação mínima, por isso um resultado não pode ser inflacionado. Só quatro deles fazem avançar o contador da execução:
| Estado | Observação mínima | Conta para o objetivo da execução |
|---|---|---|
draft |
Trabalho preparado, submissão final não confirmada | Não |
prepared_needs_human |
Um bloqueio específico que só tu podes resolver | Não |
submitted_pending_review |
A plataforma confirmou a receção; moderação pendente | Sim |
queued |
A plataforma confirmou uma posição na fila | Sim |
scheduled |
Uma data confirmada igual ou posterior à tua data mínima de lançamento | Sim |
live |
URL público verificado mais a tua confirmação | Sim |
already_listed |
Uma listagem pública já existente, mesma prova que live | Não |
blocked |
Elegibilidade, limite da conta ou um facto em falta | Não |
deferred_paid |
A única via utilizável custa dinheiro; nada foi comprado | Não |
not_a_fit |
Os critérios de público ou de listagem não encaixam | Não |
unavailable |
A via não pode ser usada neste momento | Não |
Cada plataforma conta uma vez por execução, por muito que o seu estado mude depois. A entrada sobre o estado da listagem explica o vocabulário, e o guia de acompanhamento de envios trata casos-limite como uma caixa de parceiro que promete um segundo site.
Passo 7: deixar um espaço de trabalho retomável
No fim de uma sessão, o agente só marca itens do onboarding para verificações 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, tua ou de outro agente, lê primeiro o tracker: passagens, lançamentos agendados que já pedem verificação, e depois revisões pendentes cuja janela já passou. Volta a verificar os registos existentes em vez de submeter duas vezes.
É esse o verdadeiro ganho. O teu segundo produto reutiliza a configuração do browser, a identidade, o padrão de permissões e os 299 playbooks ativos do snapshot do catálogo de 24 de setembro de 2026; só o product.json e os textos são novos.
Para onde ir a seguir
Como funciona mostra os passos com o vídeo do fundador. O catálogo de diretórios deixa-te ler alguns guias práticos públicos antes de decidires, e o changelog lista cada versão do toolkit. Queres que o Claude Code também escreva textos de marketing? Compara as skills de Claude Code para marketing. Os outros agentes estão nas páginas de agentes. O repositório em si compra-se uma vez, na página de preço.
Perguntas frequentes
O Claude Code consegue submeter o meu SaaS a diretórios sozinho?
Em grande parte, sim. Com o repositório, um Chrome ligado e as tuas permissões, o Claude Code lê cada playbook, preenche o formulário e regista o resultado. Tu aprovas os textos, confirmas as listagens públicas e resolves CAPTCHA ou pedidos de verificação em dois passos quando a execução faz uma pausa à tua espera.
Preciso do Claude Code CLI, ou a aplicação de desktop também serve?
O repositório recomenda a CLI num terminal para melhores resultados, e o prompt inicial di-lo. A aplicação de desktop não está bloqueada: se ficares por lá, o agente continua o trabalho autorizado e o progresso guardado mantém-se intacto.
Quanto tempo demora a primeira execução?
O planeador reserva 150 minutos ativos para 10 plataformas, 15 por plataforma. São limites de coordenação que pausam a execução quando atingidos, não uma promessa de velocidade, e o tempo que passas nas passagens depende das plataformas.
O que acontece quando um diretório mostra um CAPTCHA?
O agente para no desafio, mantém o rascunho aberto e regista prepared_needs_human com uma ação exata para ti. Resolves na mesma janela, e a execução continua a partir daí.
Este passo a passo funciona igual com o Codex ou o Cursor?
Sim. Os ficheiros, o tracker e a configuração do browser são os mesmos para qualquer agente que consiga ler o repositório e usar o Chrome DevTools MCP. As páginas de agentes indicam o que muda em cada ferramenta.
Fontes: START.md, ONBOARDING.md, BROWSER-SETUP.md, WEBSITE-AND-EMAIL.md, RUNBOOK.md e CHANGELOG.md no toolkit do LaunchRepo (versão 1.9.0, 29 de setembro de 2026); o prompt inicial citado literalmente; uma execução de run.py e record.py a 30 de setembro de 2026; a referência de configuração do Chrome DevTools MCP (Chrome 144 ou mais recente para --autoConnect), verificada a 30 de setembro de 2026. Não são dados números de tempo ou de resultados entre clientes, porque nenhum foi medido.