Mapa completo dos prompts da Fábrica: quem é cada “Claude” da linha de montagem, o texto exato que cada um lê, o que a sua demo aprovada tinha e o que chegou de fato a quem programou as telas.
Você tem razão, e a causa não é o Claude ter ficado “menos criativo”. Ele foi contratado como engenheiro, com um briefing de engenheiro. A direção visual que você aprovou na demo (estilo Acolhedor, paleta, fontes, fotos, logo, saudação, hero) nunca chegou a quem escreveu as telas: das 13 cores e 2 fontes aprovadas, passaram 3 cores. A demo, o prompt que a gerou e as imagens ficaram de fora.
Na demo, o Claude trabalhou como designer, com um prompt que pede “sob medida”, fotos e revisão olhando os próprios prints. Na construção, a regra era “faça o mínimo que a tarefa pede” e “copie os padrões” de uma loja de exemplo. O resultado foi o que o prompt pediu.
Retrato do build da Peixaria até agora (status “pronto”, 14 rodadas de revisão).
Mesmo projeto, mesmo celular (390 px), mesmo dado de origem. À esquerda a demo Acolhedor aprovada; à direita o app em produção hoje.




O app funciona: login, carrinho, pedido e painel passaram nos portões. O que falta é exatamente o que nenhum portão mede: identidade, imagem e acabamento.
A Fábrica não é um Claude único: são várias chamadas, cada uma com um prompt próprio. Em laranja, onde o Claude é chamado; em grafite, código comum que decide e confere.
O lead conversa com o Pixios (Haiku 4.5), escolhe o estilo e aprova a demo. Sai uma spec em JSON: negócio, perfis, funcionalidades, regras e identidade visual (direção, fontes, paleta de 13 cores).
Uma única chamada, sem ferramentas. Recebe a spec e devolve o manifesto (papéis, tabelas, endpoints, páginas, fluxos), os textos de navegação nos 3 idiomas e a divisão em módulos. Não escreve código.
Código puro transforma o contrato em tarefas ordenadas: schema, seed, api, uma pagina por tela e integracao por módulo. Aqui nasce o texto de cada tarefa (descrição, critérios, arquivos permitidos).
Claude Code com Read, Write, Edit e Bash numa cópia isolada do projeto. Lê o GUIA.md inteiro (30 KB) e a tarefa. Só pode alterar os arquivos permitidos; o resto é desfeito.
Verificam sintaxe, i18n, segredos, API, telas, formulários, macaco aleatório, papéis, visual (medido), segurança e desempenho. Reprovou, a tentativa volta ao trabalhador com o relatório do erro.
Com tudo pronto, os 9 portões rodam no projeto inteiro. Cada achado vira uma tarefa de correção, que volta ao trabalhador. No build da Peixaria foram 14 rodadas e 49 tarefas de correção.
Configuração real da tabela motores e do build.
| Papel | Modelo | Esforço | Ferramentas | Recebe | Devolve |
|---|---|---|---|---|---|
| Planejador | claude-sonnet-5-5 (assinatura) | high | nenhuma | System de 21 KB + spec em JSON | JSON: manifesto, i18n, módulos |
| Trabalhador | claude-sonnet-5-5 (assinatura) | medium | Read, Write, Edit, Bash (lista segura) | System de 2 KB + texto da tarefa + GUIA.md que ele mesmo lê | Arquivos do projeto + relatorio.json |
| Revisor / visão | previsto, sem motor injetado | — | — | Prints + checklist de 5 itens | Nunca chamado neste build |
Parâmetros do trabalhador no Claude Code: --system-prompt substituindo o padrão, --permission-mode dontAsk, --disable-slash-commands, --strict-mcp-config. Sem skills, sem MCP, sem rede, sem gerador de imagem.
Decide o que existe no app. Recebe a spec inteira (incluindo a identidade visual) e devolve o contrato. É a única chamada que enxerga a direção visual, e só a usa para escolher 3 cores.
O exemplo de manifesto é uma loja de exemplo. É o modelo que o Claude imita para desenhar a Peixaria.
Fim da identidade visual no contrato: 3 cores e o tema claro. Fontes, direção, ilustração e imagens não têm campo no manifesto.
É quem escreve cada tela, API, migration e seed. Cada execução monta duas peças: o system (fixo, igual para todas as tarefas) e o texto da tarefa (gerado a partir do contrato). Mais o GUIA.md, que o system manda ler inteiro.
O GUIA ensina estrutura de arquivos, manifesto, rotas, SQL, i18n e data-testid. Das 365 linhas, as que tocam em aparência são o parágrafo de “Tema, cores e tamanhos” (só tokens, nunca hex) e a regra de imagens (WebP leve).
Texto literal de trabalhador-prompt.js. Tudo que não está aqui, o agente não sabe.
Montado por tarefaTexto() a partir do contrato. Abaixo, a mensagem exata que o Claude recebeu para escrever a tela do carrinho (gerada agora com o plano real do build).
ativos/** está permitido, mas nenhuma instrução diz o que colocar ali, e o agente não tem como gerar imagem.A spec aprovada do projeto (tabela builds.spec) lista tudo abaixo. Cada linha mostra se o item sobreviveu até o prompt que escreve as telas.
| Item da spec / da demo | Valor aprovado | Planejador | Trabalhador de tela |
|---|---|---|---|
| Nome do app | Peixaria do Batata | recebeu | recebeu |
| Funcionalidades aprovadas | 14 itens (catálogo, kg/un/embalagem, cupons, Pix…) | recebeu | só via contrato (endpoints, páginas) |
| Cores | 13 (marca, marca-clara, marca-escura, chip, borda, cartão-aconchego…) | recebeu | só 3: fundo, texto, primária |
| Fontes | Nunito, Plus Jakarta Sans | recebeu | não chegou (a base usa Sora nos títulos) |
| Direção de estilo | “ACOLHEDOR: caloroso e humano, cantos 16 a 24 px, ilustrações em SVG, saudação pessoal, cartões com respiro” | recebeu | não chegou |
| Regra “Visual fiel à demo aprovada” | campo regras da spec | recebeu | não chegou |
| HTML da demo aprovada | HTML único com 3 telas e dados realistas | não recebeu | não recebeu |
| Prints da demo | celular e PC | não recebeu | não recebeu |
| Fotos geradas (hero, peixes, camarão) | geradas por IA, em WebP | não recebeu | pasta ativos/ vazia |
| Logo (claro e escuro) | peixe verde da marca | não recebeu | não recebeu |
| Saudação, hero, chips de categoria | presentes na demo | não recebeu | não recebeu |
“Recebeu” quer dizer: o texto está no prompt daquela chamada. Verificado em planejador-prompt.js, trabalhador-prompt.js e planejador-tarefas.js.
A demo e a construção usam o mesmo modelo. O que muda é o briefing. Frases literais dos dois prompts:
flow/demos.js · resultado: o que você aprovoutrabalhador-prompt.js · resultado: o app de hojeSete causas, da que mais pesa para a que menos pesa. Todas verificadas no código; nenhuma depende de “o modelo piorou”.
A spec aprovada tem direção, fontes, 13 cores e a regra “visual fiel à demo”. O manifesto só tem campo para 3 cores. O prompt de tela herda do manifesto, não da spec. A demo em si (HTML, prints, imagens) não entra em nenhuma tarefa.
planejador-tarefas.js monta a tarefa só do contrato; tarefaTexto() usa projeto.cores e projeto.descricao.“Faça o mínimo”, “não invente” e “copie os padrões” são boas regras para API e banco. Aplicadas a uma tela, elas produzem a tela mais simples que cumpre o contrato. Ninguém pediu uma tela bonita, então ela não foi feita.
trabalhador-prompt.js, linhas das regras duras.Só tokens semânticos, só 33 ícones, só os componentes de @pixios/ui, fonte de título fixa (Sora), proibido hex e CSS próprio fora dos tokens. Qualquer app construído ali tende a parecer a mesma loja de exemplo com outra cor. Nunito, pedida na demo, não existe na base.
base/web/src/styles.css.O agente não tem rede nem gerador de imagem, e a pasta ativos/ começa vazia. O seed grava foto nula e a tela mostra um ícone cinza. A demo tinha fotos reais porque a etapa da demo gera as imagens antes de desenhar; a construção não repete essa etapa.
repo/ativos vazio no build; prints do app acima.G6 mede diferença de pixel, tela em branco e texto cortado. O julgamento por IA (checklist de hierarquia, espaçamento, “cara de SaaS profissional”) só roda se uma função de visão for injetada, e nada injeta. Mesmo ligado, reprovação dele vira P2 e nunca bloqueia.
motorVisao em todo o api/src: só definido, nunca passado. G6 achou 2 itens no build inteiro.62% das execuções foram correção de defeito (macaco aleatório, memória, G4, G7, G8). Cada ciclo reforça “não quebre nada”. As telas, escritas uma vez, só foram tocadas de novo para consertar falha de teste, nunca para melhorar a aparência.
correcao; 13 de pagina.O trabalhador roda em medium. Cada tela tem em média ~9 mil tokens de saída e uma única tentativa. É o desenho certo para CRUD; para composição visual é pouco.
motores (sonnet-medio) e execucoes (13 telas, 121 mil tokens de saída).Tokens de saída por tipo de tarefa neste build (total 1,24 milhão). Telas ficaram com 10%; correções, com 44%.
Preço de tabela por tipo: correção US$ 53,10; integração US$ 38,22; telas US$ 9,30. Pelo motor de assinatura o custo real foi zero. Melhorar as telas custaria pouco: as 13 do app inteiro valem cerca de US$ 9 por passada.
Proposta, ainda nada alterado no código. Em ordem de impacto sobre o que você viu na tela.
Salvar o HTML, os prints e as imagens da demo no projeto. Cada tarefa de tela recebe o trecho da demo daquela tela e os prints para abrir com Read, com a ordem “reproduza este visual”.
Novo bloco identidade (direção, paleta de 13 cores, fontes, tom) copiado da spec e anexado ao texto das tarefas de tela e de correção visual.
Uma tarefa nova (T00): aplica paleta e fontes da demo no tema do projeto, coloca logo e imagens em ativos/ e define a casca (cabeçalho, saudação, chips). As telas já nascem sobre isso.
Reaproveitar as fotos da demo e gerar as que faltam com genimg (cerca de US$ 0,04 por foto) antes do seed. O seed passa a gravar a foto de cada produto, com nomes variados.
Manter o engenheiro para schema, seed e API. Para pagina, um system de designer-engenheiro: autoriza composição, ilustração e polimento, mantém o contrato e os testids.
Injetar o motor de visão no G6, comparar cada tela com o print da demo e fazer reprovação de fidelidade bloquear (hoje seria P2 e passaria). Uma passada de polimento por tela, com esforço high, custa em torno de US$ 9 de tabela.
Mais ícones e componentes (hero, chip de filtro, seletor de peso com mais e menos, galeria). Aqui entra a biblioteca de componentes que você ainda não me indicou.
Posso começar por 1, 2 e 4 na própria Peixaria (refazer as telas sobre a demo, com fotos) e, se ficar do jeito certo, transformar em padrão da Fábrica. Diga por onde seguir.