Disciplina de Código Mínimo
Use esta skill para aplicar uma disciplina de código mínimo (YAGNI-ladder) ao planejar e escrever mudanças de código. Ela mantém os diffs pequenos e obviamente corretos, sem sacrificar as verificações que mantêm os usuários seguros.
Esta skill complementa a ai-slop-cleaner: essa skill limpa o slop depois que ele chega; esta impede que ele seja escrito.
Quando Usar
Use esta skill quando:
- o usuário solicitar uma implementação mínima, enxuta, YAGNI ou com o menor diff possível
- um plano ou mudança em andamento estiver crescendo além do solicitado
- escrever código novo onde há risco de expansão de escopo, reinvenção de helpers ou generalização especulativa
- revisar um diff proposto quanto ao tamanho antes da implementação
Quando Não Usar
Não use esta skill quando:
- o usuário explicitamente solicitar uma construção ampla, rica em funcionalidades ou preparada para o futuro (o escopo explícito deles prevalece)
- a tarefa for um esboço exploratório que o usuário marcou como descartável
- a pressão por minimização tocar em comportamento protegido (veja Itens Não Negociáveis)
A Disciplina
Existência primeiro. Pergunte se a mudança precisa existir; pule trabalho que serve apenas a uma necessidade especulativa futura.
Reutilizar antes de escrever. Busque no código-fonte um helper, tipo ou padrão existente antes de escrever algo novo. Nunca copie um helper que já existe a alguns arquivos de distância — reutilize-o ou extraia-o para um local compartilhado.
Escada de dependências. Recorra primeiro à biblioteca padrão, depois à capacidade nativa da plataforma, e então a uma dependência já instalada. Código escrito manualmente é o último recurso. Não introduza uma nova dependência quando algumas linhas de código bastarem, a menos que o usuário tenha solicitado ou aprovado explicitamente.
Entender antes de minimizar. Leia o código afetado e siga seu caminho de execução primeiro. Entregue o diff correto mais curto assim que o problema for compreendido — o código que você nunca escreve nunca quebra.
Chato sobre inteligente. Prefira código chato e obviamente correto em vez de código inteligente.
Marque o teto. Registre simplificações deliberadas com um comentário curto nomeando o limite aceito e o que justificaria substituí-lo.
Causa raiz, não sintomas. Corrija bugs na causa raiz compartilhada por todos os chamadores, não com um patch separado para cada sintoma relatado.
Itens Não Negociáveis
Nunca minimize:
- validação em qualquer fronteira de confiança cruzada
- tratamento de erros que protege contra perda de dados
- controles de segurança
- fundamentos de acessibilidade
- escopo que o usuário explicitamente solicitou
Verificação
Antes de relatar a conclusão, confirme:
- cada linha adicionada merece seu lugar (sem generalização especulativa, sem helpers duplicados)
- o diff é o mais curto que resolve corretamente o problema declarado
- os itens não negociáveis estão intactos
- os testes ainda passam e o comportamento permanece inalterado, exceto conforme solicitado