---
name: design-interview
description: Entrevistar e tensionar uma ideia de produto, UI, UX, CLI/TUI ou design antes de escrever brief, PRD ou Tech Spec. Use quando o usuário pedir para desafiar a ideia, "grill me", stress-test, clarear decisões, resolver tradeoffs de experiência ou quando o problema ainda estiver nebuloso.
---

# Design Interview SDD

## Objetivo

Resolver a árvore de decisões antes de gerar artefato. Pergunte só o que não puder ser descoberto no codebase, no Project Discovery, no PRD ou nos componentes/tokens existentes.

## Protocolo

1. Leia contexto disponível: Idea, PRD, Project Discovery, design brief, rotas, componentes, tokens e docs.
2. Separe fatos conhecidos, inferências e decisões em aberto.
3. Faça perguntas por dependência, não por checklist solto.
4. Para cada pergunta, ofereça uma recomendação e o tradeoff.
5. Pare quando houver entendimento compartilhado suficiente para brief, PRD ou Tech Spec.

## Árvore mínima

- Usuário: quem usa, em qual contexto, com qual urgência e frequência.
- Job to be done: que progresso o usuário tenta fazer.
- Superfície: tela, fluxo, formulário, dashboard, CLI/TUI, notificação ou estado.
- Sucesso: comportamento observável, métrica e evidência.
- Conteúdo: real vs placeholder, origem dos dados, volume e crescimento.
- Risco: acessibilidade, responsividade, performance, dados sensíveis, permissão, rollback.
- Experiência: tom, densidade, prioridade visual, anti-referências e restrições.
- Implementação: stack atual, componentes existentes, tokens, dependências e comandos.

## Saída

```md
## Entendimento compartilhado
- Decisão central:
- Usuário/JTBD:
- Superfície:
- Princípios:
- Riscos:
- Perguntas resolvidas:
- Perguntas abertas:
- Próximo artefato:
```

## Regras

- Não transforme entrevista em bloqueio quando há uma hipótese razoável e reversível.
- Não pergunte o que o codebase responde.
- Não aceite preferência estética sem conectar a usuário, contexto ou restrição.
- Use `experience-design` para transformar o entendimento em handoff.
