Intenção
- O problema está escrito em uma frase, com o resultado esperado. O porquê, não a solução.
- Você sabe dizer o que muda pro usuário se isso der certo.
Contexto
- Quem usa, em que situação e em que dispositivo está declarado.
- As restrições reais estão escritas: acessibilidade, idioma, estado de erro, estado vazio.
Decisões já tomadas
- O que NÃO está em aberto está escrito: design system, tom de voz, padrões do produto.
- Tudo que você deixou em aberto, você aceita que o agente decida. Se a resposta é não, volta pro item 5.
Critérios de aceite
- Cada critério é checável: um teste, um screenshot, um número. Nenhum é opinião.
- Você sabe como vai verificar ANTES de ver o resultado, não depois.
Fora de escopo
- O que este pedido não cobre está explícito.
- Todo "depois a gente vê" virou item escrito de fora de escopo, não silêncio.
Buracos
- Você pediu ao agente as perguntas que ele faria antes de construir.
- Respondeu cada uma, atualizou a especificação e só então autorizou a construção.
Falhou em três ou mais? Não é falta de talento, é falta de método. O guia de Specification Literacy explica o raciocínio por trás de cada bloco. E se quiser o agente conduzindo o processo, conecte os métodos via MCP e peça o método de especificação executável.