Super Code Skill

Visão Geral

Produza código que seja curto, correto, idiomático e de fácil manutenção — nessa ordem de prioridade. Esta habilidade aborda dois tipos distintos de ineficiência que devem ser corrigidos independentemente:

1. Ineficiência de tokens de código — o artefato em si está inchado (linhas desnecessárias, código repetitivo, superabstração)
2. Ineficiência de tokens de geração — como o agente opera durante uma sessão (reescritas de arquivo completo, arquivos não solicitados, preenchimento de texto antes/depois das alterações)

Ambos importam. Corrigir apenas um não é suficiente.

Quando Usar Esta Habilidade

• Aplique esta habilidade automaticamente em TODAS as tarefas de codificação no IDE.
• Use sempre que o usuário pedir para escrever, editar, refatorar, gerar ou revisar código em qualquer idioma.
• Este é um estilo padrão, não um passe sob demanda — aplique-o sempre.

Ordem de Prioridade (nunca viole esta classificação)

Correctness → Clarity → Necessary robustness → Conciseness → Micro-performance

Conciseness nunca vence correção ou legibilidade. Se uma compressão remover o tratamento de erro para um caso que pode realmente ocorrer, ou produzir código que um humano não conseguiria ler em seis meses, desfaça essa compressão específica. Código ruim e curto é pior do que código correto e longo.

Fluxo de Trabalho — aplique a cada tarefa de codificação

Etapa 1: Comprometa-se com a forma mínima correta ANTES de escrever

Antes de tocar em um arquivo, decida:

• Qual é a menor área de superfície que resolve corretamente este problema?
• O que o chamador realmente precisa desta função/classe/módulo?
• Existe uma primitiva da biblioteca padrão/framework que já faz isso?

Escreva isso mentalmente (não em um bloco de texto para o usuário). Esta é a forma alvo.

Etapa 2: Escreva usando padrões idiomáticos da linguagem

Leia o arquivo de referência relevante para o idioma em uso:

• Bash/Shell → bash/SKILL.md
• C → c/SKILL.md
• C++ → cpp/SKILL.md
• C# → csharp/SKILL.md
• Dart/Flutter → dart/SKILL.md
• Elixir/Erlang → elixir/SKILL.md
• Go → go/SKILL.md
• Java → java/SKILL.md
• Kotlin/Compose → kotlin/SKILL.md
• PHP → php/SKILL.md
• Python → python/SKILL.md
• Ruby → ruby/SKILL.md
• Rust → rust/SKILL.md
• Scala → scala/SKILL.md
• Swift → swift/SKILL.md
• TypeScript/JavaScript → typescript/SKILL.md

Aplique os padrões idiomáticos desse arquivo. Eles substituem código imperativo verboso por equivalentes corretos e concisos que ainda são legíveis.

Etapa 3: Passagem de compressão no seu próprio rascunho

Antes de apresentar qualquer código, escaneie-o em busca de:

Etapa 4: Verificação de segurança — execute isso antes de apresentar

Pergunte a si mesmo (silenciosamente):

• Removi o tratamento de um caso que pode realmente acontecer?
• Tornei isso mais difícil de ler para um humano daqui a seis meses?
• Sacrifiquei correção ou segurança para economizar linhas?

Se sim para qualquer um: desfaça essa compressão específica e mantenha o restante.

Etapa 5: Apresente a saída — regras de tokens de geração

Sempre:

• Edite arquivos por meio de patches/diffs direcionados, não reescritas completas, a menos que o arquivo seja novo ou a alteração toque em mais de 70% das linhas
• Apresente apenas o que foi solicitado

Nunca:

• Gere arquivos não solicitados (testes, READMEs, configurações, tipos) a menos que o usuário tenha pedido
• Adicione blocos de texto antes/depois do código explicando o que você está prestes a fazer ou acabou de fazer — apenas faça
• Reexplique o requisito do próprio usuário antes de escrever
• Reafirme o que mudou em um parágrafo após mostrar o diff — o diff é autoevidente

Lista de Verificação Universal de Anti-Padrões

Estes se aplicam em todos os idiomas. Os arquivos específicos do idioma estendem esta lista.

Comentários

• ❌ // Loop through the list and add each item → ❌ excluir
• ✅ // Order matters: process refunds before charges → ✅ manter (explica por quê)
• Regra: se o comentário puder ser gerado mecanicamente a partir da leitura do código, ele não agrega valor

Codificação defensiva

• Trate apenas casos de erro que podem realmente ocorrer dado o local da chamada
• Se o chamador garante não nulo, não verifique nulo dentro da função
• Se um bloco catch só pode registrar e relançar, considere remover o try/catch

Abstrações

…