---
name: design-flow
description: Conduzir o fluxo completo de design dentro do SDD, da entrevista ao handoff, IA, tokens, tasks, implementação e review visual. Use quando o usuário pedir design flow, fluxo completo de design, começar do zero, guiar uma feature visual ou organizar o trabalho de UX/UI antes de construir.
---

# Design Flow SDD

## Objetivo

Guiar design como subfluxo do SDD. Cada fase produz decisão ou artefato rastreável e só avança quando a fase anterior está boa o bastante.

Use `provider-compatibility` durante o fluxo: entrevista, brief, IA, tokens e tasks precisam funcionar como Markdown puro. Implementação, screenshots, browser, subagents e MCP são opcionais e devem ter fallback.

## Sequência

1. `design-interview`: clareia decisões e tradeoffs.
2. `experience-design`: gera brief e handoff de experiência.
3. `information-architecture`: define estrutura, navegação, conteúdo e fluxos.
4. `artifact-diagrams`: gera Mermaid e, quando útil ao planejamento, Excalidraw editável para fluxos, jornadas, estados ou dependências.
5. `design-tokens`: estabelece ou estende sistema visual.
6. `design-to-tasks`: quebra em fatias verticais verificáveis.
7. `frontend-design`: implementa UI usando a stack real.
8. `visual-review`: roda sob demanda quando houver algo visível.

## Quando pular fases

- Ideia já está clara: pule `design-interview`.
- Componente isolado: pule `information-architecture`, mas ainda registre estados.
- Projeto já tem tokens sólidos: use `design-tokens` só para mapear lacunas.
- Sem frontend ou UI renderizável: substitua `frontend-design` por handoff de experiência para CLI/API/docs.
- Review só roda automaticamente se o usuário pedir ou se o checkpoint/merge exigir evidência visual.

## Persistência

Em orquestração SDD, prefira:

```text
docs/<slug-da-orquestracao>/design/
  01-brief.md
  02-information-architecture.md
  03-diagrams.md
  04-tokens.md
  05-design-tasks.md
  06-visual-review.md
  screenshots/
  assets/
```

Se não houver orquestração, `.design/<feature-slug>/` é aceitável como workspace local de design.

## Checkpoints

- Antes de Tech Spec: brief, IA e riscos de experiência precisam estar claros.
- Antes de Tasks: fluxos relevantes precisam estar diagramados em Mermaid ou Excalidraw quando texto não bastar; tasks de design precisam ser verticais e verificáveis.
- Antes de merge: `visual-review` precisa ter evidência visual quando houver UI.

## Regras

- Não rode a sequência inteira às cegas; anuncie a fase e o artefato esperado.
- Não duplique PRD/Tech Spec; o design flow complementa com estrutura, estados e evidência.
- Se uma fase revelar mudança de escopo, volte ao PRD/Tech Spec ou ao checkpoint correto.
