Communitygithub.com

cucuwang/visual-fix

Aponte para um defeito de UI, localize a fonte correta, aprove o patch e verifique o resultado.

O que é visual-fix?

Esta skill oferece um fluxo de trabalho estruturado para corrigir um único problema visível de interface do usuário (UI) por vez, transformando-o em uma mudança de código localizada, aprovada e verificada. É útil para desenvolvedores que trabalham com depuração visual, permitindo localizar rapidamente a origem no código a partir de uma captura de tela ou descrição do sintoma. A skill suporta várias evidências, como screenshots, seletores de DOM, nomes de componentes e descrições em linguagem natural. O processo inclui etapas para estabelecer um estado de linha de base, localizar o código-fonte renderizado, diagnosticar a causa raiz, planejar a correção exata, aplicar o patch aprovado e, finalmente, verificar a correção visualmente ou através de testes automatizados. Embora seja genérica, a skill se refere a arquivos de referência opcionais (`locating.md` e `verification.md`) para projetos específicos, permitindo customização para diferentes frameworks, sistemas de estilo ou plataformas de desenvolvimento.

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add cucuwang/visual-fix

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Correção Visual

Transforme um problema visível de UI em uma mudança de código localizada, aprovada e verificada.

Evidências Suportadas

Aceite qualquer combinação útil de:

  • Uma captura de tela da UI atual
  • Uma captura de tela com uma região anotada ou descrita
  • Uma captura de tela atual e uma alvo com seus papéis identificados
  • Uma rota, viewport, nome de componente, string visível, seletor ou ID de teste
  • Um sintoma em linguagem natural, como "este card está cortado" ou "estes controles não estão alinhados"

Peça apenas por evidências que impeçam a localização confiável. Uma rota mais uma string visível única podem ser suficientes sem uma captura de tela. Uma captura de tela com componentes repetidos ainda pode precisar de uma rota, rótulo ou estado.

Lide com um problema visual de cada vez. Divida sintomas não relacionados em correções separadas.

Fluxo de Trabalho

1. Estabeleça o alvo

Reafirme o resultado delimitado em termos concretos:

  • O que parece errado agora
  • O que o usuário espera ver
  • Qual rota, componente, estado e viewport são relevantes, quando conhecidos
  • Qual âncora visível identifica o alvo

Se o resultado solicitado for subjetivo ou puder afetar diferentes elementos, faça a menor pergunta que os distinga.

2. Estabeleça uma linha de base somente leitura

Antes de editar:

  • Encontre as instruções do repositório e a fonte da verdade.
  • Inspecione o status da árvore de trabalho e preserve as alterações existentes do usuário.
  • Identifique o framework, a entrada da rota, a árvore de componentes, o sistema de estilo e os comandos disponíveis de execução ou teste.
  • Reproduza a rota alvo e o viewport quando o ambiente permitir.
  • Capture ou registre o estado atual antes de alterá-lo.

Não edite a saída gerada quando existir um arquivo de origem mantido. Não limpe ou sobrescreva alterações não relacionadas na árvore de trabalho.

Relate a linha de base brevemente:

Contexto
- Rota/estado: /catalog, filtros abertos
- Viewport: 390 x 844
- Fonte da verdade: src/routes/catalog.tsx + src/styles/catalog.css
- Alterações existentes do usuário: nenhuma
- Reprodução: disponível

3. Localize a fonte renderizada

Rastreie evidências do elemento renderizado de volta ao código mantido. Use a rota, nome acessível, texto visível, seletor DOM, nome do componente, ID de teste, classe, token de estilo ou geometria da captura de tela. Leia references/locating.md quando vários arquivos ou camadas de estilo estiverem envolvidos.

Identifique um local de origem principal e no máximo dois locais relacionados necessários. As evidências de arquivo e linha devem vir da árvore de trabalho atual.

Localizado
- Principal: src/components/ProductGrid.tsx:42, ProductGrid
- Relacionado: src/styles/products.css:18
- Evidência: `.grid` controla o espaçamento horizontal repetido visível entre os cards
- Confiança: alta

Se dois elementos semelhantes permanecerem plausíveis, explique a evidência distintiva e pare para esclarecimento.

4. Diagnostique a partir das evidências

Conecte o sintoma visível ao código real. Prefira uma causa suportada. Ofereça duas ou três hipóteses apenas quando as evidências permanecerem ambíguas.

Para cada hipótese, inclua:

  • A propriedade, seletor, token ou componente envolvido
  • O código ou evidência renderizada que a suporta
  • A direção da correção pretendida
  • Uma observação que a refutaria

Não invente valores CSS a partir da captura de tela. Inspecione o valor atual e o sistema de design ao redor primeiro.

5. Apresente o plano de alteração exato

Mostre o patch proposto antes de editar:

Plano de alteração
- Arquivos: src/components/ProductGrid.tsx:42
- Atual: gap: 8px
- Proposto: usar o token space-4 existente (16px)
- Escopo: ProductGrid em /catalog e /search
- Preservando: padding do card, contagem de colunas móveis, rotas não relacionadas
- Verificação: teste direcionado, lint, capturas de tela em 390 x 844 e 1280 x 800
- Risco: médio; o componente é compartilhado por duas rotas

Aguarde aprovação explícita deste plano. Escolher um diagnóstico não aprova uma alteração de código. Se o plano depois se expandir para outro arquivo, dependência, arquivo de bloqueio, artefato gerado ou rota, apresente o plano revisado e obtenha aprovação novamente.

6. Aplique o patch aprovado

Faça a menor alteração que implemente o plano. Mantenha as edições dentro dos arquivos e escopo aprovados. Em seguida, inspecione o diff imediatamente:

  • Execute git diff --check quando o projeto usar Git.
  • Confirme que o diff contém apenas a alteração planejada.
  • Preserve alterações pré-existentes e evite reformatação não relacionada.
  • Não faça commit, push, instale dependências ou modifique serviços externos, a menos que autorizado separadamente.

7. Verifique o resultado

Leia references/verification.md antes de afirmar sucesso.

Use a evidência mais forte disponível:

  1. Execute testes direcionados, formatação, verificações de tipo ou uma compilação relevante para o código alterado.
  2. Renderize a mesma rota, estado e viewport usados para a linha de base.
  3. Compare visualmente antes e depois.
  4. Verifique um viewport próximo ou rota compartilhada quando a fonte alterada tiver escopo mais amplo.

Relate exatamente um estado de verificação:

  • Verificado visualmente quando existirem evidências de renderização comparáveis antes e depois
  • Verificado estaticamente quando as verificações de código passarem, mas a UI não puder ser renderizada
  • Não foi possível verificar visualmente quando o ambiente não tiver a rota, navegador, fixture ou caminho de inicialização
  • Falha na verificação com o comando com falha ou regressão observada

Se a verificação falhar, retorne ao diagnóstico. Não empilhe uma segunda correção não aprovada em cima da primeira.

Relatório de conclusão

Mantenha a transferência compacta e baseada em evidências:

Corrigido
- Alvo: espaçamento do card do catálogo em largura móvel
- Fonte: src/components/ProductGrid.tsx:42
- Alteração: gap agora usa space-4
- Verificação: Verificado visualmente em 390 x 844; teste unitário e lint passaram
- Verificações mais amplas: /search em 390 x 844 e /catalog em 1280 x 800

Mencione qualquer incerteza visual restante. Nunca descreva um diff de código como prova visual.

Habilidades Relacionadas