Prompts de IA para produto e design

Contexto
Objetivo do produto: [objetivo]
Escopo da decisão: [tela, fluxo ou serviço]
Fontes disponíveis: [arquivos, links, pesquisas, métricas e testes]
Restrições conhecidas: [prazo, stack, acessibilidade, segurança e marca]

Tarefa
Antes de propor interface, examine apenas as fontes fornecidas. Localize rotas, componentes, tokens, padrões equivalentes, decisões registradas e testes relevantes. Separe o que está confirmado, o que está desatualizado e o que continua desconhecido.

Formato de saída
Entregue uma tabela com: afirmação, evidência exata, status, possibilidade de reuso e risco. Depois liste as perguntas que precisam de resposta antes de desenhar.

Critérios de conferência
Cada afirmação deve apontar para um arquivo, linha, URL ou trecho da pesquisa. Marque inferências como inferência. Não proponha solução enquanto houver uma lacuna que possa mudar o escopo.

Contexto
Decisão que a pesquisa precisa informar: [decisão]
Perfil de recrutamento: [critérios, sem criar persona fictícia]
Comportamento a investigar: [situação ou tarefa]
O que a equipe já sabe: [evidências]
O que ainda é hipótese: [hipóteses]

Tarefa
Monte um roteiro de 45 minutos que recupere episódios reais. Comece pelo último caso vivido, aprofunde ações, obstáculos, alternativas e consequências. Evite apresentar a solução ou pedir que a pessoa preveja o futuro.

Formato de saída
Organize em abertura, aquecimento, bloco principal, sondagens opcionais e fechamento. Para cada pergunta, informe qual decisão ela ajuda a tomar e qual viés deve ser evitado.

Critérios de conferência
Nenhuma pergunta pode sugerir a resposta, pedir elogio à ideia ou misturar dois assuntos. O roteiro precisa caber no tempo e conter uma pergunta de consentimento para gravação quando aplicável.

Contexto
Pergunta de pesquisa: [pergunta]
Transcrições ou notas: [cole o material com identificadores anônimos]
Segmentos relevantes: [segmentos]
Limites da amostra: [quantidade, recrutamento e lacunas]

Tarefa
Identifique comportamentos, necessidades, atritos e estratégias de contorno presentes no material. Agrupe apenas ocorrências comparáveis. Mantenha observação, interpretação e hipótese em campos separados.

Formato de saída
Crie uma tabela com: padrão, participantes, evidência textual curta, frequência na amostra, impacto observado, confiança e pergunta em aberto. Termine com até cinco implicações para decisão de produto.

Critérios de conferência
Não invente citação, frequência ou causa. Toda citação deve manter o identificador da origem. Se uma conclusão vier de uma pessoa só, sinalize caso isolado.

Contexto
Decisão de produto: [decisão]
Trechos de pesquisa: [notas ou transcrições]
Alternativas usadas hoje: [ferramentas, pessoas ou processos]
Resultado que aparece nas falas: [resultado, se houver]

Tarefa
Derive possíveis Jobs to Be Done apenas do material fornecido. Para cada job, diferencie situação, motivação e resultado esperado. Aponte quando os dados não sustentarem alguma parte.

Formato de saída
Use a frase "Quando [situação], quero [motivação], para [resultado]". Acrescente evidência de origem, alternativa atual, frequência na amostra e grau de confiança.

Critérios de conferência
Não crie idade, profissão, personalidade ou citação. Jobs sem evidência para situação e resultado devem ficar marcados como hipótese a validar.

Contexto
Função proposta: [descrição]
Dados coletados, inferidos e compartilhados: [lista]
Momento e texto do consentimento: [fluxo]
Público e contexto de uso: [público]
Controles disponíveis: [ver, corrigir, exportar, apagar e revogar]

Tarefa
Analise onde a proposta pode gerar recusa, perda de confiança ou abandono. Considere surpresa na coleta, necessidade real dos dados, assimetria de controle, linguagem ambígua e recuperação após erro.

Formato de saída
Entregue uma tabela com: cenário, dado envolvido, dano possível, sinal para o usuário, gravidade, mitigação e forma de verificar. Separe risco confirmado de risco hipotético.

Critérios de conferência
Não atribua medo ou resistência a um público sem pesquisa. Cada mitigação deve reduzir um risco descrito e indicar como a equipe saberá se funcionou.

Contexto
Projeto: [descrição]
Decisões já tomadas: [lista]
Pessoas envolvidas e suas responsabilidades: [lista]
Evidências disponíveis: [pesquisa, métricas e suporte]
Restrições conhecidas: [negócio, tecnologia, operação e prazo]

Tarefa
Prepare o kickoff para descobrir quais decisões ainda estão abertas, quem decide cada uma e qual evidência será aceita. Inclua perguntas sobre resultado esperado, público afetado, comportamento atual, dependências e limites do escopo.

Formato de saída
Organize as perguntas por decisão. Para cada uma, indique motivo, pessoa que pode responder, evidência esperada e consequência de ficar sem resposta.

Critérios de conferência
Remova perguntas cerimoniais ou repetidas. Nenhuma pergunta pode usar "melhor experiência" ou "mais engajamento" sem pedir uma definição observável.

Contexto
Objetivo da jornada: [resultado buscado pela pessoa]
Início e fim do recorte: [eventos]
Pesquisa disponível: [trechos identificados]
Canais e responsáveis: [lista]
Métricas ou chamados relacionados: [dados]

Tarefa
Reconstrua a jornada com base no material fornecido. Mostre o que a pessoa tenta fazer, o que o sistema faz, onde há troca de canal e onde aparecem espera, retrabalho, abandono ou pedido de ajuda.

Formato de saída
Crie uma tabela com: etapa, ação, objetivo, evidência, canal, estado do sistema, emoção observada ou inferida, atrito, responsável e oportunidade.

Critérios de conferência
Marque emoção inferida como inferência. Não preencha etapa sem evidência. Toda oportunidade deve apontar para um atrito e para a equipe capaz de agir.

Contexto
Fluxo atual: [passos e estados]
Regras de negócio: [regras]
Dependências externas: [serviços, permissões e dispositivos]
Dados persistidos: [o quê, onde e por quanto tempo]
Riscos conhecidos: [lista]

Tarefa
Mapeie falhas plausíveis em entrada, validação, processamento, retorno e persistência. Inclua interrupção, repetição de ação, resposta atrasada, perda de conexão, permissão negada, dado inconsistente e retorno pelo botão Voltar quando forem aplicáveis.

Formato de saída
Entregue uma tabela com: gatilho, estado anterior, resposta do sistema, mensagem, ação disponível, recuperação, dado preservado, telemetria e teste de aceite.

Critérios de conferência
Não liste falha sem comportamento de recuperação. Verifique que repetir uma ação não cause efeito duplicado e que nenhum estado deixe a pessoa sem próximo passo.

Contexto
Mudança lançada: [descrição e data]
Métrica observada: [definição, valor anterior e atual]
Segmentos e tamanho da amostra: [dados]
Eventos instrumentados: [eventos]
Mudanças simultâneas ou fatores externos: [lista]

Tarefa
Gere hipóteses concorrentes para explicar o sinal. Para cada hipótese, mostre a evidência a favor, a evidência ausente, uma explicação alternativa e o teste menos custoso capaz de diferenciá-las.

Formato de saída
Use uma tabela com: hipótese, mecanismo esperado, evidência atual, confiança, teste, métrica principal, métrica de proteção e critério para decidir.

Critérios de conferência
Não trate variação como causalidade. Declare limitações de amostra e instrumentação. Cada teste deve poder refutar a hipótese e ter um resultado decisório explícito.

Contexto
Problema observado: [evidência]
Público afetado: [segmento confirmado]
Objetivo do negócio: [objetivo]
Capacidades e restrições: [lista]
Alternativas atuais: [como o problema é resolvido hoje]
Horizonte da decisão: [período]

Tarefa
Escreva um rascunho de estratégia que conecte problema, escolha e consequência. Separe evidência, inferência e hipótese. Mostre os conflitos que a equipe precisa resolver, não apenas uma direção favorita.

Formato de saída
Entregue: diagnóstico, resultado desejado, público prioritário, proposta de valor, escolhas, coisas que não faremos, riscos, métricas, sinais de parada e perguntas em aberto.

Critérios de conferência
Toda escolha deve responder a uma evidência ou restrição. Não invente tamanho de mercado, prazo, vantagem competitiva ou reação de usuário. Se faltar informação decisiva, marque [VERIFICAR].

Contexto
Tarefas prioritárias: [lista com evidência]
Inventário de conteúdo e funções: [lista]
Estrutura atual: [URLs ou árvore]
Papéis e permissões: [lista]
Restrições de URL, SEO ou plataforma: [lista]

Tarefa
Proponha uma arquitetura de informação que permita concluir as tarefas prioritárias com rótulos compreensíveis. Identifique conteúdo duplicado, página órfã, dependência de permissão e conflito entre modelo mental e estrutura interna.

Formato de saída
Entregue uma árvore de até três níveis com rótulo, URL sugerida, tarefa atendida, conteúdo principal, permissão e origem na estrutura atual. Depois liste mudanças e riscos de migração.

Critérios de conferência
Cada item deve atender uma tarefa ou requisito identificado. Não crie categoria para um único item sem justificativa. Mantenha URLs existentes quando a troca não trouxer benefício demonstrável.

Contexto
Tarefa da pessoa: [tarefa]
Entrada e saída da tela: [origem e próximo passo]
Dados disponíveis: [campos e exemplos reais]
Ações e permissões: [lista]
Componentes existentes: [biblioteca ou padrões]
Dispositivos prioritários: [larguras ou contexto]

Tarefa
Descreva o wireframe em ordem de leitura. Para cada região, informe conteúdo, componente, ação, dependência de dados e comportamento responsivo. Inclua estados que mudam a decisão da pessoa.

Formato de saída
Use uma lista numerada de regiões. Depois acrescente uma matriz para padrão, carregando, vazio, erro, sem permissão e sucesso, com mensagem, foco e ação de recuperação.

Critérios de conferência
Todo dado deve ter origem e todo controle deve ter resultado. A ordem visual e a ordem do teclado precisam continuar coerentes no menor viewport indicado.

Contexto
Fluxo: [descrição]
Estados conhecidos: [lista]
Eventos: [ações da pessoa, sistema e tempo]
Dados persistidos: [lista]
Regras de negócio e permissões: [lista]
Comportamento esperado ao recarregar ou voltar: [descrição]

Tarefa
Modele a máquina de estados. Encontre transições impossíveis, eventos sem destino, estados sem saída e efeitos que podem ocorrer duas vezes. Inclua interrupção e retomada quando fizerem parte do uso.

Formato de saída
Entregue uma tabela com: estado atual, evento, pré-condição, próximo estado, efeito colateral, dado salvo, mensagem, foco e recuperação. Acrescente um diagrama textual e casos de teste.

Critérios de conferência
Cada evento deve ter um resultado definido. Recarregar, repetir e voltar não podem produzir estado falso ou duplicar ação irreversível. Marque regra ausente como [VERIFICAR].

Contexto
Componente ou tela: [descrição]
Tarefa principal: [tarefa]
Dados e dependências: [fontes]
Ações disponíveis: [lista]
Padrões existentes: [componentes e tokens]

Tarefa
Mapeie os estados que realmente podem ocorrer: inicial, preenchido, carregando, vazio, sucesso, erro de validação, erro do serviço, offline, sem permissão, indisponível e desabilitado. Ignore os que não se aplicarem e justifique.

Formato de saída
Crie uma tabela com: estado, gatilho, conteúdo visível, controle disponível, foco, anúncio para tecnologia assistiva, dado preservado e recuperação.

Critérios de conferência
Nenhum estado pode depender apenas de cor, apagar entrada sem aviso ou terminar sem ação possível. Mensagens devem explicar o que ocorreu e o que a pessoa pode fazer agora.

Contexto
Objetivo do formulário: [objetivo]
Campos, tipos e obrigatoriedade: [lista]
Regras de validação: [regras]
Dados sensíveis: [lista]
Componente ou stack existente: [descrição]

Tarefa
Especifique a estrutura semântica e o comportamento por teclado e leitor de tela. Defina rótulos persistentes, instruções antes do campo, autocomplete quando aplicável, validação no momento adequado, resumo de erros e foco após envio.

Formato de saída
Entregue uma tabela por campo e um fluxo de envio. Inclua nome acessível, tipo, autocomplete, ajuda, erro, associação semântica, ordem de foco e comportamento após sucesso ou falha.

Critérios de conferência
Todo campo deve ter rótulo programático e instrução compreensível. Erro não pode depender só de cor. Após falha, a pessoa precisa localizar o problema sem perder os valores já preenchidos.

Contexto
Tokens de cor em hexadecimal: [lista]
Combinações em uso: [texto, fundo, borda, ícone e estado]
Tamanho e peso do texto: [valores]
Tema claro e escuro: [combinações]
Paleta permitida: [restrições]

Tarefa
Calcule a relação de contraste de cada combinação e compare com os critérios aplicáveis da WCAG 2.2. Só proponha ajuste quando houver falha. Preserve a paleta permitida e a função semântica do token.

Formato de saída
Entregue uma tabela com: primeiro plano, fundo, uso, relação calculada, critério, resultado e substituição permitida. Mostre também as combinações de foco e estados interativos.

Critérios de conferência
Não estime contraste pela aparência. Informe os valores usados no cálculo para repetição em outra ferramenta. Marque qualquer combinação sem cor de fundo conhecida como [VERIFICAR].

Contexto
Tarefa dentro do modal: [tarefa]
Conteúdo e ações: [lista]
Elemento que abre o modal: [controle]
Componentes existentes: [biblioteca]
Viewports e dispositivos: [contexto]

Tarefa
Escreva o contrato do modal com uso e não uso, anatomia, abertura, fechamento, foco inicial, contenção de foco, Escape, retorno do foco, rolagem, fundo inerte e comportamento responsivo.

Formato de saída
Entregue: regras de uso, estados, sequência de teclado, nomes acessíveis, responsabilidades do componente, responsabilidades de quem o consome e testes de aceite.

Critérios de conferência
O título precisa nomear o diálogo. O teclado não pode alcançar o conteúdo atrás enquanto o modal estiver aberto. Ao fechar, o foco deve voltar ao controle de origem, salvo quando ele não existir mais.

Contexto
Tela ou screenshot a revisar: [anexo]
Tokens e componentes canônicos: [arquivos ou links]
Telas equivalentes aprovadas: [referências]
Viewports obrigatórios: [larguras]
Vetos e limites visuais: [regras]

Tarefa
Compare a tela com as fontes fornecidas. Examine hierarquia, tipografia, cor, espaço, grade, estados, densidade, responsividade e foco. Diferencie divergência comprovada de julgamento que exige inspeção visual.

Formato de saída
Liste os achados por severidade. Para cada um, informe elemento, evidência canônica, efeito no uso e correção mínima. Marque como [VERIFICAR VISUALMENTE] o que a fonte não comprovar.

Critérios de conferência
Não proponha fonte, cor, componente ou padrão fora do sistema. Inclua evidência para tema claro e escuro e para o menor e o maior viewport indicados.

Contexto
Hipótese a testar: [hipótese]
Pessoa e tarefa: [quem e o que precisa fazer]
Cenário do teste: [início, dados e fim]
Stack ou ferramenta: [restrições]
Componentes disponíveis: [lista]
O que não faz parte: [fora do escopo]

Tarefa
Implemente um protótipo navegável que permita testar a hipótese. Priorize o caminho e os estados necessários para a tarefa. Use dados fictícios identificados como fictícios e não conecte serviço externo sem autorização.

Formato de saída
Entregue os arquivos alterados, instruções para executar, cenário de teste e limitações conhecidas. Inclua padrão, carregando, vazio, erro e sucesso quando fizerem parte do fluxo.

Critérios de conferência
A tarefa precisa ser concluída por teclado e no menor viewport indicado. O protótipo deve responder à hipótese sem simular como pronta uma integração inexistente.

Contexto
Objetivo da mudança: [resultado]
Comportamento atual e esperado: [descrição]
Reprodução do problema: [passos]
Arquivos ou rotas relevantes: [caminhos]
Stack, convenções e testes: [fontes]
Limites: [sem nova dependência, sem alterar API, ou outros]

Tarefa
Leia as fontes e reproduza o comportamento antes de editar. Faça a menor mudança que resolve o caso. Reuse componentes e tokens existentes. Se o pedido conflitar com o sistema atual, apresente a evidência e pare antes de ampliar o escopo.

Formato de saída
Informe causa, arquivos alterados, decisão técnica, teste adicionado e comando de verificação. Mostre qualquer risco que permaneça.

Critérios de conferência
O teste deve falhar antes da correção e passar depois quando houver defeito reproduzível. Não altere teste para esconder regressão. Não adicione abstração ou dependência sem necessidade comprovada.

Contexto
Mudança feita: [descrição]
Critérios de aceite: [lista]
Comandos do projeto: [testes, lint e servidor]
Fluxos críticos: [passos]
Viewports e temas: [lista]
Limites de acesso: [o que não pode ser verificado]

Tarefa
Verifique a mudança a partir de um estado limpo. Rode os comandos obrigatórios e percorra os fluxos no navegador. Teste teclado, foco, recarga, Voltar, erro, tema e responsividade quando forem relevantes.

Formato de saída
Entregue uma tabela com: critério, método, comando ou passos, resultado e evidência. Separe passou, falhou e não verificado. Inclua o primeiro erro útil de qualquer falha.

Critérios de conferência
Não chame configuração de prova. Não use resultado antigo. Só declare concluído quando todos os critérios obrigatórios tiverem evidência recente ou uma limitação estiver explicitamente marcada.

Contexto
Frame, protótipo ou screenshot: [link ou anexo]
Objetivo e tarefa principal: [descrição]
Pesquisa e conteúdo real: [fontes]
Repositório e convenções: [arquivos]
Estados e viewports aprovados: [lista]
Questões ainda abertas: [lista]

Tarefa
Leia as fontes antes de implementar. Explique a intenção que precisa sobreviver no código: prioridade de leitura, ação principal, regras de estado, adaptação entre viewports, comportamento de teclado e relação com o sistema existente.

Formato de saída
Entregue um brief com: objetivo, hierarquia, componentes reutilizados, dados, estados, interação, responsividade, acessibilidade, riscos e dúvidas que bloqueiam a implementação.

Critérios de conferência
Cada decisão deve apontar para uma fonte ou estar marcada como hipótese. Não infira interação a partir de screenshot estático. Não escreva código até resolver uma dúvida que possa mudar estrutura ou comportamento.

Contexto
Arquivo e nós do Figma: [links]
Ferramentas disponíveis para leitura: [lista]
Arquivos de tokens no repositório: [caminhos]
Convenção de nomes: [fonte]
Temas e modos: [lista]
Escopo autorizado para edição: [limites]

Tarefa
Leia as variáveis e estilos acessíveis no Figma e compare com os tokens do código. Registre correspondência exata, diferença de valor, alias, modo ausente e uso sem token. Se a ferramenta não expuser algum dado, marque como não verificado.

Formato de saída
Entregue uma tabela com: origem no Figma, coleção e modo, valor, token no código, status, consumidores e ação proposta. Separe correção segura de decisão que exige o dono do sistema.

Critérios de conferência
Não extraia valor por aproximação visual quando houver variável. Não crie token novo para contornar uma divergência sem explicar o uso. Nenhuma escrita no Figma ou no código sem autorização explícita.

Contexto
Diretório autorizado: [caminho]
Objetivo original: [objetivo]
Fontes de estado: [plano, notas, testes e histórico Git]
Mudanças que podem estar em andamento: [arquivos ou agentes]
Ações proibidas: [lista]

Tarefa
Antes de continuar, confirme o diretório, leia as fontes de estado e inspecione o diff. Reconstrua o que já foi concluído, o que foi apenas alegado e qual é o próximo passo verificável. Preserve mudanças que não forem suas.

Formato de saída
Entregue: objetivo atual, evidências concluídas, trabalho pendente, árvore suja, riscos, teste mais recente e próximo passo. Depois execute apenas o próximo passo autorizado.

Critérios de conferência
Não repita trabalho já comprovado. Não descarte arquivo desconhecido. Não use resumo anterior como prova quando o repositório ou o ambiente puderem ter mudado.

Contexto
Biblioteca de componentes: [link ou caminho]
Tokens e documentação: [fontes]
Código de produção que consome o sistema: [caminhos]
Testes e exemplos: [fontes]
Agente e ferramentas disponíveis: [descrição]

Tarefa
Audite se um agente consegue descobrir, escolher e usar o sistema sem depender de conhecimento implícito. Verifique nomes semânticos, propósito, propriedades, variantes, estados, exemplos, acessibilidade, vínculo entre design e código e forma de validar o resultado.

Formato de saída
Entregue achados por severidade com evidência exata, efeito na decisão do agente e correção mínima. Inclua uma tarefa de teste e o resultado esperado para medir a documentação.

Critérios de conferência
Não chame arquivo existente de documentação suficiente sem testar a descoberta. Diferencie ausência de dado, divergência e preferência. Qualquer nota de prontidão deve mostrar o critério usado.

Contexto
Objetivo: [por que esta tarefa existe]
Público ou sistema afetado: [quem ou o quê]
Entradas disponíveis: [dados, arquivos e links]
Restrições: [limites, regras e coisas proibidas]

Tarefa
[verbo de ação + objeto + recorte]

Formato de saída
[estrutura, ordem, tamanho e campos obrigatórios]

Critérios de conferência
[condições observáveis que definem uma resposta correta]
[evidência que deve acompanhar cada afirmação]
[como tratar informação ausente]

Antes de responder, aponte apenas a lacuna que impediria executar a tarefa. Não preencha campo ausente por suposição.

Contexto
<contexto>
<documento id="[ID]" fonte="[URL ou arquivo]">
[conteúdo]
</documento>
</contexto>

Tarefa
Pergunta: [pergunta]
Responda usando somente os documentos em contexto. Para cada afirmação factual, cite o ID e um trecho curto que a sustenta. Se os documentos divergirem, mostre a divergência. Se não houver evidência suficiente, responda "Não consta nas fontes fornecidas".

Formato de saída
Resposta direta, seguida de evidências e lacunas.

Critérios de conferência
Toda afirmação deve ser rastreável ao documento citado. Nenhuma fonte externa ou conhecimento não fornecido pode aparecer como fato.

Contexto
Categorias permitidas: [lista e definição]
Casos ambíguos conhecidos: [lista]
Texto a classificar: [entrada]

Exemplos
Inclua de três a cinco exemplos revisados no formato:
<exemplo>
<entrada>[texto realista]</entrada>
<classe>[uma categoria permitida]</classe>
<justificativa>[regra aplicada]</justificativa>
</exemplo>

Tarefa
Classifique a nova entrada usando as mesmas regras. Se nenhuma categoria servir, use [categoria de exceção definida] em vez de criar uma nova.

Formato de saída
Categoria, justificativa curta, regra aplicada e confiança baixa, média ou alta.

Critérios de conferência
Os exemplos devem cobrir casos diferentes e pelo menos um limite entre categorias. A saída só pode usar valores permitidos. Não use exemplo que contenha dado sensível real.

Contexto
Texto de origem: [conteúdo]
Esquema permitido:
{
  "nome": "string | null",
  "categoria": "valor_a | valor_b | null",
  "evidencia": "string | null"
}

Tarefa
Extraia apenas valores presentes no texto. Use null quando o campo não estiver explícito. Em "evidencia", copie o menor trecho que sustenta os demais campos.

Formato de saída
Retorne somente um objeto JSON válido com as mesmas chaves e tipos do esquema. Não use bloco de código, comentário ou chave adicional.

Critérios de conferência
A resposta deve passar em um parser JSON e no esquema definido. Cada valor não nulo precisa ser sustentado pelo trecho em "evidencia". Se a aplicação exigir garantia de esquema, configure Structured Outputs na API em vez de depender apenas deste texto.

Contexto
Decisão ou plano: [descrição]
Objetivo: [resultado]
Evidências usadas: [fontes]
Restrições: [limites]
Alternativas descartadas e motivo: [lista]
Impacto se estiver errado: [efeito]

Tarefa
Faça uma revisão adversarial. Procure premissas não comprovadas, contradições, incentivo perverso, efeito de segunda ordem, dependência frágil e explicação alternativa. Construa o argumento mais forte contra a decisão.

Formato de saída
Entregue achados por gravidade com evidência, mecanismo de falha, custo, teste que reduziria a incerteza e mudança mínima no plano.

Critérios de conferência
Não elogie antes de testar. Não invente risco sem explicar o mecanismo. Diferencie defeito demonstrado, hipótese plausível e preferência. Se o plano resistir, diga quais evidências sustentam essa conclusão.