Tempo real não é publicar às cegas

Publicar um site com Claude Code em tempo real não significa deixar o agente mandar qualquer arquivo para produção sem revisão. Significa encurtar o caminho entre pedir uma mudança, gerar os arquivos, publicar e abrir a URL final para conferir.

O fluxo fica bom quando cada etapa devolve evidência: qual Site foi alterado, qual slug foi escolhido, qual deploy terminou, qual URL abriu e o que ainda precisa de correção.

Se você ainda não conectou o servidor MCP, faça isso antes pela configuração geral ou pelo guia específico de Claude Code.

O fluxo do prompt à URL

Um fluxo prático tem cinco movimentos:

Etapa Pedido para o agente Evidência esperada
Criar Gerar ou alterar os arquivos do site Arquivos modificados e resumo do que mudou
Preparar Chamar get_context e inspecionar public/ Site ID e presença de public/index.html
Publicar Usar as file tools e chamar deploy Deploy acompanhado até estado final
Verificar Abrir a URL final Home, estilos e assets carregando
Iterar Ajustar e republicar Mesma URL atualizada ou novo slug aprovado

Esse roteiro evita dois extremos ruins: tratar o publish como uma etapa manual separada ou deixar o agente publicar sem dizer o que fez.

Prompt base para usar no Claude Code

Depois de conectar o MCP, use um prompt que combine criação, publicação e verificação:

Quero publicar este site pelo Site no Ar.


1. Chame get_context e confirme o Site.
2. Crie ou atualize os arquivos sob public/ e confirme public/index.html.
3. Publique com deploy pelo MCP do Site no Ar.
4. Slug desejado: minha-campanha
5. Depois abra a URL final e confira se a home, CSS, imagens e links principais carregam.


Se algo bloquear, explique o bloqueio e a próxima ação.

Se o conteúdo ainda não existe, acrescente o briefing antes dessas instruções. Se ele já existe, não misture redesign com deploy: peça mudanças específicas, revise o diff e publique.

O que o agente deve fazer durante o publish

O contrato de publicação tem uma sequência clara. O agente cria ou escolhe um Site, chama get_context, altera o repositório pelas file tools, inicia o deploy e acompanha o resultado.

Esse detalhe importa: as file tools trabalham diretamente no workspace do Site. Para assets grandes, prefira URLs externas; não envie bytes ou base64 no contexto do modelo.

Ao final, a resposta boa não é apenas “publiquei”. Ela deve trazer:

  • URL final;
  • slug usado;
  • arquivos alterados;
  • status do deploy;
  • observações da verificação;
  • correções pendentes, se existirem.

Como iterar sem perder o controle

O ponto forte de publicar dentro da conversa é repetir o ciclo com pouco atrito. Depois de abrir a URL, você pode pedir:

Na URL publicada, ajuste a primeira dobra para deixar o CTA mais claro.
Mantenha o mesmo Site e o mesmo slug.
Depois publique uma nova versão e confira a URL novamente.

Essa instrução evita que o agente crie um Site novo quando a intenção é atualizar o existente. Para um fluxo de campanha, isso é essencial: o link compartilhado continua o mesmo, mas os arquivos publicados recebem a nova versão.

Quando quiser comparar variações, faça o contrário: peça slugs separados e nomeie cada hipótese. Assim você não mistura teste A/B, rascunho e produção no mesmo endereço.

Limites que vale declarar no pedido

Tempo real funciona melhor quando você dá limites explícitos. Antes de publicar, diga se o agente pode:

  • escolher um slug alternativo caso o primeiro esteja ocupado;
  • trocar imagens geradas por placeholders;
  • remover páginas que não fazem parte da entrega;
  • configurar domínio próprio agora ou deixar para depois;
  • publicar mesmo com warnings não críticos;
  • aguardar sua aprovação antes do deploy.

Essas decisões parecem pequenas, mas determinam se o agente deve seguir, perguntar ou parar. Para uma entrega a cliente, por exemplo, faz sentido exigir aprovação antes de atualizar o link final. Para um rascunho interno, talvez seja melhor publicar e verificar rapidamente.

Quando não usar esse fluxo

Não use esse caminho como atalho para esconder dependências reais. Se o site precisa de variáveis secretas, banco de dados, autenticação própria, jobs ou APIs dinâmicas, trate isso como arquitetura de aplicação, não como uma página estática.

O Site no Ar é direto para HTML e assets. Ele é ótimo para landing pages, sites institucionais, protótipos navegáveis, páginas de campanha e demos estáticas. Quando o projeto cresce além disso, publique a parte estática com clareza e documente o que ainda depende de outro runtime.

Fechando a conversa com uma URL

O melhor fim para um ciclo com Claude Code não é uma lista de arquivos modificados. É uma URL pública, uma verificação curta e uma indicação clara do que foi colocado no ar.

Para chegar nesse ponto, use o fluxo completo: peça a criação, confirme a saída, publique pelo MCP e valide o resultado. O artigo Claude Code + Site no Ar: guia completo de configuração cobre a conexão inicial. O guia Como publicar um site feito no Claude Code em segundos mostra o primeiro publish. Este fluxo junta os dois para manter criação e publicação na mesma conversa.