Exploração de Direção de UI
Produza uma direção de design utilizável para a tarefa declarada. Inspecione as telas, componentes, tokens, densidade, conteúdo e convenções de interação existentes antes de gerar alternativas. Preserve a identidade do produto, a menos que uma reformulação seja solicitada.
Use evidências de referência
Quando referências externas informarem a tarefa, use design-reference-research se disponível ou inspecione as fontes fornecidas/padrão relevantes diretamente. Consuma sua cobertura de fontes, capture IDs, observações e incertezas. Não refaça pesquisas concluídas nem trate um mood board não inspecionado como evidência. A disponibilidade de referências não torna a pesquisa obrigatória para uma tarefa pequena já fundamentada no produto.
Traduza princípios úteis em alternativas originais usando a identidade do produto existente. Explique como cada escolha consequente segue a tarefa do usuário e as evidências. Resolva padrões conflitantes pela plataforma, tarefa e restrições; não misture sistemas de navegação incompatíveis nem copie a marca de outro produto. Leve adiante estados de interação desconhecidos como perguntas a serem verificadas, em vez de inventar silenciosamente o comportamento observado.
Enquadre as alternativas
Esclareça apenas as escolhas que alteram materialmente o resultado. Identifique a tarefa do usuário, a hierarquia de conteúdo, os estados aplicáveis, as restrições de acessibilidade e as superfícies alvo. Faça as alternativas diferirem em estrutura ou interação consequente, não apenas em cor. Use um número pequeno proporcional à solicitação; não gere sempre três ou exija agentes paralelos.
Mantenha artefatos exploratórios separados do código de produção, a menos que a implementação já tenha sido solicitada. Use dados realistas, rótulos longos, estados vazios/de erro e layouts responsivos onde eles alteram a escolha. Mostre o que cada alternativa melhora e custa. Uma captura de tela sozinha não especifica foco, navegação ou persistência.
Use capacidades de design disponíveis
Use componentes nativos do repositório e ferramentas de pré-visualização/design disponíveis. Uma entrega utilizável pode ser HTML local, um canvas de design existente ou um visual anotado; não precisa depender de um fornecedor hospedado. Não afirme que um design foi renderizado ou testado sem essa evidência.
Para uma integração Superdesign explicitamente configurada, leia hosted-design.md. O fluxo de trabalho ainda deve funcionar quando esse serviço estiver indisponível. Não baixe uma CLI mais recente, crie uma conta ou faça upload de fonte como pré-requisito implícito para o trabalho de design.
Entregue uma direção
Compare alternativas com a tarefa e as restrições. Se o usuário solicitar seleção, apresente as alternativas reais para essa decisão. Se eles autorizarem você a escolher, recomende e prossiga com razões, em vez de introduzir outro portão de aprovação.
Forneça o artefato selecionado, tokens/componentes reutilizados, regras de layout, alterações responsivas, comportamento de interação/foco, estados significativos, ativos e decisões não resolvidas. Vincule critérios de aceitação e desvios intencionais a IDs de evidências de referência, quando disponíveis; uma alternativa que não foi selecionada não é um requisito de implementação. Distinga um design selecionado de uma implementação funcional. Encaminhe a implementação autorizada para frontend-ui-engineering e a crítica para plan-design-review quando disponível, sem exigir que nenhum dos dois esteja instalado.
Leia provenance.md para a fonte do fluxo de trabalho upstream e aviso.