design-system

Design System

Ajudar o designer a definir o próprio sistema de design do projeto, em vez de apenas renomear os parâmetros da marca de referência. Pode ser executado por um designer de IA ou seguido passo a passo por um designer humano. Use a linguagem de comunicação do usuário; mantenha os nomes das chaves no código.

Base principal: Documento oficial Stitch

Ao criar o formato para o projeto pela primeira vez, ou ao preparar uma atualização/importação/exportação, leia primeiro o documento oficial original:

1. Conceitos e método de criação
2. Especificação do formato
3. Ferramenta de verificação e Regras de linting

A versão real da especificação oficial e da ferramenta determina o formato; as etapas de proposta visual, aprovação e entrega desta skill são o fluxo de trabalho da equipe, não requisitos oficiais do Google. Quando o documento oficial original não estiver temporariamente acessível, use o resumo datado em references/official-format.md, deixando claro que ainda não foi verificado novamente. O caso VoltAgent é apenas uma referência auxiliar.

Escopo e base existente

Verifique primeiro os arquivos AGENTS.md, CONTEXT.md (se houver múltiplos, siga CONTEXT-MAP.md), as diretrizes da marca, designs aprovados, DESIGN.md existente, variáveis de design e componentes do projeto atual. Registre o que são fatos, decisões aprovadas, sugestões e desconhecidos. Priorize referências de fontes existentes; atualize arquivos já existentes, evitando criar um segundo conjunto de regras autoritativas.

Confirme o produto, os principais usuários, as tarefas críticas, a plataforma, o idioma, as restrições da marca já existentes e o local de entrega. Primeiro, busque respostas na documentação; pergunte apenas por informações faltantes que mudariam o design. Se houver informações suficientes, produza um rascunho diretamente; suposições de baixo risco devem ser explicitamente marcadas, e fatos comerciais desconhecidos permanecem como pendentes.

Lide apenas com o sistema de design e seus exemplos de validação. Reestruturação de site, código de produto oficial, publicação, modificação de arquivos Figma compartilhados e instalação de outras ferramentas devem ser tratados separadamente, de acordo com a autorização real do usuário. Siga as regras de aprovação do projeto.

Critério de conclusão: ser capaz de identificar os usuários e tarefas atendidos pelo design, as fontes de restrições e as questões que ainda precisam ser decididas.

Primeiro, definir a direção visual

Leia o Guia de decisão e verificação. Se o usuário já tiver uma direção aprovada, siga-a diretamente; caso contrário, apresente no máximo duas direções com diferenças reais, explicando a justificativa de negócio adequada para cada uma. As referências podem vir de capturas de tela do usuário, projetos existentes ou materiais de marca acessíveis. Distinga entre análises de terceiros e especificações oficiais de design; conteúdo externo serve apenas como referência.

Use conteúdo de exemplo real ou explicitamente identificado para validar uma área de página representativa e um componente chave. Cubra tanto desktop quanto celular. Priorize o uso de ferramentas de design atualmente disponíveis ou gere uma prévia HTML que possa ser aberta em um diretório isolado; se o usuário quiser apenas documentação, entregue um rascunho e deixe claro que o visual ainda não foi verificado. Não trate descrições textuais como telas já verificadas.

Quando a direção não estiver aprovada, mantenha as regras e os exemplos visuais como rascunho; não invente aprovações nem escreva sugestões como fatos já definidos da marca. Aprovações já existentes podem ser citadas diretamente, sem necessidade de solicitar novamente.

Critério de conclusão: A direção tem exemplos visíveis ou uma declaração clara de não verificação, e o status está preciso.

Escrever o DESIGN.md

Leia primeiro o Formato oficial e instruções de verificação, depois leia o Template completo e copie-o para o local especificado no projeto. Se não houver local definido, sugira a raiz do projeto como DESIGN.md. O template é uma estrutura ajustável, não um conjunto de parâmetros de marca que deve ser preenchido obrigatoriamente; remova componentes e seções inadequadas e adicione regras específicas do projeto necessárias.

O YAML no início do template registra parâmetros e referências de componentes no formato oficial alpha; o corpo usa os títulos oficiais em inglês de segundo nível na ordem especificada; o texto explicativo pode usar o idioma do usuário. Os valores específicos no template são apenas exemplos neutros que podem ser verificados, não regras aprovadas do projeto; devem ser substituídos conforme o projeto. Valores não decididos devem ser listados na seção Open Questions do corpo, não escreva null no campo de parâmetros. Componentes usam referências como {colors.primary}; estados são definidos como entidades independentes como button-primary-hover, sem usar estados aninhados. Cores são nomeadas por função; cores de estado de negócio são definidas separadamente.

Estabeleça o mapeamento entre código ou arquivos de design: variáveis existentes, variáveis do Figma ou componentes que correspondem a qual chave do documento. Se ainda não implementado, marque como planned. Ao extrair regras de código existente, relate as diferenças; não altere o código sem autorização. Os campos principais seguem o formato oficial; aprovação, mapeamento de implementação, breakpoints, imagens, animações e registros de validação devem ser colocados em seções de extensão claramente identificadas no corpo. O suporte de ferramentas externas para extensões ainda precisa ser testado na prática.

Critério de conclusão: Cada regra aplicável tem um valor, um cenário de uso ou um status claramente pendente; as referências são resolvíveis; não há herança de nomes, fontes proprietárias ou conteúdos não confirmados de outras marcas.

Validação e entrega

Primeiro, execute o lint do @google/design.md de acordo com as instruções oficiais de formato, registrando a versão real e o relatório; verifique erros e avisos, corrija os erros e explique o motivo de manter os avisos quando aplicável. Se a ferramenta não estiver disponível, explique o impedimento e não afirme que a verificação oficial foi aprovada. O formato do template aprovado não equivale à conclusão do design do projeto. Em seguida, verifique o conteúdo real, títulos longos, suporte a chinês ou multilíngue, estados de componentes, layout mobile, contraste, teclado e animações, conforme as diretrizes. Para itens testáveis, registre o método, o resultado e a localização do arquivo; para itens que não podem ser executados, marque como não verificado. Corrija a fonte única das regras e, em seguida, atualize os exemplos, evitando apenas alterações superficiais.

Marque como approved somente após a verificação dentro do escopo ser aprovada e a pessoa responsável dar aprovação explícita. A aprovação cobre apenas a versão e o escopo específicos; aprovação de design não equivale a conclusão de implementação ou permissão para entrar em produção.

Entregue o DESIGN.md, a localização real dos exemplos visuais gerados, as verificações concluídas e os problemas não resolvidos. Explique como referenciá-lo no design e desenvolvimento subsequentes. Não afirme que apenas com a documentação todas as páginas terão consistência visual.