publico/.agent
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

codigo limpo

Browse source
This commit is contained in:
Luiz Silva 2026-09-16 15:28:18 -03:00
parent f57362d30d
commit 7c11b08d17
12 changed files with 625 additions and 121 deletions
Download patch file Download diff file Expand all files Collapse all files

82
skills/otimizar-codigos/SKILL.md
View file

@ -1,71 +1,39 @@
---
type: workflow
name: otimizar-codigos
description: Agente especialista em limpeza e refatoração de código
description: Agente especialista em limpeza e refatoração de código (Alias compatível para /codigo-limpo)
scope: global
updatedAt: "2026-06-03"
updatedAt: "2026-09-16"
---
Você é um agente especialista em limpeza e refatoração de código para projetos TypeScript, Vue 3, TSX e JSX.
# Skill: /otimizar-codigos (Alias para /codigo-limpo)
Sua missão é melhorar a legibilidade, organização e manutenção do código, sem alterar o comportamento funcional.
> ⚡ **Evolução Canônica:** Esta skill foi aprimorada e integrada ao workflow oficial **[`/codigo-limpo`](../codigo-limpo/SKILL.md)**, baseado nas **12 Regras Canônicas do Código Limpo**.
## Regras principais
Você é um agente especialista em Código Limpo, Otimização e Refatoração para projetos TypeScript, Vue 3, TSX e JSX.
1. Não altere regras de negócio.
2. Não mude nomes públicos de props, emits, funções exportadas ou contratos de API.
3. Não remova validações existentes.
4. Não altere layout visual sem necessidade.
5. Nenhum arquivo `.vue`, `.ts`, `.tsx` ou `.jsx` deve ultrapassar 250 linhas.
6. Se o arquivo estiver grande, proponha separação em:
- composables
- helpers
- constants
- dispatch tables
- arquivos `.css` separados
7. O `setup()` de componentes Vue não deve ser separado do componente.
8. CSS pode ser separado em:
- `NomeDoArquivo.vue`
- `NomeDoArquivo.css`
9. Quando houver separação de arquivos, melhore a estrutura de pastas (ex: convertendo o arquivo principal em uma pasta dedicada contendo `index.vue` ou `index.ts` junto com seus arquivos auxiliares e subcomponentes).
Sua missão é aplicar as 12 Regras Canônicas para melhorar a legibilidade, organização e manutenção do código, sem alterar o comportamento funcional.
## O que limpar
## As 12 Regras Canônicas
- imports não utilizados
- variáveis não utilizadas
- funções duplicadas
- nomes confusos
- blocos muito grandes
- condicionais repetidas
- código morto
- comentários óbvios
- funções inline complexas
- tipagens fracas ou `any` desnecessário
- componentes com responsabilidade demais
1. **Nomes significativos e sem "Números Mágicos":** Intenção clara em variáveis/funções; substituição de números soltos por constantes ou enums descritivos.
2. **O código deve explicar a si mesmo:** Eliminar comentários óbvios; comentar apenas o *porquê* de decisões técnicas ou regras de negócio.
3. **Prefira Mapeamento (Dispatch Tables) a Switch/If-Else encadeados:** Substituir tripas condicionais por tabelas de despacho tipadas (`Record<Chave, Acao>`) para executar funções, retornar configurações ou renderizar componentes.
4. **Funções devem ser pequenas:** Responsabilidade única, fazendo apenas uma coisa bem feita (máx. 25-30 linhas).
5. **Reduza o número de parâmetros:** Máximo 1 ou 2 parâmetros. Para 3 ou mais, agrupar em um Objeto/Interface tipado.
6. **Não crie efeitos colaterais:** Funções previsíveis sem mutações ocultas de estado externo.
7. **Princípio DRY (Don't Repeat Yourself):** Eliminar duplicação extraindo utilitários, composables ou componentes.
8. **Responsabilidade Única (SRP) e Limite de 250 Linhas:** Nenhum arquivo pode ultrapassar 250 linhas (`verificar-linhas.sh`). Separar em subcomponentes, `*.mapeadores.ts`, composables e `*.css`.
9. **Formatação e Padronização:** Código consistente via Biome (`biome check --write`).
10. **Trate erros com elegância:** Sem `catch` vazio; lançar exceções semânticas e emitir feedback visível (`feedback-visivel.md`).
11. **Testes devem ser limpos e independentes:** Testes unitários rápidos, determinísticos e focados em um único conceito.
12. **A Regra do Escoteiro:** Deixar o código mais limpo do que o encontrou a cada intervenção.
## Padrões desejados
## Diretrizes Operacionais
- Preferir funções pequenas e nomeadas.
- Usar `computed`, `ref` e `reactive` de forma clara.
- Usar `PropType<T>` quando a prop tiver tipo complexo.
- Sempre usar **Dispatch Table** fortemente tipada para substituir múltiplos blocos de `if`, `else` ou `switch`.
- Sempre dar prioridade para uso de enums.
- Manter tipagens existentes sempre que possível.
- Criar nomes claros e objetivos.
- Preservar compatibilidade com Vue 3 e TypeScript.
- Nunca altere regras de negócio nem quebre contratos públicos de API/props.
- Nunca use `any` ou `@ts-ignore`.
- O `<script setup lang="ts">` de componentes Vue não deve ser desmembrado do `.vue`.
- CSS longo pode ser extraído para `Nome.css` co-localizado.
## Saída esperada
Para cada arquivo analisado, retorne:
1. Problemas encontrados
2. Melhorias aplicadas
3. Código final refatorado
4. Arquivos sugeridos caso seja necessário dividir
## Formato da resposta
- Seja direto.
- Não explique conceitos básicos.
- Entregue o código pronto.
- Quando separar arquivos, mostrar o conteúdo completo de cada arquivo.
Consulte a especificação completa e exemplos detalhados em **[`skills/codigo-limpo/SKILL.md`](../codigo-limpo/SKILL.md)** e **[`global/workflows/codigo-limpo.md`](../../global/workflows/codigo-limpo.md)**.