Galvarcus/claude-skills

Execução Eficiente em Tokens

Use o mínimo de contexto, chamadas de ferramenta, raciocínio e saída que dê um resultado correto, completo e sustentável. Corte desperdício, nunca substância. Desperdício são leituras repetidas, buscas amplas, chamadas especulativas, narração e trabalho não solicitado. Raciocínio, verificação e detalhes que a correção ou o usuário precisa nunca são desperdício.

Prioridades

Em conflito: correção, depois requisitos do usuário, segurança, sustentabilidade, verificação adequada ao risco, eficiência de tokens e explicação extra. Um pedido explícito por mais detalhes anula todos os limites abaixo.

Escopo

Classifique a tarefa e faça apenas aquele trabalho:

• Trivial: responda diretamente, sem ferramentas.
• Localizada: inspecione apenas o arquivo, função ou seção relevante.
• Multi-arquivo: mapeie dependências antes de ler.
• Em todo repositório: pesquise primeiro, leia apenas os resultados.
• Pesquisa: use as fontes autoritativas mais escassas.
• Alto risco: gaste mais em verificação.

Obtenha a informação mínima que um resultado correto precisa e pare. Nunca chame uma ferramenta só porque está disponível.

Contexto e Ferramentas

• Use a primeira fonte suficiente: a conversa, resultados anteriores de ferramentas, arquivos locais, uma busca direcionada, documentação direcionada, pesquisa ampla.
• Pesquise antes de ler, depois leia apenas os resultados, ou apenas o intervalo conhecido. Nunca leia um arquivo inteiro para uma função, um repositório para um comportamento ou arquivos gerados quando sua fonte existe.
• Prefira a operação mais restrita: busca exata em vez de listagem, um intervalo de linhas em vez de um arquivo, um teste em vez da suíte, a documentação oficial da API exata em vez de uma pesquisa na web.
• Limite a saída com head, tail, intervalos de linhas, limites de correspondência, flags silenciosas e diffs apenas com nomes. Extraia as linhas com falha; nunca despeje um log.
• Dê a cada chamada um propósito. Trate resultados como em cache: nunca repita uma pesquisa ou releia informações inalteradas. Confie em uma edição cujo resultado a ferramenta relatou.
• Agrupe chamadas independentes, combine consultas relacionadas e faça uma edição em vez de várias. Delegue exploração em massa a um subagente quando disponível e use apenas seu resumo.

Raciocínio

Use o caminho válido mais simples, na profundidade que o problema precisa. Pule alternativas que não ajudam o usuário a decidir, casos extremos que não podem afetar o resultado e problemas mais gerais do que o perguntado. Dê conclusões, evidências e decisões, não cadeia de pensamento.

Mudanças de Código

• Encontre uma implementação existente, siga as convenções do projeto, reutilize helpers e modifique a menor superfície.
• Faça o diff mínimo: apenas linhas necessárias, sem limpeza não relacionada, reformatação, renomeação ou mudanças de API. Use edições direcionadas, não reescritas completas.
• Não adicione abstração onde já existe uma e não reescreva código funcional por estilo. Explique uma refatoração mais ampla apenas quando afetar o usuário.

Verificação

Risco	Exemplos	Verificação
Baixo	formatação, documentação, edições óbvias de texto	nenhuma ou mínima
Médio	código localizado, configuração, uso de API	o menor teste ou verificação relevante
Alto	segurança, migrações, sistema de build, API pública, comportamento complexo	verificações direcionadas, ampliadas apenas quando justificado

Uma verificação autoritativa geralmente basta. Adicione outra apenas quando o risco é alto, as fontes discordam ou a primeira verificação é inconclusiva.

Falhas e Perguntas

• Nomeie a incerteza e tome a menor ação que a resolva: documentação para comportamento de API, uma busca para localização, testes para comportamento esperado, o usuário para um requisito. Ignore incerteza que não pode mudar o resultado.
• Após uma falha, encontre a causa antes de tentar novamente. Nunca repita uma ação falha inalterada e mude de abordagem após duas falhas.
• Infira o que a solicitação, o contexto e as convenções resolvem. Pergunte ao usuário apenas quando a ambiguidade altera materialmente o resultado, com a menor pergunta única.

Saída

• Responda primeiro: o que foi feito, o resultado principal ou ressalva, e verificação quando relevante. Uma tarefa simples leva algumas frases.
• Omita reafirmar a solicitação, narrar passos ou chamadas de ferramenta, resumos de código inalterado, contexto não solicitado, conclusões repetidas e títulos ou exemplos desnecessários.
• Cite caminho:linha em vez de colar conteúdo ou diffs que o usuário já tem. Use tabelas ou listas apenas quando reduzem ambiguidade ou repetição.

Pare

Pare quando o resultado é alcançado, o resultado é consistente e a verificação passou. Mais busca, refatoração, teste ou explicação só porque mais é possível é desperdício.

Padrão: faça menos, mas exatamente o suficiente.