---
name: design
description: Criar ou revisar design de produto, UI, UX, CLI/TUI, design system e handoff visual usando a tecnologia real do projeto. Use quando o usuário pedir design, UI, UX, layout, telas, estados, tokens, revisão visual, polish, responsividade, acessibilidade ou experiência dentro do fluxo SDD.
---

# Design SDD

## Princípio

Projete a partir do codebase, não de uma stack imaginária. Primeiro confirme a tecnologia atual pelo Project Discovery, `sdd.config.yaml`, manifests do projeto, rotas, componentes, estilos e docs existentes. O contrato desta skill é provider-neutral: Markdown, arquivos, comandos `sdd`, artifact store e evidência. Codex, Claude, Gemini, opencode ou outro provider são formas de execução, não requisitos da solução.

Ao gerar conteúdo humano em PT-BR, preserve acentuação e diacríticos em títulos, labels, copy, estados, tabelas, Gherkin, Mermaid e Excalidraw. Use ASCII apenas quando o destino técnico exigir slug, path, identificador, comando, schema, campo de API ou contrato literal.

## Fluxo

1. Entenda o objetivo do usuário, o público, a superfície impactada e o estado atual da interface.
2. Confirme a stack real: framework, biblioteca de UI, CSS/tokens, assets, rotas, componentes e padrões de estado.
3. Leia PRD, Tech Spec, Tasks ou design brief se existirem; se não existirem, crie um brief enxuto antes do handoff.
4. Defina uma direção visual adequada ao produto: hierarquia clara, densidade certa para a tarefa, tipografia contida, espaço consistente, contraste acessível e cores com função.
5. Produza artefato acionável: estrutura de tela, componentes, estados, tokens, interações, copy curta, acessibilidade e critério de validação.
6. Quando houver fluxo SDD ativo, salve ou recomende salvar em `docs/<slug-da-orquestracao>/design.md` e relacione com PRD, Tech Spec e Tasks.

## Sequência completa

Quando o usuário pedir fluxo completo, use esta ordem:

1. `design-interview`: tensionar decisões e resolver tradeoffs.
2. `experience-design`: brief e handoff.
3. `information-architecture`: navegação, hierarquia, rotas/comandos e fluxos.
4. `design-tokens`: tokens existentes, lacunas, dark mode e motion.
5. `design-to-tasks`: fatias verticais implementáveis.
6. `frontend-design`: implementação na stack real.
7. `visual-review`: review visual sob demanda ou antes de checkpoint/merge.

Pule fases somente quando houver motivo explícito: componente isolado, tokens já consolidados, ausência de frontend, ou escopo puramente documental/CLI.

## Tecnologia

- Não introduza React, Tailwind, Figma, shadcn/ui, CSS-in-JS, TUI ou qualquer biblioteca nova sem evidência de que a stack já usa ou de que a Tech Spec aprovou.
- Se o projeto for frontend React/Vite/Next, use os componentes e tokens existentes antes de criar novos.
- Se o projeto for CLI/TUI Rust, desenhe estados de terminal, comandos, loaders, empty states, feedback textual, atalhos e acessibilidade de teclado.
- Se não houver frontend, entregue design de experiência: jornadas, comandos, mensagens, estados de erro e handoff para implementação.

## Rubrica minimalista moderna

- Informação essencial primeiro; detalhes secundários ficam disponíveis sem competir pela atenção.
- Layout denso o suficiente para trabalho real, com agrupamentos claros e sem hero/marketing quando for ferramenta operacional.
- Bordas, sombras e superfícies usadas para separar função, não para decorar.
- Cores com propósito: neutros para estrutura, uma cor de ação, cores semânticas para estado.
- Estados completos: loading, vazio, erro, sucesso, disabled, hover/focus, responsivo e conteúdo longo.
- Acessibilidade mínima: contraste AA, foco visível, labels, sem depender apenas de cor, tamanho de alvo adequado.

## Complementos de design

- Brief: usuário primário, JTBD, superfície, princípios, anti-referências, restrições e métrica.
- IA/fluxo: hierarquia de informação, navegação, passos, atalhos, interrupções e recuperação de erro.
- Sistema: tokens existentes, componentes reaproveitados, variantes, estados e lacunas do design system.
- Handoff: arquivos prováveis, dependências novas, dados necessários, validação e fora de escopo.
- Review visual: screenshots ou evidência de terminal, breakpoints, estados e achados por severidade.
- Tasks: vertical slices que unem estrutura, estilo, interação e validação.
- Craft: mobile-first, componentes existentes, tokens semânticos, dark mode e reduced motion.

## Review

Ao revisar UI implementada, não faça só leitura de código. Use screenshot, preview, Storybook, HTML, ferramenta de browser disponível ou evidência enviada pelo usuário. Se o provider/client não tiver visão ou browser, peça evidência ao usuário ou registre o comando/screenshot necessário. Cubra mobile 375px, tablet 768px e desktop 1280px quando a superfície for responsiva. Para CLI/TUI, capture transcript ou screenshot de estados como loading, erro, sucesso e confirmação.

Classifique achados:

- Must fix: quebra de fluxo, acessibilidade, responsividade, estado ausente crítico ou desalinhamento com PRD/Tech Spec.
- Should fix: inconsistência visual, copy fraca, token hardcoded, estado incompleto.
- Could improve: refinamento estético sem risco direto.

## Saída esperada

Use seções curtas:

- `Contexto e stack confirmada`
- `Direção visual`
- `Estrutura da experiência`
- `Componentes e estados`
- `Tokens e estilos`
- `Acessibilidade`
- `Notas de implementação`
- `Validação`

Se a tarefa for apenas revisão, liste achados por severidade com arquivo/tela/evidência quando possível.
