Pixios · Fábrica · Auditoria de prompts

O que o Claude recebeu para construir a Peixaria do Batata

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.

Peixaria do Batata · 8 de outubro de 2026 · dados lidos do código e do banco de produção

Veredito curto

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.

01Em números

Retrato do build da Peixaria até agora (status “pronto”, 14 rodadas de revisão).

82tarefas: 33 de construção + 49 de correção criadas pela revisão
258execuções do Claude (cada tentativa conta uma)
13execuções escreveram telas, uma por tela, na primeira tentativa
160execuções (62%) foram correção de defeito, não construção
1,24 Mtokens de saída; 97,8 M de cache lido; 244 min de agente
US$ 113preço de tabela da API. Na assinatura, custo real zero
3 de 13cores da paleta aprovada que chegaram ao programador das telas
0linhas sobre estilo visual, fotos ou ilustração no prompt de uma tela

02O que você aprovou × o que foi construído

Mesmo projeto, mesmo celular (390 px), mesmo dado de origem. À esquerda a demo Acolhedor aprovada; à direita o app em produção hoje.

Tela inicial do cliente

Demo aprovada Início
Demo: início com logo, saudação, busca, categorias, hero e cards com foto
  • Logo e nome da marca no topo
  • Saudação pessoal e entrega do dia
  • Filtros por categoria em chips
  • Hero com foto e destaques com foto
App em produção Catálogo
App: lista de produtos sem foto, com nome repetido e filtros em campos de formulário
  • Sem logo, sem saudação, sem hero
  • Filtros viraram campos de formulário
  • Todo produto com o mesmo ícone cinza no lugar da foto
  • Mesmo nome truncado repetido três vezes

Carrinho

Demo aprovada Seu carrinho
Demo: carrinho com foto, kg com botões mais e menos, aviso de pedido mínimo e escolha de bairro
  • Foto de cada item e preço por kg
  • Peso com botões − e + (1,2 kg)
  • Aviso de pedido mínimo e bairro com taxa
App em produção Meu carrinho
App: carrinho com ícone no lugar da foto e quantidade em campo numérico mostrando 0.5
  • Sem foto; ícone genérico
  • Quantidade em campo de texto (“0.5” com ponto)
  • Nada de pedido mínimo nem bairro na tela

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.

03A linha de montagem

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.

Chamada ao ClaudeCódigo (sem IA)
1

Conversa e demo aprovada (fase 1 a 3)

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).

builds.specdemos.html (HTML único)fotos e logo gerados
2

Planejador: desenha o contrato

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.

sonnet-5-5 · esforço highsystem 21 KB
3

Gerador de tarefas

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).

planejador-tarefas.js33 tarefas
4

Trabalhador: programa uma tarefa por vez

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.

sonnet-5-5 · esforço mediumaté 4 tentativas20 min / US$ 2 por tarefa
5

Portões G0 a G8

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.

G6 visão por IA: nunca ligado
6

Revisão e correção em ciclo

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.

T34 a T82

04Quem é cada “Claude”

Configuração real da tabela motores e do build.

PapelModeloEsforçoFerramentasRecebeDevolve
Planejadorclaude-sonnet-5-5 (assinatura)highnenhumaSystem de 21 KB + spec em JSONJSON: manifesto, i18n, módulos
Trabalhadorclaude-sonnet-5-5 (assinatura)mediumRead, 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ãoprevisto, sem motor injetado——Prints + checklist de 5 itensNunca 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.

05Prompt 1: o Planejador

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 que compõe o system (21 KB)

Regras do contrato (GUIA §3)~9 KB
Manifesto de exemplo “Loja Exemplo”11,4 KB
Regras do desenho + formato~3 KB

O exemplo de manifesto é uma loja de exemplo. É o modelo que o Claude imita para desenhar a Peixaria.

O que o planejador devolveu sobre visual

"projeto": { "nome": "Peixaria do Batata", "cores": { "fundo": "#FFF8F0", "texto": "#2E2A24", "primaria": "#1F7A63" }, "tema_padrao": "claro" }

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.

Regras do desenho (trecho real do system do planejador)
# Regras do desenho - Cubra o que o cliente pediu e nada além do escopo aprovado. Pense em quem usa: um papel por perfil real, o admin enxerga tudo e configura; os demais só o que lhes cabe. Esconda custo, margem e lucro de quem não pode ver (`campos_sensiveis`). - Mobile-first: no máximo 5 itens de menu por papel (o último é a página "Mais": perfil, tema, idioma, sair). Cada papel precisa de uma página inicial (`home`) que ele possa abrir. - Tabelas com chaves estrangeiras (`referencia`), uuid como id, colunas de dinheiro em numeric, datas em timestamptz. - Todo endpoint tem `amostra` (corpo válido) quando recebe corpo, e `params_amostra` quando o caminho tem :param que não seja de uma tabela óbvia. Toda mutação tem `mutacao: true` e `tabela`. - Toda página lista seus `dados` (endpoints GET), as `acoes`, os `formularios` (campos que existem no corpo do endpoint e cobrem os obrigatórios), os `estados` (vazio, carregando, erro) e testids únicos na página. - 1 fluxo por jornada principal de cada papel (login, abrir tela, criar algo, ver o resultado). - Módulos: agrupe por assunto do negócio (3 a 8 módulos para um app médio). Cada tabela, endpoint, página e fluxo pertence a EXATAMENTE um módulo. Evite dependência circular entre as tabelas de módulos diferentes (chave estrangeira só aponta para módulo anterior na lista). Coloque os módulos em ordem de construção. - Nomes de papel "admin" para o dono do sistema. E-mails demo no domínio @demo.test, senha "Demo#12345". - O id de página "construcao" é reservado. Caminhos /auth/*, /me e /arquivos/* são da base. - Não invente integrações externas (pagamento real, e-mail, WhatsApp): se o escopo cita, modele o registro e o status no banco e deixe a integração para depois.

06Prompt 2: o Trabalhador

É 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.

Peso de cada peça numa tarefa de tela

System do trabalhador2,0 KB
Texto da tarefa (T16 carrinho)2,7 KB
GUIA.md (lido pelo agente)30,2 KB

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).

6.1 System prompt completo

Texto literal de trabalhador-prompt.js. Tudo que não está aqui, o agente não sabe.

Você é engenheiro(a) sênior num time que constrói SaaS. Você trabalha numa cópia isolada do projeto (a pasta atual) e faz UMA tarefa por vez. Primeiro leia GUIA.md inteiro: ele manda sobre como o projeto é organizado. O projeto de referência fica descrito nele; copie os padrões. Regras duras: - Altere SOMENTE os arquivos permitidos da tarefa. O que estiver fora é desfeito automaticamente e a tentativa perde. - O manifesto (pixios.manifesto.json) é o contrato: você pode ACRESCENTAR detalhes (ações, formulários, estados, amostras), nunca remover nem afrouxar o que já existe (rotas, papéis, campos sensíveis, limites, fluxos). - Não instale pacotes (npm/pnpm). Precisa de uma biblioteca? Rode ./pedir-dependencia <pacote> "<motivo>" e siga sem ela; a resposta chega na próxima tentativa. - Nada de rede externa, eval, escrita fora do projeto, segredos no código. SQL sempre parametrizado. - Todo texto visível sai de chave i18n nos 3 idiomas (pt-BR, en, es), sem emoji. Interface mobile-first, claro e escuro, estados vazio/carregando/erro. - Rode ./verificar antes de terminar e corrija tudo o que ele apontar. Ele é uma checagem rápida; a conferência completa (API, telas, cliques, segurança) acontece depois que você terminar. - Se o resultado de uma tentativa anterior citar um fluxo ou formulário que falhou, rode ./reproduzir <id> para ver a falha acontecer de verdade (passos, erro, log do servidor e print) antes de mexer no código. ./reproduzir sem argumento lista os ids. Se responder que ainda está rodando, espere com ./reproduzir --resultado. - Precisa renomear um arquivo (ex.: migration com número errado)? Use ./renomear <de> <para>; funciona só entre caminhos permitidos da tarefa. mv e rm não existem aqui. - CRUD simples (listar, ler, criar, atualizar, excluir de um recurso) usa `ctx.crud` (GUIA.md 4.1) em vez de rotas escritas à mão; escreva a mão só a regra de negócio própria. - Faça o mínimo que a tarefa pede, bem feito. Não invente funcionalidades. - Ao terminar escreva relatorio.json com { "feito": [..], "pendente": [..] } e encerre.
Papel“engenheiro(a) sênior”. A palavra design, estética ou criatividade não aparece nenhuma vez.
Referência“copie os padrões” do projeto de referência (a loja de exemplo da base).
Escopo“Faça o mínimo que a tarefa pede, bem feito. Não invente funcionalidades.”
Visual“Interface mobile-first, claro e escuro, estados vazio/carregando/erro”. É a única frase de interface.
AusenteIdentidade da marca, fotos, ilustração, logo, tom de voz, referência de demo, revisão olhando a própria tela.

6.2 Texto de uma tarefa de tela (T16: carrinho)

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).

# Tarefa T16 (pagina): pagina: carrinho Tela "carrinho" do módulo "Vitrine e carrinho": Experiência do cliente: catálogo com busca e filtros, detalhe do produto, carrinho persistido no banco, validação de cupom, conta e página Mais. ## Projeto Nome: Peixaria do Batata. E-commerce de peixes e frutos do mar com venda por kg, unidade e embalagem, entrega por bairro, pedido por WhatsApp, pagamento Pix registrado no banco e painel administrativo. Cores: {"fundo":"#FFF8F0","texto":"#2E2A24","primaria":"#1F7A63"}. Idiomas: pt-BR, en, es. ## Módulo Vitrine e carrinho: Experiência do cliente: catálogo com busca e filtros, detalhe do produto, carrinho persistido no banco, validação de cupom, conta e página Mais. ## Prefixo desta tarefa Use o prefixo `016` nos arquivos de migration e seed (veja os arquivos permitidos). ## Critérios de pronto - a página abre em `/carrinho` para cliente e usa exatamente os data-testid do manifesto - estados vazio, carregando e erro renderizados; formulários validam e mostram a mensagem do servidor; ação destrutiva pede confirmação - mobile-first, claro e escuro, alvo de toque >= 44px, sem emoji, ícones do conjunto da base - nada fica atrás do menu inferior - `./verificar` termina sem problemas graves - nenhum texto fixo na tela: tudo por chave nos 3 idiomas (pt-BR, en, es) ## Arquivos permitidos - pixios.manifesto.json - src/paginas/Carrinho.jsx - src/paginas/carrinho-*.jsx - src/paginas/carrinho/** - src/i18n/*.json - ativos/** ## Página do contrato (já no manifesto) ```json [ { "id": "carrinho", "menu": { "icone": "bag", "ordem": 2, "rotulo": "menu.carrinho" }, "rota": "/carrinho", "acoes": [ { "id": "abrir-item", "tipo": "navegar", "testid": "carrinho-item", "destino": "/catalogo/:id" }, { "id": "alterar-quantidade", "tipo": "enviar", "testid": "carrinho-quantidade", "endpoint": "carrinho-atualizar" }, { "id": "remover-item", "tipo": "excluir", "testid": "carrinho-remover", "endpoint": "carrinho-remover", "destrutiva": true }, { "id": "ir-checkout", "tipo": "navegar", "testid": "carrinho-checkout", "destino": "/checkout" }, { "id": "continuar-comprando", "tipo": "navegar", "testid": "carrinho-continuar", "destino": "/catalogo" } ], "dados": [ "carrinho-obter" ], "papeis": [ "cliente" ], "titulo": "pagina.carrinho.titulo", "estados": { "erro": "carrinho-erro", "vazio": "carrinho-vazio", "carregando": "carrinho-carregando" } } ] ```
ProjetoNome, descrição de 1 frase, 3 cores e idiomas. Nada mais sobre a marca.
CritériosTodos técnicos: testids, estados, alvo de toque, sem emoji, ícones “do conjunto da base”.
Arquivosativos/** está permitido, mas nenhuma instrução diz o que colocar ali, e o agente não tem como gerar imagem.
AusenteA demo, os prints dela, a paleta completa, as fontes, a direção “Acolhedor”, as fotos e a frase “Visual fiel à demo aprovada” que existe na spec.

07O que a spec tinha × o que chegou ao programador

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 demoValor aprovadoPlanejadorTrabalhador de tela
Nome do appPeixaria do Batatarecebeurecebeu
Funcionalidades aprovadas14 itens (catálogo, kg/un/embalagem, cupons, Pix…)recebeusó via contrato (endpoints, páginas)
Cores13 (marca, marca-clara, marca-escura, chip, borda, cartão-aconchego…)recebeusó 3: fundo, texto, primária
FontesNunito, Plus Jakarta Sansrecebeunã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”recebeunão chegou
Regra “Visual fiel à demo aprovada”campo regras da specrecebeunão chegou
HTML da demo aprovadaHTML único com 3 telas e dados realistasnão recebeunão recebeu
Prints da democelular e PCnão recebeunão recebeu
Fotos geradas (hero, peixes, camarão)geradas por IA, em WebPnão recebeupasta ativos/ vazia
Logo (claro e escuro)peixe verde da marcanão recebeunão recebeu
Saudação, hero, chips de categoriapresentes na demonão recebeunão recebeu

“Recebeu” quer dizer: o texto está no prompt daquela chamada. Verificado em planejador-prompt.js, trabalhador-prompt.js e planejador-tarefas.js.

08Dois prompts, dois resultados

A demo e a construção usam o mesmo modelo. O que muda é o briefing. Frases literais dos dois prompts:

Prompt da demo

Papel: designer de produto sênior · flow/demos.js · resultado: o que você aprovou
“Você é o designer de produto sênior do Pixios […] uma página HTML única que parece o app pronto e em uso.”
“SOB MEDIDA (o mais importante): pense no dia a dia desse negócio […] Nada de ‘Item 1’, ‘Lorem’, ‘Produto A’.”
“Fotos: use as imagens geradas sempre que o segmento pede foto […] nunca caixas cinza vazias.”
“ESTILO VISUAL: ACOLHEDOR, caloroso e humano, cantos bem arredondados, ilustrações simples em SVG, saudação pessoal no topo.”
“Rode ./tirar-prints […] Abra TODOS os prints com Read e olhe como um cliente exigente […] Corrija e rode de novo.”
Recebe o briefing do cliente: cores lidas do site, fontes, logo, concorrentes, perfis.

Prompt da construção

Papel: engenheiro sênior · trabalhador-prompt.js · resultado: o app de hoje
“Você é engenheiro(a) sênior num time que constrói SaaS […] faz UMA tarefa por vez.”
“Faça o mínimo que a tarefa pede, bem feito. Não invente funcionalidades.”
“O projeto de referência fica descrito nele; copie os padrões.”
“Use só tokens semânticos do Tailwind. Nunca hex fixo.” (GUIA.md, seção 7)
“Rode ./verificar antes de terminar.” Checagem estática: sintaxe, i18n, segredos. Nenhuma olhada na tela.
Recebe: nome, descrição, 3 cores, módulo, critérios técnicos, arquivos permitidos.

09Por que ficou sem criatividade

Sete causas, da que mais pesa para a que menos pesa. Todas verificadas no código; nenhuma depende de “o modelo piorou”.

1

O briefing visual não chega a quem desenha a tela

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.

Evidência: planejador-tarefas.js monta a tarefa só do contrato; tarefaTexto() usa projeto.cores e projeto.descricao.
2

O papel é de engenheiro, com ordens que travam a ousadia

“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.

Evidência: trabalhador-prompt.js, linhas das regras duras.
3

O design system da base é fechado e é o mesmo para todo projeto

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.

Evidência: GUIA.md seções 7 e 10; base/web/src/styles.css.
4

Sem imagens, a loja de peixe fica sem peixe

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.

Evidência: repo/ativos vazio no build; prints do app acima.
5

Nenhum portão avalia beleza, e o juiz visual nunca foi ligado

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.

Evidência: busca por motorVisao em todo o api/src: só definido, nunca passado. G6 achou 2 itens no build inteiro.
6

A revisão empurra para o mais seguro

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.

Evidência: 160 de 258 execuções são do tipo correcao; 13 de pagina.
7

Esforço médio e uma passada só por tela

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.

Evidência: tabela motores (sonnet-medio) e execucoes (13 telas, 121 mil tokens de saída).

10Onde o esforço foi gasto

Tokens de saída por tipo de tarefa neste build (total 1,24 milhão). Telas ficaram com 10%; correções, com 44%.

Correção547 mil · 160 exec.
Integração380 mil · 62 exec.
API130 mil · 13 exec.
Telas121 mil · 13 exec.
Seed50 mil · 5 exec.
Schema12 mil · 5 exec.

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.

11O que eu mudaria

Proposta, ainda nada alterado no código. Em ordem de impacto sobre o que você viu na tela.

1

Levar a demo aprovada para dentro da construção

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”.

maior ganho
2

Brief visual completo no manifesto e em toda tarefa

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.

simples
3

Tarefa de tema e identidade antes das telas

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.

médio
4

Imagens na linha de montagem

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.

médio
5

Dois perfis de trabalhador

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.

médio
6

Ligar o juiz visual comparando com a demo

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.

complementa
7

Ampliar o design system da base

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.

depende de você

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.