Lennith/MyCodexSkills

Refatoração Enxuta de Código

Limite de Acionamento

Use esta skill apenas quando o usuário explicitamente quiser uma simplificação estruturada ou refatoração convergente.

Não acione para:

• pequenas limpezas
• correções de bugs de rotina
• renomeações avulsas
• refatorações comuns que não necessitam de um fluxo de trabalho convergente dedicado

Modos

Escolha um modo por execução:

• quick (rápido): passada convergente leve para uma área pequena ou bem delimitada
• strict (estrito): passada formal de refatoração com rastreabilidade total e portões de mesclagem

Use quick como padrão, a menos que o usuário solicite uma refatoração formal, auditável ou sensível a lançamentos.

Entradas Necessárias

• repo_path: caminho absoluto para o repositório Git
• refactor_goal: objetivo de convergência em uma linha
• scope: escopo opcional de caminho ou módulo
• mode: quick ou strict
• target_branch: obrigatório apenas para strict, padrão master

Regra Central

Este fluxo de trabalho não preserva compatibilidade externa antiga por padrão, mas deve preservar o contrato atual pretendido do sistema escopado.

Nunca altere contratos de backend, semântica de resposta ou padrões de asserção apenas para fazer os testes passarem.

Modo Rápido (Quick)

Use quick quando a tarefa for delimitada e o usuário busca principalmente convergência, não uma trilha formal de artefatos.

Passos necessários:

1. Declare o objetivo, escopo e a principal complexidade a ser removida.
2. Mantenha uma lista curta de ações na conversa ou em uma nota local mínima, se útil.
3. Aplique apenas alterações escopadas vinculadas a essa lista de ações.
4. Preserve contratos de backend, semântica de resposta e padrões de asserção.
5. Execute validação focada na área alterada.
6. Se a validação sugerir divergência entre backend e teste, pare e execute o portão de divergência de contrato antes de quaisquer novas edições.
7. Relate qual complexidade foi removida, o que permaneceu e qualquer risco remanescente.

Artefatos em ./slim_refactor/ são opcionais no modo quick.

Modo Estrito (Strict)

Use strict quando a refatoração precisar ser rastreável, auditável ou controlada por portões de mesclagem.

Portões obrigatórios:

1. Crie e use um branch de trabalho dedicado. Nunca edite diretamente no branch alvo.
2. Escreva o design antes das edições de código.
3. Rastreie artefatos sob ./slim_refactor/:
   • todolist.md
   • plan.md
   • report.md
4. Preserve contratos de backend, semântica de resposta e padrões de asserção.
5. Execute revisão a cada rodada de alterações.
6. Execute o portão de divergência de contrato sempre que a validação sugerir divergência entre backend e teste.
7. Execute o portão completo do fluxo de trabalho antes da mesclagem.

Portão de Divergência de Contrato

Use este portão sempre que os testes falharem de uma forma que possa refletir uma divergência de contrato, em vez de uma regressão real.

Ações necessárias:

1. Pare as alterações de implementação até que a classificação esteja completa.
2. Compare o comportamento atual, o contrato atual pretendido e as expectativas do teste.
3. Lance uma revisão de subagente independente quando subagentes estiverem disponíveis.
4. Se subagentes não estiverem disponíveis, execute uma revisão local explícita como fallback e registre esse fallback na saída da rodada.
5. Classifique a divergência como exatamente uma de:
   • backend_regression: o comportamento do backend está errado para o contrato atual pretendido.
   • stale_tests: os testes estão defasados em relação ao contrato atual pretendido.

Ações permitidas após a classificação:

• backend_regression: corrija o comportamento do backend para o contrato atual pretendido. Não enfraqueça os testes para ocultar o problema.
• stale_tests: atualize apenas os testes afetados ou pule esses testes para esta rodada. Não relaxe contratos de backend ou padrões de asserção.

Se os testes forem pulados, relate a condição do portão desatualizado, o escopo pulado e o acompanhamento necessário antes de encerrar a rodada.

Fluxo de Trabalho de Execução

Rápido (Quick)

1. Confirme o objetivo, escopo e alvo de validação.
2. Remova complexidade não essencial com o menor conjunto coerente de alterações.
3. Prefira deleção e convergência em vez de novas abstrações.
4. Preserve o contrato atual pretendido do backend enquanto altera a estrutura.
5. Valide o escopo afetado.
6. Se a validação sugerir divergência contrato/teste, execute o portão de divergência de contrato antes de mais edições.
7. Resuma o resultado da convergência e o risco residual.

Estrito (Strict)

1. Faça checkout e sincronize target_branch.
2. Registre BASE_SHA.
3. Crie branch codex/refactor/<topic>-<YYYYMMDD>.
4. Crie ou atualize ./slim_refactor/todolist.md.
5. Crie ou atualize ./slim_refactor/plan.md.
6. Implemente apenas ações declaradas no plano.
7. Preserve o contrato atual pretendido do backend enquanto converge a estrutura.
8. Execute revisão para cada rodada de alteração e registre as descobertas em ./slim_refactor/report.md.
9. Se a validação sugerir divergência contrato/teste, execute o portão de divergência de contrato e registre o tipo de revisor mais a classificação.
10. Execute o portão completo do fluxo de trabalho.
11. Finalize report.md com rastreabilidade e decisão de mesclar ou bloquear.

Requisitos de Saída

Sempre relate:

• complexidade removida
• estrutura convergida
• resultado da validação
• risco remanescente
• invariantes de contrato mantidas ou corrigidas
• classificação de divergência, quando aplicável
• tipo de revisor (subagent ou local_fallback) quando uma revisão de divergência ocorreu
• testes alterados ou pulados quando testes desatualizados foram encontrados

Para strict, também relate:

• nome do branch
• caminhos dos artefatos
• resultado da revisão
• decisão de mesclar ou bloquear

Referências

• references/workflow-checklist.md
• references/design-spec-template.md
• references/todolist-template.md
• references/plan-template.md
• references/report-template.md