component-refactoring

Visão geral da skill component-refactoring

O que a component-refactoring faz

A skill component-refactoring ajuda você a refatorar componentes React de alta complexidade no frontend do Dify sem ficar adivinhando por onde começar. Ela foi feita para casos em que um componente já está grande demais, aninhado demais ou difícil demais de testar com clareza, e você precisa de um plano estruturado para separar UI, extrair hooks ou reduzir a complexidade cognitiva.

Quando ela é a melhor opção

Use a skill component-refactoring quando pnpm analyze-component --json apontar complexidade acima de 50, contagem de linhas acima de 300, ou quando o analisador recomendar explicitamente refatoração antes dos testes. Ela também faz sentido quando a tarefa é especificamente dividir código, extrair hooks ou simplificar um componente que acumulou ramificações condicionais demais.

O que a torna útil

Essa skill é mais orientada a decisão do que um prompt genérico de refatoração. Ela oferece um fluxo de trabalho alinhado às ferramentas de análise de componentes do Dify, além de padrões concretos de redução, como divisão por seções e extração de hooks. Isso importa porque o principal risco em arquivos React grandes não é a sintaxe; é manter o comportamento enquanto se reduz o acoplamento.

Como usar a skill component-refactoring

Instale e aponte para o repositório certo

Instale a skill component-refactoring com npx skills add Charlie85270/Dorothy --skill component-refactoring. O fluxo pressupõe a estrutura do frontend do Dify, então execute os comandos a partir de web/ e use caminhos relativos a esse diretório, como app/components/....

Comece pela análise, não por um rewrite

Um fluxo forte de component-refactoring usage é: analisar o componente, inspecionar o prompt gerado e então refatorar só as partes que realmente estão puxando a complexidade para cima. Use pnpm analyze-component <path> --json para confirmar a pontuação e a contagem de linhas, e pnpm refactor-component <path> --json quando quiser um resumo de refatoração em formato legível por máquina. Se o arquivo não estiver acima do limite, talvez a skill nem seja necessária.

Leia estes arquivos primeiro

Para tirar proveito prático do component-refactoring guide, leia primeiro SKILL.md e depois os docs de referência que explicam os padrões por trás do prompt: references/complexity-patterns.md, references/component-splitting.md e references/hook-extraction.md. Esses arquivos mostram o que a skill considera complexidade e quais tipos de mudança realmente a reduzem.

Transforme um objetivo genérico em um prompt melhor

A skill funciona melhor quando sua entrada nomeia o componente alvo, o objetivo e quaisquer restrições. Por exemplo, em vez de “refatore este componente”, diga: “Refatore app/components/foo/index.tsx para reduzir a complexidade cognitiva abaixo de 50. Prefira extrair hooks para estado/efeitos e dividir a seção do modal, mas não altere o comportamento nem as props públicas.” Esse nível de especificidade melhora o resultado porque informa à skill o que precisa ser preservado e o que deve ser otimizado.

FAQ da skill component-refactoring

A component-refactoring serve só para o Dify?

Sim, o fluxo component-refactoring for Refactoring foi pensado em torno das convenções do frontend do Dify, dos nomes de comandos e dos caminhos de componentes. Você pode adaptar as ideias para outros lugares, mas as orientações de instalação e uso são mais valiosas se você estiver nesse codebase ou em um monorepo React muito parecido.

Posso usar isso no lugar de um prompt normal?

Pode, mas a skill é melhor do que um prompt genérico quando você precisa de orientação de refatoração repetível e ligada a métricas de complexidade. Um prompt comum pode sugerir uma limpeza ampla; component-refactoring é mais útil quando a próxima ação precisa ser baseada em evidências e limitada pela saída do analisador.

Preciso ser avançado para usar?

Não. A skill é adequada para iniciantes que conseguem identificar um arquivo-alvo e executar os comandos de análise. O principal requisito é conseguir informar o caminho específico do componente e dizer se a prioridade é dividir, extrair hooks ou reduzir a complexidade.

Quando não devo usar?

Não use a skill component-refactoring para componentes simples, wrappers de terceiros ou casos em que você só quer testes sem mudar a estrutura. Se o componente já estiver legível e abaixo do limite, refatorá-lo pode gerar retrabalho desnecessário.

Como melhorar a skill component-refactoring

Forneça métricas de entrada melhores

A forma mais rápida de melhorar o uso de component-refactoring é incluir a saída do analisador na solicitação: pontuação de complexidade, maxComplexity, lineCount e qualquer texto de aviso. Esses detalhes ajudam a skill a focar no ponto real de pressão em vez de tratar todo arquivo grande como igual.

Especifique o estilo de refatoração que você quer

Se você quer um resultado específico, diga isso logo de início. Por exemplo: “Divida primeiro as seções da UI”, “extraia um custom hook para estado/efeitos compartilhados” ou “reduza a renderização condicional no return principal”. Isso é melhor do que um pedido vago como “deixe mais limpo”, porque a skill consegue mapear seu objetivo para o padrão certo nas referências.

Fique atento aos modos de falha mais comuns

Os erros mais frequentes são dividir demais, mover lógica sem simplificá-la e mudar comportamento enquanto se tenta baixar a complexidade. Entradas mais fortes reduzem esses riscos: identifique quais props, side effects e fluxos de modal precisam continuar estáveis e peça mudanças externas mínimas na API.

Itere depois da primeira passagem

Depois da primeira refatoração, rode novamente pnpm analyze-component <path> --json e compare a pontuação com o alvo. Se a complexidade ainda estiver alta, peça à skill para focar no bloco restante mais cheio de branches ou em um único candidato a hook, em vez de reorganizar o arquivo inteiro de novo.