Um prompt que pede "pesquise, projete a arquitetura, escreva o código e documente" falha por uma razão física: cada instrução compete pela mesma janela de atenção do modelo. O resultado é um trabalho mediano em quatro frentes em vez de bom em uma. Prompt chain inverte a lógica: uma tarefa por prompt, com contrato explícito entre as etapas.
Quando vale encadear (e quando não)
Encadeie quando:
- A tarefa tem etapas com dependência real: a etapa 2 precisa do resultado da etapa 1 para existir.
- Cada etapa tem critério de qualidade diferente: pesquisa exige cobertura; código exige correção; documentação exige clareza. Um prompt único aplica um padrão médio a tudo.
- O trabalho excede o que uma resposta bem feita comporta (acima de ~1500 linhas de saída, a qualidade degrada mesmo em modelos longos).
Não encadeie quando as partes são independentes ("gere 5 títulos e 3 variações de corpo") — aí basta um prompt bem estruturado com formato de saída dividido. Encadear o que não depende só adiciona fricção.
A anatomia de uma etapa
Cada prompt da cadeia segue a mesma estrutura P.C.R.F. (do nosso guia de adaptação) com um acréscimo: o contrato de entrada e saída.
- Entrada: o que esta etapa recebe da anterior — nomeado explicitamente ("recebe o documento de arquitetura gerado na etapa 1, colado abaixo").
- Tarefa única: um verbo. "Implemente", não "implemente e documente".
- Saída formatada: o formato que a próxima etapa espera. Se a etapa 2 vai consumir JSON, a etapa 1 entrega JSON — com as chaves nomeadas no prompt.
Exemplo completo: MVP de API em 4 etapas
O fluxo que usamos para validar o Boilerplate Fastify + Prisma + TypeScript do catálogo, decomposto:
- Etapa 1 — Especificação. Prompt: "A partir da descrição do produto abaixo, gere a especificação de API em JSON: endpoints (método, path), contratos de request/response, e regras de negócio. Não escreva código." Saída: um documento JSON que vira o contrato.
- Etapa 2 — Esqueleto. Prompt recebe o JSON da etapa 1: "Implemente a estrutura do projeto Fastify + Prisma + TypeScript para esta especificação. Entregue árvore de pastas, package.json e os arquivos de configuração. Código dos handlers pode ser stub." Saída: projeto que sobe com
npm run dev. - Etapa 3 — Implementação por endpoint. Um prompt por grupo de endpoints (não todos de uma vez): "Implemente os handlers do recurso X conforme o contrato, com validação zod e tratamento de erro. Mantenha as assinaturas existentes." Saída: código funcional testável.
- Etapa 4 — Revisão. Prompt recebe o código completo: use aqui o Code Reviewer Sênior do catálogo. Saída: findings com severidade e correção sugerida.
O ganho não é só qualidade — é ponto de falha localizado. Se a etapa 3 errar, você refaz a etapa 3; na abordagem monolítica, o erro contamina tudo e você recomeça do zero.
Regras práticas de cadeia
- Contrato antes de código: sempre tenha uma etapa que produza um documento verificável (especificação, arquitetura, outline) antes da etapa de produção. É o seu "revisar antes de imprimir".
- Formato estável entre etapas: JSON ou markdown com estrutura fixa. Texto livre como contrato de interface é onde cadeias quebram — a próxima etapa interpreta a saída anterior do jeito dela.
- Ponto de inspeção humana: escolha 1–2 pontos da cadeia onde você lê e aprova antes de continuar (tipicamente: após a especificação e após o review). Não precisa revisar tudo; precisa revisar nos pontos onde erro é caro de propagar.
- Número de etapas tem teto útil: acima de 6–7 etapas, a fricção de colar/sair entre prompts supera o ganho. Aí o problema não é decomposição — é que a tarefa está mal definida (volta ao erro de escopo aberto do nosso guia de erros comuns).
Cadeia para conteúdo: o caso do artigo longo
O mesmo padrão serve para escrita. Para um artigo de 3000 palavras com pesquisa:
- Pesquisa/estrutura: "gere o outline com tese por seção e as fontes de argumento" (sem escrever).
- Rascunho por seção: um prompt por 2–3 seções, recebendo o outline + a carta de voz.
- Costura e revisão: "receba as seções rascunhadas; unifique transições, elimine repetições entre seções e aplique o critério de corte da carta de voz".
O passo 3 é o que a maioria pula — e é onde artigo gerado por seção deixa de parecer "colagem". A costura é uma tarefa legítima, com prompt próprio.
Erros específicos de cadeia
- Contrato implícito: a etapa 1 entrega algo que a etapa 2 "deveria" entender. Se o formato da saída não está nomeado no prompt da etapa 1, ele não existe.
- Propagação de erro sem inspeção: um erro na especificação vira erro em todo o código. Por isso o ponto de inspeção após a etapa de contrato é inegociável.
- Cadeia por vaidade: 5 etapas para uma tarefa que cabia em 2. Cada etapa adiciona tempo e contexto perdido. Decomponha até a qualidade subir — não até o fluxo parecer impressionante.
Prompts do catálogo que funcionam bem como etapas
- Boilerplate Fastify + Prisma + TypeScript — etapa de esqueleto.
- Code Reviewer Sênior — etapa final de revisão (funciona com a saída de qualquer etapa anterior).
- Pipeline GitHub Actions + Docker — etapa de infraestrutura após o código existir.
Perguntas frequentes
O que é uma prompt chain?
Uma sequência de prompts em que a saída de uma etapa é a entrada da seguinte, cada uma com escopo e critério de aceite próprios.
Quando não vale a pena encadear?
Quando a tarefa cabe em uma especificação com critério único. Cadeias adicionam custo e pontos de falha.
Como evitar que a cadeia acumule erro?
Valide a saída de cada etapa com o critério dela antes de passar adiante, e passe adiante o artefato nomeado, não a conversa inteira.