As skills que eu uso todos os dias
Matheus Cardoso
Dezenove skills pro Claude Code, num repositório público. Metade é engenharia e metade é interface. Cada uma é um modo de trabalho: coloca o agente num papel específico, com um trabalho específico e um critério de pronto que ele não pode fingir que cumpriu.
O problema
Toda vez que você abre o Claude Code, você começa do zero. O agente não sabe qual é a sua barra. Não sabe que "funciona na minha máquina" não basta, que segurança não é a última etapa, que interface de template reprova.
Então você se repete. "Checa segurança em todas as camadas." "Roda os testes antes de dizer que terminou." Você diz as mesmas coisas com palavras diferentes toda sessão, e o resultado depende de quão bem você traduziu o seu padrão naquele momento. Isso é variância, e variância em processo é bug.
Uma skill é o padrão escrito uma vez. Um arquivo markdown com frontmatter, sem build, sem runtime, sem dependência.
Instalação
Duas portas. O plugin instala o conjunto como pacote gerenciado que atualiza quando eu publico. O clone coloca os arquivos onde você pode editar. Escolha uma: instalar as duas te deixa com cada skill duas vezes.
# plugin: atualiza junto com o repositório
/plugin marketplace add matheuscarddoso/skills
/plugin install mcardoso-skills@mcardoso
# ou clone, se você quer editar as skills
git clone https://github.com/matheuscarddoso/skills.git ~/Projects/skills
~/Projects/skills/scripts/installDepois, /ask e uma frase descrevendo sua situação. Ele decide qual skill resolve e chama.
As dezenove
Interface
Engenharia
Se você só for adotar três, adote /grill, /review e /designer. Uma evita construir errado, a outra evita entregar errado, e a terceira evita entregar feio.
Como uma skill é feita
A descrição não é enfeite: é ela que decide se o agente alcança a skill. Ela precisa dizer o que a skill é e listar os gatilhos, inclusive as frases que a pessoa realmente digita quando tem o problema.
---
name: investigate
description: Diagnóstico disciplinado de bug difícil ou regressão de
performance, por fases com trava entre elas. Use quando algo está
quebrado e a causa é desconhecida, quando o usuário disser "tá lento",
"não funciona", "por que isso quebrou".
---
## Fase 3: Minimize
Corte tudo que não é necessário pro vermelho. Metade da entrada,
metade do caminho de código, uma dependência de cada vez. Continua
vermelho, o corte fica. Ficou verde, o corte tocou a causa.
**Trava:** nada mais pode ser removido sem o vermelho virar verde.O resto é passo com critério de pronto verificável. "Até estar alinhado" convida o agente a declarar vitória cedo. "Nada mais pode ser removido sem o vermelho virar verde" não convida.
Quem chama
As dezenove dividem num eixo só: quem pode chamar. Dez só respondem quando você digita, porque auditoria completa que o agente dispara sozinho sai caro e no meio do seu caminho.
As outras nove respondem ao agente também, e é onde está a diferença que eu mais sinto no dia. Quando alguém diz "tá lento e não sei por quê", ele vai pro diagnóstico em fases em vez de dar palpite. E quando ele está escrevendo um componente, ele alcança a11y e polish enquanto escreve, em vez de eu descobrir o problema na revisão.
O custo em tokens
Skill é contexto, e contexto é dinheiro e atenção. Suíte que cobra caro por chamada vira suíte que você deixa de usar, e a melhor skill do mundo, não usada, não faz nada. Então custo aqui é restrição de projeto, não otimização depois.
A descrição de toda skill instalada fica no contexto em toda sessão, tenha ela sido usada ou não. É o único custo que você paga sempre, e por isso tem o orçamento mais duro. O corpo carrega só o que toda execução precisa; o que só algumas alcançam vive em references/, atrás de um link com a condição escrita.
Na prática: a suíte inteira soma 42 mil tokens e nenhuma sessão paga isso. /security numa passada rápida custa mil, e a auditoria completa com os catorze domínios custa quase quatro mil. Você paga pelo que usa.
$ node scripts/skills.mjs bill
skill chamada + references refs descrição
--------------------------------------------------------------
ask 571 571 0 47
grill 946 946 0 90
a11y 1226 3296 3 98
color 1210 3194 3 72
designer 1341 2584 2 89
layout 1345 2720 2 85
microcopy 1137 1965 1 56
polish 1378 3376 3 95
teardown 1159 1796 1 80
typography 1230 2485 2 79
variant 1245 1857 1 77
deploy 705 1240 1 75
engineer 1258 4613 6 105
investigate 849 849 0 79
kickoff 1011 3620 4 79
qa 751 1213 1 83
review 798 1284 1 79
security 998 3937 4 92
tdd 737 737 0 61
--------------------------------------------------------------
Sempre carregado (soma das descrições): 1550 tokens de 1600
Chamada mais cara: 1378 tokensE o orçamento quebra o build. Dobrar a suíte de onze pra dezenove skills levou o sempre-carregado de 899 pra 1.550 tokens, e o teto de 1.600 não subiu: o que pagou a conta foi cortar as listas de gatilho pros termos que de fato distinguem uma skill da vizinha. A próxima entra apertando outra descrição. Orçamento que não quebra o build não é orçamento, é intenção.
Nenhuma assume linguagem
O corpo de cada skill fala em capacidade, não em ferramenta: "o analisador estático do projeto, no nível que ele mantém", e não "PHPStan no nível 6". Isso não é diplomacia. É o que faz a skill continuar valendo quando você troca de stack no meio de um projeto.
O específico vive em references/stacks/, e a skill lê só o arquivo da stack que ela detectou. Acrescentar Python e TypeScript ao /engineer subiu o custo profundo dele, e a chamada quase não mexeu, porque um projeto Python não paga pelos outros dois.
Mais
O repositório é MIT e as skills são markdown que você pode ler em uma sentada. Três repositórios moldaram ele, e vale ler os três: as skills do Rodrigo deram a substância, as do Matt Pocock a arquitetura, e a gstack do Garry Tan o rigor de suíte. Código em matheuscarddoso/skills.