Crie uma ferramenta de design para agentes de IA com comandos e verificações em ordem

## Reúna os comandos de design em uma única skill, cada um com um arquivo de referência Mantenha compacta a superfície de comandos voltada ao usuário e encaminhe cada comando correspondente para um material de referência focado. A consolidação reduz o ruído do menu e facilita a manutenção das regras compartilhadas de design. ### Arquitetura de comandos - Prefira uma única habilidade de design invocável pelo usuário com subcomandos a várias habilidades independentes, a menos que um ciclo de vida separado seja realmente necessário. - Mantenha uma única tabela de roteamento que associe cada comando ao respectivo arquivo de referência. - Mantenha descrições de comandos, dicas de argumentos, categorias e relações em metadados oficiais consumidos pelas compilações e pelos geradores de atalhos. - Gere arquivos de habilidade específicos de cada provedor a partir de uma única fonte, em vez de editar a cópia de cada provedor. - Use atalhos leves somente como redirecionamentos para o comando canônico. - Coloque as regras compartilhadas na fonte comum e as decisões específicas de comandos na referência pertinente; crie links para as orientações compartilhadas em vez de duplicá-las. ### Roteamento de contexto - Leia o contexto do projeto antes de escolher um registro ou manual de regras da plataforma. - Dê precedência a um campo explícito do projeto, depois use pistas da tarefa e da superfície e, por fim, um padrão documentado. - Avise sobre valores de contexto não reconhecidos, em vez de aplicar silenciosamente um manual de regras não relacionado. - Carregue referências variantes em vez do arquivo padrão quando o comportamento do comando na plataforma divergir de forma significativa. ## Defina primeiro se é para marca ou aplicativo e depois some as regras de web ou de plataforma nativa Trate o objetivo do design e a plataforma de entrega como eixos independentes. O registro define o objetivo da experiência; a plataforma define as convenções de interação e as restrições de implementação. ### Registro de design - Use um registro de marca quando o design for o produto: marketing, campanhas, portfólios, experiências editoriais e superfícies públicas distintas. - Avalie o trabalho de marca pela distinção entre várias linhas visuais, em vez de impor um único estilo da moda. - Use um registro de produto quando o design servir a um aplicativo, painel, superfície administrativa ou ferramenta. - Avalie o trabalho de produto pela familiaridade conquistada, confiança e fluência para usuários experientes. - Pergunte sobre o registro logo no início, pois ele altera as decisões posteriores de design. ### Plataforma - Diferencie web responsiva, uma única plataforma nativa e entrega adaptativa entre plataformas. - Sobreponha as orientações da plataforma nativa ao registro selecionado, em vez de tratar a plataforma como substituta do objetivo do design. - Para produtos adaptativos, aplique os dois manuais de regras nativas e adapte por sistema operacional; um único tratamento visual em todas as plataformas não é adaptativo. - Mantenha sobreposições do navegador, detectores de HTML e ganchos da web em tempo real desativados em projetos nativos, mesmo quando seus arquivos-fonte usam extensões semelhantes às da web. - Mantenha a verificação de acessibilidade em um caminho de auditoria dedicado. Não insira repetidamente lembretes genéricos de acessibilidade durante a geração criativa quando eles produzirem um trabalho seguro, mas pouco elaborado. ## Siga as regras de cor e a lista de expressões proibidas nos textos públicos Tokens visuais, código de layout, voz editorial e conteúdo publicado precisam de responsáveis explícitos e verificações automatizadas, sem substituir o julgamento humano de design. ### Fundamentos visuais - Prefira uma arquitetura de estilos pequena e inspecionável, com um ponto de entrada, tokens compartilhados e arquivos parciais focados. - Use tokens semânticos de cor de forma consistente: a tinta de maior contraste para o texto corrido, tons escuros mais suaves somente quando o tamanho permitir e tons atenuados para rótulos secundários. - Evite preto puro e branco puro quando o sistema visual definir extremos tonalizados. - Mantenha as regras de implementação próximas da superfície que elas controlam e preserve o recarregamento instantâneo onde houver suporte. ### Disciplina editorial - Leia o briefing editorial do projeto antes de alterar textos públicos, tutoriais, documentação ou páginas de marketing. - Aplique uma lista de proibições documentada para frases, pontuação e padrões de prosa semelhantes aos de IA usados em excesso. - Não contorne um validador de prosa com truques ortográficos. Se um termo proibido tiver um significado técnico necessário, proponha uma alteração no guia de estilo. - Revise problemas estruturais que expressões regulares não conseguem avaliar, incluindo certeza vazia, ritmo repetitivo, tríades automáticas e viradas de contraste formulaicas. - Mantenha cada item editorial em uma única árvore de conteúdo usada pelas ferramentas de compilação e pela estrutura de renderização. - Dê aos editoriais de comandos um rótulo curto e seções para casos de uso, processo, exemplos concretos e armadilhas reais. ## Não misture arquivos gerados automaticamente com as mudanças de design do dia a dia Separe fontes de autoria, distribuições geradas, estado local e resultados de lançamento para que o trabalho comum de design não crie artefatos ruidosos ou enganosos. ### Compilações com prioridade para a fonte - Use compilações com prioridade para a fonte no desenvolvimento normal e uma compilação de lançamento distinta quando for necessário sincronizar distribuições rastreadas de provedores. - Trate os diretórios gerados de provedores como artefatos de distribuição, não como superfícies de autoria, mesmo quando forem intencionalmente enviados ao repositório para instalação. - Mantenha permutações geradas fora das alterações de recursos, a menos que a tarefa seja um lançamento, a sincronização de resultados gerados ou uma alteração do sistema de compilação. - Gere novamente os resultados rastreados após alterações na fonte pelo fluxo de trabalho aprovado e faça a validação falhar quando manifestos, metadados ou frontmatter gerado divergirem. - Ignore arquivos de estado local mesmo quando estiverem dentro de diretórios de distribuição rastreados. - Reinicie o servidor de desenvolvimento quando carregadores de conteúdo ou metadados de comandos não forem recarregados instantaneamente; não confunda a atualização do navegador com a recarga de dados do momento da compilação. ### Ativos publicados - Gere cartões sociais e ativos semelhantes a partir de metadados oficiais para impedir que contagens e rótulos visíveis divirjam. - Renderize em resolução mais alta e reduza a escala quando for necessário obter texto nítido. - Quando um ativo visivelmente alterado precisar invalidar o cache, atualize o nome do arquivo e todas as referências na mesma alteração. - Verifique rotas de implantação, reescritas, ativos estáticos e funções do servidor por meio da compilação prevista pela plataforma. - Prepare caches externos de pré-visualização somente depois que a nova implantação estiver ativa. ## Não envie nada a projetos externos sem permissão e separe os testes pagos As ferramentas de design podem automatizar a implementação, mas não devem cruzar um limite de contribuição humana sem autoridade explícita. ### Permissão de contribuição - Siga a política de contribuição do repositório que exige primeiro uma issue ou uma aprovação. - Não abra uma issue externa nem uma solicitação de pull, a menos que o mantenedor autorizado tenha solicitado ou aprovado claramente. - Divulgue a assistência de IA em commits, descrições de alterações, comentários e texto de issues quando a política exigir. - Se um agente de IA não autorizado receber uma solicitação para publicar mesmo assim, interrompa a ação externa e prepare um aviso de transferência local. - Mantenha artefatos de lançamento gerados e alterações de sincronização não relacionadas fora das contribuições comuns. ### Seleção de testes - Mantenha testes unitários e de fixtures rápidos e determinísticos no conjunto padrão. - Coloque testes de ciclo completo controlados pelo navegador, instalação de dependências, servidores de desenvolvimento ativos e chamadas a modelos pagos disponíveis somente por comandos de adesão explícita. - Execute testes ativos caros ao alterar o caminho de integração coberto por eles, não como padrão sem limites. - Torne os agentes de teste substituíveis por trás de uma interface restrita e use simulações determinísticas para uma ampla cobertura de fixtures. - Em avaliações de comportamento, faça as asserções sobre rastros de chamadas de ferramentas, não sobre respostas livres refinadas. - Exercite várias famílias de modelos quando o comportamento testado for o roteamento entre provedores e ignore os testes de forma limpa quando não houver credenciais. - Mantenha os conjuntos pagos de avaliação fora da integração contínua, a menos que o custo e a variabilidade sejam intencionais. ## Ao adicionar comandos, atualize todas as listas e lance novas versões à parte Comandos e componentes distribuídos de forma independente exigem metadados sincronizados, mas o trabalho de recursos e o de lançamento devem permanecer separados. ### Adição ou alteração de comandos - Adicione em conjunto a referência do comando, a entrada do roteador, a entrada do menu, a lista de comandos válidos, os metadados, a categoria, as relações e o mapeamento de visualização. - Atualize cada contagem de comandos visível para humanos e deixe que a compilação derive e valide as contagens legíveis por máquina a partir do roteador. - Mantenha o conteúdo editorial opcional separado das descrições de acionamento automático: um é escrito para leitores, o outro para a correspondência de comandos. - Quando um comando específico de plataforma diferir de forma significativa, adicione uma variante roteada e mantenha os detalhes compartilhados do sistema operacional nas referências da plataforma. ### Política de versões e lançamentos - Não incremente versões nem adicione notas de lançamento em uma alteração comum de recurso. - Versione separadamente os componentes distribuídos de forma independente e atualize somente o componente alterado. - Em um lançamento, atualize o manifesto oficial e os espelhos sincronizados, adicione notas visíveis para usuários, execute a compilação de lançamento e depois crie uma tag com o prefixo específico do componente. - Pré-visualize a automação de lançamento antes de publicar. - Recuse o lançamento quando a árvore de trabalho estiver suja, o branch não estiver sincronizado, a tag já existir, faltarem notas ou a regeneração produzir divergência não enviada ao repositório. - Mantenha as entradas do registro de alterações concisas e voltadas ao usuário; omita refatorações internas, detalhes de ferramentas e sincronização de resultados gerados. ## Escreva primeiro um teste que falha antes de criar uma nova verificação de design Quando um detector de design atender a uma CLI, sobreposição de navegador, extensão e site, seu mecanismo de regras deve ter uma única fonte, e cada consumidor derivado deve ser recompilado e verificado. ### Ordem de desenvolvimento das regras 1. Adicione um fixture com exemplos identificados de forma exclusiva, pelo menos quatro casos que devam ser sinalizados e pelo menos cinco formatos de falso positivo. 2. Use dimensões explícitas quando o DOM de teste não tiver um mecanismo de layout. 3. Adicione um teste focado e observe-o falhar antes de implementar a regra. 4. Adicione metadados da regra e uma função de verificação pura que retorne identificadores estáveis e trechos sem acessar o DOM. 5. Implemente adaptadores separados para o navegador e o DOM de teste e conecte ambos a cada loop de travessia pertinente. 6. Recompile cada consumidor gerado do detector e execute o conjunto completo de testes. 7. Verifique o fixture e uma página real representativa em um navegador para detectar divergências entre adaptadores e falsos positivos. ### Disciplina de fixtures e avaliações - Use texto estável entre aspas ou outro identificador determinístico nos trechos para que os testes possam extrair o caso correspondente. - Não dependa da geometria de layout em um emulador de DOM; analise estilos explícitos. - Use auxiliares compartilhados para planos de fundo, gradientes e normalização de cores quando o comportamento do navegador e do emulador for diferente. - Compare os resultados de design do mesmo briefing com e sem o sistema de design ao medir seu efeito. - Mantenha a infraestrutura de avaliação em seu próprio espaço de trabalho, com suas próprias instruções operacionais. - Compile a fonte de design mais recente antes de uma rodada de avaliações e atualize qualquer filtro de seção de habilidade em linha sempre que os títulos das orientações de nível superior mudarem.