justin-figma-design

Justin Figma Design (/jfd)

Este workspace é um espaço de colaboração focado em Figma, não uma base de código de aplicação. Esta habilidade é a camada de orquestração: memória do workspace, fluxo de trabalho do Figma Console, disciplina de design system e QA visual baseado em evidências. Não gere React, HTML ou CSS, a menos que o usuário solicite explicitamente conversão de design para código.

Companheiro MCP obrigatório

Todo trabalho no Figma depende do Figma Console MCP (user-figma-console): figma_execute para inspecionar e modificar, figma_take_screenshot para evidências, figma_get_status e figma_reconnect para a conexão com o Desktop Bridge. Trabalho de escrita requer o servidor local/NPX com o Desktop Bridge conectado; o modo remoto hospedado é somente leitura. Leia references/figma-execute.md antes de escrever qualquer script, e o arquivo do workspace docs/tools/figma-console.md (na raiz do workspace) para detalhes de conexão. Não trate /jfd como um editor Figma independente sem essa conexão MCP.

Resolva fatos a partir do design, não desta habilidade

Esta habilidade fornece procedimentos, não fatos. Tamanhos de dispositivos, fontes, espaçamentos e preferências de estilo mudam com o tempo; o arquivo alvo está sempre atualizado. Resolva qualquer valor necessário — uma dimensão, fonte, etapa de espaçamento, cor, nome ou convenção — nesta ordem:

1. O arquivo alvo. Meça o frame, texto, token ou componente real.
2. A família. Frames, estados e telas irmãos na mesma seção.
3. Memória do workspace. O arquivo docs/files/<alias>/design.md e docs/preferences.md, respeitando suas datas de "Última verificação".
4. O usuário ou uma consulta atual. Pergunte ou consulte orientações atuais da plataforma. Nunca confie em tamanhos de dispositivos memorizados ou padrões antigos.
5. Registre de volta. Grave o valor resolvido com a data de hoje no design.md alvo para que a próxima sessão possa confiar nele.

Nunca resolva um valor de projeto a partir do texto desta própria habilidade.

Dois fluxos de trabalho

• Editando um arquivo existente (o padrão): há algo a medir. Siga o loop completo abaixo e nunca presuma o tamanho do frame raiz — meça o raiz real da família que está sendo editada.
• Começando do zero: nada existe para medir, então a ordem de resolução segue os passos 3–5. Leia references/starting-from-scratch.md. Confirme o tamanho do frame raiz, tipografia e suporte a temas com o usuário antes de construir, e crie imediatamente o design.md do arquivo para que todas as sessões futuras possam medir em vez de adivinhar.

Inicialize um workspace vazio

Use o modo init quando o workspace não tiver docs/preferences.md e docs/FILES.md. Init é uma estrutura local e idempotente; nunca abre o Figma, chama o MCP ou modifica uma tela.

1. Trate jfd init da mesma forma que /jfd init quando o host não tiver aliases de barra.
2. Liste os caminhos da estrutura ausentes antes de escrever. Em um workspace não vazio, peça confirmação primeiro. Nunca sobrescreva um arquivo, diretório, link simbólico ou instalação de habilidade existente.
3. Copie apenas os arquivos ausentes de assets/templates/ desta habilidade.
4. Instale uma cópia da habilidade ausente em .agents/skills/justin-figma-design/ (canônico) e .cursor/skills/justin-figma-design/ quando apropriado.
5. Opcionalmente, execute scripts/init_project.py (Python 3, apenas stdlib) para uma passagem em lote; as ferramentas de arquivo do agente permanecem o caminho principal.
6. Verifique a estrutura e então peça um link do Figma ou chave do arquivo. Nunca invente credenciais ou dados de arquivo.

Detalhes: references/getting-started.md.

Escolha o modo de operação

Non-YOLO é o padrão.

• Non-YOLO para trabalho em produção: padrões compartilhados, telas, componentes, variáveis, temas, alterações responsivas e qualquer escopo não explicitamente descartável.
• YOLO somente quando o usuário disser explicitamente "YOLO", "demo rápida", "protótipo rápido" ou equivalente, e o escopo for um quadro ou estado nomeado.
• "Criar um componente", "atualizar uma biblioteca", "suportar claro e escuro" ou uma alteração de chrome compartilhado nunca é YOLO apenas por ser pequena.
• Permaneça no modo de planejamento até que o usuário peça claramente para implementar ou executar.

YOLO reduz a sobrecarga de biblioteca; não remove segurança ou QA visual. Escale para Non-YOLO ao descobrir chrome compartilhado, um padrão reutilizável, múltiplos estados relacionados, propagação claro/escuro ou responsiva, uma alteração em componente mestre, uma refatoração de Auto Layout, uma alteração de regra de negócio ou um segundo quadro. Roteador completo e listas de verificação: references/modes-and-workflow.md.

Antes de qualquer mutação no Figma

1. Leia docs/preferences.md e docs/FILES.md na raiz do workspace.
2. Resolva o alias do arquivo alvo e leia seu docs/files/<alias>/design.md; leia screens.md para trabalho com tela, fluxo ou superfície composta.
3. Leia a nota de sessão relevante mais recente. O design.md vivo e a autoridade atual têm precedência sobre notas históricas desatualizadas.
4. Confirme o arquivo Figma ativo, página, seção/frame e autoridade. Pesquise novamente IDs de nós, componentes, variáveis e estilos no arquivo conectado; IDs de sessões anteriores são evidências desatualizadas, não autorização.
5. Faça o inventário de toda a família do mesmo frame/estado antes de uma alteração compartilhada: claro/escuro, expandido/recolhido, rotas aninhadas ativas, sobreposições, variantes responsivas e estados intencionalmente removidos.
6. Meça o(s) frame(s) raiz da família que está sendo editada. Nunca presuma um tamanho de dispositivo.
7. Antes da mutação de texto, inspecione segmentos de fonte estilizados e carregue as fontes atuais. Escolha qualquer fonte de substituição através da ordem de resolução — texto medido, depois design.md, depois o usuário — nunca a partir desta habilidade.

Se o arquivo alvo não tiver design.md, complete uma linha de base de investigação somente leitura primeiro. Se o arquivo ativo ou a autoridade não puder ser verificado, pare e pergunte.

Gráficos comuns

Antes de colocar ícones ou imagens importadas, leia docs/assets/README.md e docs/assets/icons.md na raiz do workspace. Prefira componentes de arquivo existentes e fontes de ícones aprovadas do projeto; inspecione limites de vetor, dimensionamento e contraste de tema antes de aceitar um novo gráfico. Avatares são fornecidos apenas pelo usuário; nunca os gere.

Contrato Non-YOLO

• Pesquise instâncias/componentes autoritativos locais primeiro, depois bibliotecas habilitadas, depois pesquisa mais ampla de biblioteca. Crie somente após documentar a lacuna.
• Construa o sistema de design mínimo coerente para o escopo aprovado: variáveis e modos primeiro, depois estilos e componentes, depois instâncias de tela.
• Use variantes para estados estruturais/visuais e propriedades de componentes para flexibilidade de conteúdo. Prefira instâncias, trocas de instância e wrappers controlados em vez de redesenhos desconectados.
• Torne a intenção do layout legível: nomes semânticos, hierarquia significativa, Auto Layout onde filhos se relacionam, vinculações de token, descrições de componentes e comportamento de acessibilidade/estado documentado.
• Trate Claro/Escuro como uma matriz de modos de variável, não duas telas codificadas. Veja references/variables-and-theming.md.
• Aplique alterações compartilhadas à família completa de telas relacionadas em uma passagem e faça QA de cada membro. Uma correção de frame único não está completa enquanto os irmãos estiverem desatualizados.

Leia references/components-and-design-system.md e references/layout-and-autolayout.md antes de trabalho complexo.

Regras de layout

Escolha Hug, Fill, Fixed e min/max independentemente por eixo: Hug para pilhas e controles orientados por conteúdo; Fill apenas para um filho com espaço disponível significativo em um pai Auto Layout; Fixed para limites estruturais intencionais (raízes de tela medidas, caixas de ícone, CTAs, shells calibrados); min/max para limites responsivos aprovados. Codifique relacionamentos com Auto Layout aninhado, padding e gap — nunca frames espaçadores invisíveis preservando coordenadas antigas. Mantenha camadas absolutas / Ignorar Auto Layout apenas para sobreposições justificadas, chrome, decoração ou exceções documentadas no design.md alvo. Após redimensionar um contêiner, audite os descendentes que controlam largura; um pai mais largo não é um reflow completo. Detalhes: references/layout-and-autolayout.md.

Execute e verifique

Inspecione, execute um figma_execute pequeno e direcionado, retorne cada ID mutado e geometria útil, e então capture uma captura de tela imediatamente com figma_take_screenshot. Mantenha escritas e capturas de tela sequenciais quando o roteamento depender do arquivo ativo. O QA combina estrutura medida com evidência visual — capture, conforme aplicável: (1) um recorte de componente focado, (2) o quadro completo, (3) a visão geral da família ou seção relacionada. Verifique bordas compartilhadas, espaçamento, clipping, overflow, comportamento de cópia longa, limites de ícone/vetor, contraste, tipografia, controles ocultos, estado semântico, paridade de estado relacionado, valores codificados, vinculações não resolvidas e resolução Claro/Escuro. Use designs de Verificação do Figma quando disponíveis; caso contrário, execute verificações estruturais e manuais equivalentes.

Trate um figma_execute com falha como potencialmente parcial até que o alvo seja inspecionado; nunca reexecute cegamente um script de criação ou reparentalização com falha. Contrato de recuperação: references/figma-execute.md. Listas de verificação completas: references/qa-and-recovery.md.

Encerramento

• Capture capturas de tela finais para cada quadro mutado e membro de família necessário.
• Registre exceções intencionais, placeholders, problemas não resolvidos e limites de escopo.
• Atualize o design.md e screens.md alvo quando autoridade, componentes, variáveis, telas, tamanhos raiz ou deriva mudarem — incluindo qualquer valor resolvido durante a sessão.
• Escreva uma nota datada em docs/sessions/ para trabalho significativo.

Respeite as proteções documentadas do arquivo alvo em seu design.md: originais bloqueados ou protegidos, estilos ou estados que devem permanecer removidos, cópia e linguagem que devem ser preservadas. Nunca armazene credenciais ou tokens privados na memória do projeto.

Para orientação externa por trás desta habilidade, leia references/research-sources.md.