---
name: historias-testaveis
description: Transforma uma necessidade de produto em histórias de usuário com regras, critérios de aceite observáveis e exceções. Use no refinamento ou ao revisar uma história ambígua antes da implementação.
license: MIT
metadata:
  author: Desofts
  version: "1.0"
---
# Histórias testáveis

Escreva itens que produto, design e desenvolvimento consigam interpretar de maneira consistente.

## Entenda antes de dividir

Identifique ator, objetivo, valor, gatilho e estado final. Preserve regras confirmadas e diferencie sugestões. Se autorização, cálculo ou comportamento de erro não estiver definido, registre a dúvida; não invente política de negócio.

Divida por comportamento de ponta a ponta quando uma história contiver objetivos independentes. Não crie uma história para cada campo nem separe interface e API como se fossem valor independente por padrão. Respeite convenções do usuário quando fornecidas.

## Critérios de aceite

Cada critério deve ser verificável com uma entrada, ação ou estado e um resultado observável. Pode usar Dado/Quando/Então quando isso tornar a regra mais clara. Evite “funcionar corretamente”, “ser intuitivo” e “ter boa performance” sem definição.

Inclua caminho principal e exceções relevantes: ausência de dados, duplicidade, permissão insuficiente, estado incompatível ou falha de integração. Não aplique todas as exceções a toda história sem relação com o fluxo.

Diferencie regra de experiência (“mostrar a mensagem”) e regra de autorização (“recusar a operação”). Esconder um botão não demonstra proteção da operação.

## Entrega

Para cada história, escreva título orientado a comportamento, necessidade, contexto e critérios de aceite. Depois liste regras confirmadas, sugestões a validar e dependências. Termine com dúvidas bloqueadoras, se houver.

Faça uma leitura final como testador: há um resultado que possa ser observado para cada critério? Alguma regra aparece contraditória em duas histórias? Se sim, corrija ou sinalize.

## Exemplo

Pedido: “O gestor precisa encerrar uma solicitação.”

Não assuma que qualquer gestor pode encerrar qualquer solicitação. Pergunte ou marque a dúvida sobre escopo de acesso. Um critério possível, condicionado à regra confirmada, é: “Dada uma solicitação em andamento e um gestor autorizado, ao confirmar o encerramento, o sistema registra o estado concluído e a data da ação.”

A skill prepara conteúdo; não cria ou altera tickets em ferramentas externas sem pedido explícito.