O que justesse faz?
Transforme um breve, repositório ou referência visual em UI de produção coerente. Trate o gosto como julgamento contextual sob restrições, não como um framework, estética ou receita de componentes preferidos.
Esta é uma capacidade declarativa, apenas de referência. Seu raciocínio de design, regras e critérios de aceitação devem permanecer independentes do modelo, runtime de agente, ferramenta de linha de comando, fornecedor e ambiente de hospedagem que a executam. A descoberta específica do runtime pode expor este diretório, mas não deve alterar a semântica da skill nem ser exigida por seu fluxo de trabalho.
Bloqueie o modo de operação
Escolha um modo principal antes de tomar decisões de design. Declare-o na leitura de design e não alterne modos silenciosamente. Se dois modos implicarem entregáveis materialmente diferentes e a solicitação não os resolver, faça uma pergunta focada. Uma tarefa pode nomear um modo secundário, mas o modo principal controla o fluxo de trabalho e o padrão de aceitação.
| Modo | Resultado principal | Referência obrigatória |
|---|---|---|
| Marketing / conversão | Comunicar valor e mover um público em direção a uma ação mensurável | marketing-surfaces.md |
| Produto / tarefa | Ajudar um usuário a entender o estado e concluir trabalho recorrente, incluindo dashboards | product-and-transaction.md |
| Fluxo transacional | Completar uma ação consequente ou de várias etapas de forma segura e recuperável | product-and-transaction.md |
| Redesign: preservar | Melhorar a qualidade mantendo a marca reconhecível e contratos de produto | redesign-preservation.md |
| Redesign: reformular | Estabelecer uma nova linguagem visual retendo contratos não aprovados para alteração | redesign-preservation.md |
| Referência para código | Traduzir evidência visual fornecida para a implementação nativa do projeto alvo | reference-to-code.md |
| Revisão visual | Diagnosticar hierarquia, coerência, usabilidade, responsividade e risco de produção | interface-quality.md |
| Leitura / documentação | Ajudar um leitor a entender algo através de docs, guias, artigos, ajuda ou changelogs | reading-surfaces.md |
| Experiência / showcase | Colocar um visitante dentro de portfólio, galeria ou trabalho de exposição enquanto a interface recua | experience-surfaces.md |
| Conceito de imagem | Definir ou produzir direção de arte que sirva à interface | image-concepts.md |
| Visualização de dados | Transformar medidas, comparações, distribuições, relações e incerteza em evidência inspecionável | data-visualization.md |
| Memorando de decisão executiva | Transformar evidência delimitada em uma apresentação orientada por conclusão para um tomador de decisão | decision-memo.md |
Após selecionar o modo principal, defina o perfil separadamente. Esta skill fornece o mecanismo de perfil e nenhum perfil. Ative personal:<nome> apenas quando essa flag exata for explícita na solicitação ou nas instruções do projeto. Nunca a infira a partir do nome de uma pessoa, de um tipo de artefato ou da disponibilidade desta skill. Sem a flag, mantenha a linguagem visual, voz, paleta, materialidade e cor de superfície neutras em relação à marca; uma tela de papel claro não é um padrão.
Uma flag ativa abre uma declaração obrigatória, não concede um sistema visual. Obtenha respostas concretas para todos os dez campos em profile-declaration.md antes de tomar qualquer decisão de design sob o perfil, e nunca preencha um campo não respondido por inferência ou tomando emprestado um valor de outro perfil, dos exemplos desta skill ou de seus equipamentos de teste. Pergunte cada campo com um exemplo prático anexado, na forma de resposta do próprio campo; uma pergunta nua retorna um clima onde o formulário precisa de uma medida.
Fluxo de trabalho principal
- Inspecione antes de propor. Leia os arquivos relevantes do projeto, telas e componentes representativos, configuração de pacotes e build, tokens de design, formas de dados, rotas, testes e referências fornecidas. Identifique o que é real, o que é inferido e o que permanece desconhecido.
- Enquadre o briefing. Leia brief-and-direction.md. Registre o público, trabalho do usuário, objetivo de negócio, conteúdo e evidência de marca, restrições, modo principal e sinal de sucesso. Enumere cada entregável solicitado antes da implementação. Prefira uma interpretação defensável a uma colagem de tendências.
- Declare a leitura de design. Em uma declaração compacta, nomeie o modo, público, trabalho do produto, direção visual, densidade e postura de movimento. Diferencie decisões de suposições.
- Preserve o contrato do produto. Mantenha o framework existente, gerenciador de pacotes, convenções de componentes, sistema de design, contratos de dados e API, semântica de estado, rotas, formulários, analytics, comportamento de consentimento e legal, acessibilidade, SEO, significado de conteúdo, testes e orçamentos de desempenho, a menos que o usuário autorize explicitamente uma alteração. O modo de reformulação não é permissão para quebrá-los.
- Implemente nativamente. Reuse dependências instaladas e primitivas estabelecidas. Expresse a direção no próprio framework e modelo de estilo do projeto. Não introduza React, Tailwind, GSAP, outro sistema de design, modo escuro, uma fonte ou qualquer dependência meramente porque esta skill menciona uma possibilidade visual.
- Resolva todo o espaço de estados. Projete layout responsivo mais estados aplicáveis de carregamento, vazio, parcial, erro, sucesso, desabilitado, permissão, offline, validação e ação destrutiva. Para dashboards e fluxos, proteja a legibilidade dos dados, continuidade da tarefa e recuperação.
- Renderize e verifique em passes limitados. Construa completamente primeiro. Então inspecione viewports representativos estreitos e largos e extremos reais de conteúdo juntos em uma rodada em lote quando a ferramenta de pré-visualização existir, comparando hierarquia, ordem de leitura, overflow, contraste, foco, feedback de interação e preservação de contrato. Corrija tudo que essa rodada mostrar em um lote, confirme com no máximo mais uma rodada, e pare de polir: um loop de auto-QA aberto gasta o orçamento sem convergir, e o limite cobre todo o ciclo, capturas de tela, varreduras de defeitos, micro-edições e reconstruções igualmente. Não chame um mockup de pronto para produção sem evidência proporcional de build, teste e visual.
- Pré-verifique a entrega. Leia production-preflight.md, corrija falhas aplicáveis, verifique cruzadamente cada entregável solicitado e relate verificações que não puderam ser executadas.
Roteamento de referências
Carregue apenas o que o modo ativo precisa; cada referência está diretamente linkada aqui.
- Sempre leia brief-and-direction.md, interface-quality.md e production-preflight.md.
- Leia marketing-surfaces.md para marketing, campanha, conversão editorial, preços, lançamento ou outras superfícies de aquisição.
- Leia reading-surfaces.md para documentação, guias, artigos, ajuda, changelogs e páginas de formato longo cujo trabalho é compreensão.
- Leia experience-surfaces.md para portfólios, galerias, showcases e páginas de exposição onde o trabalho em si lidera.
- Leia product-and-transaction.md para UI de aplicação, dashboards, espaços de trabalho densos em dados, formulários, checkout, onboarding, configurações e fluxos de várias etapas.
- Leia data-visualization.md sempre que uma superfície contiver um KPI, gráfico, figura analítica, comparação de métricas, tabela de números ou exibição de data/período.
- Leia redesign-preservation.md sempre que uma superfície existente mudar, no modo preservar ou reformular.
- Leia reference-to-code.md quando capturas de tela, mockups, sites ou outros exemplos visuais forem entradas de implementação.
- Leia image-concepts.md apenas quando imagens fizerem parte do briefing ou conceito de imagem for o modo selecionado.
- Leia style-lenses.md quando o briefing carecer de um vocabulário visual ou direções concorrentes precisarem ser separadas.
- Leia finishing.md por último, e apenas quando as verificações de qualidade de interface se sustentarem, para refinamento de nível de entrega e para julgar candidatos quase idênticos; finalizar nunca substitui hierarquia, veracidade ou estados.
- Leia react-next-tailwind.md apenas quando o projeto inspecionado já usar React, Next.js ou Tailwind, ou o usuário autorizar explicitamente essa stack para trabalho em campo verde; não é o padrão portável.
- Leia decision-memo.md para um memorando executivo, deck de decisão ou qualquer sequência de slides orientada por conclusão.
- Leia pptx-safe-html.md antes de diagramar o primeiro slide sempre que o entregável for um arquivo de apresentação editável em vez de uma página.
- Leia surface-translation.md quando uma visão de mundo precisar ser transportada através de dashboard, landing page com autoria, estudo de caso, relatório e apresentação.
- Com a flag exata
personal:<nome>, leia profile-activation.md e profile-declaration.md primeiro, depois profile-data-semantics.md assim que a declaração estiver completa. Caso contrário, não os carregue ou aplique. - Leia profile-calibration.md apenas ao executar uma comparação de perfil controlada, controle negativo, revisão cega ou decisão de promoção.
- Leia upstream-provenance.md apenas para atribuição, auditoria, redistribuição ou comparação upstream.
Não carregue recursivamente arquivos não relacionados das referências.
Capacidades condicionais
Use geração de imagem, busca de imagem ou navegação apenas quando disponível, autorizado e necessário. Para trabalho de imagem, prefira ativos existentes do repositório, depois ativos fornecidos pelo usuário, depois uma ferramenta autorizada. Caso contrário, entregue um briefing de conceito específico ou um placeholder claramente rotulado sem afirmar que é arte final. Use placeholders apenas para ativos externos ou dependências verdadeiramente ausentes; especifique as dimensões, função e próximo passo de substituição de cada placeholder. Não fabrique capturas de tela de produto, clientes, métricas, logotipos ou endossos.
Use movimento apenas quando ele clarificar hierarquia, feedback, continuidade ou narrativa. Prefira o mecanismo existente do projeto e a técnica adequada mais leve. Preserve conteúdo sem movimento, respeite preferências de movimento reduzido, evite captura de scroll e limpe observers, listeners e timelines. Bibliotecas de movimento são escolhas condicionais de implementação, nunca um requisito. Escale para motion-patterns.md apenas quando uma transição CSS nativa não for mais adequada e o trabalho precisar de coreografia em camadas, storytelling com scroll ou um motor de animação dedicado.
Contrato de entrega
Entregue a superfície implementada ou revisada juntamente com o modo e leitura de design, contratos preservados e intencionalmente alterados, evidência de verificação e quaisquer placeholders ou riscos não resolvidos. Para uma solicitação apenas de revisão, priorize as descobertas por impacto no usuário e cite a tela ou componente afetado; não mude o projeto a menos que solicitado.