🎯 Precisão de triggering: o sinal invisível
Iniciantes olham se a skill dispara. Experts olham se ela dispara nos casos certos e não nos near-misses. Uma skill que aciona em tarefa parecida-mas-errada injeta contexto irrelevante e degrada a resposta — pior que não disparar.
✓ Triggering preciso
- ✓Dispara nos should-trigger (alta cobertura)
- ✓Silencia nos near-misses (alta precisão)
- ✓postgres-skill NÃO aciona em "mongo query"
✗ Triggering impreciso
- ✗Aciona em qualquer menção a "database"
- ✗Falso positivo gasta contexto e confunde
- ✗Falso negativo: nunca aparece quando precisa
💡 Pro tip
Monte um conjunto de should-trigger E should-NOT-trigger (os near-misses). Uma description só está boa quando acerta os dois. Otimize contra os near-misses, não só contra os acertos óbvios.
🪙 Economia de tokens e contexto
A description fica sempre no contexto (nível 1). O corpo entra quando dispara (nível 2). Bundled resources só sob demanda (nível 3). Uma skill cara em tokens rouba espaço de todas as outras — experts medem isso.
| Nível | O que carrega | Quando |
|---|---|---|
| 1 | name + description (~100 palavras) | sempre no contexto |
| 2 | corpo do SKILL.md (<500 linhas) | quando dispara |
| 3 | scripts / references / assets | sob demanda |
O custo escondido das skills sempre-ativas
Cada description instalada consome contexto o tempo todo. 30 skills com descriptions inchadas = milhares de tokens gastos antes de qualquer tarefa. Por isso a description densa-e-curta não é estética: é orçamento.
💡 Pro tip
Empurre tudo que não é gatilho para o nível 3 (bundled). Se o detalhe não é lido em toda invocação, ele não pertence ao corpo — vira arquivo carregado sob demanda.
📜 Ler transcripts para achar trabalho desperdiçado
O sinal que ninguém vê no skills.sh está no seu próprio transcript. Releia uma sessão real: onde o agente refez a mesma coisa, pediu confirmação à toa, ou ignorou a skill que deveria ter usado? Aí mora o trabalho desperdiçado.
Procure repetição
O agente reescreveu o mesmo boilerplate três vezes? Vira um script bundled da skill.
Procure não-disparo
A skill certa existia e não acionou? A description está fraca no QUANDO — ajuste o trigger.
Procure disparo errado
Uma skill apareceu sem necessidade? Near-miss — aperte a description para excluí-lo.
💡 Pro tip
Transcript é o melhor eval grátis que existe. Antes de instalar mais skills, leia uma sessão e pergunte: o que se repetiu? O que falhou em silêncio? Cada padrão é um ajuste de skill.
📊 Pass-rate de evals e assertions não-discriminantes
Um eval que sempre passa não mede nada. O sinal de expert é a assertion discriminante: uma que falha sem a skill e passa com ela. Se o baseline já passa, a assertion não está medindo a contribuição da skill.
✗ Assertion não-discriminante
assert output.contains("function")
# passa com OU sem a skill → inútilPass-rate 100% que não distingue baseline de com-skill é falso conforto.
✓ Assertion discriminante
assert migration.has_down_step() # falha sem a skill, passa com ela ✓
Mede exatamente o comportamento que a skill deveria adicionar.
o teste do eval honesto:
baseline (sem skill) → pass-rate 30% com a skill → pass-rate 90% delta = 60pp → a skill comprovadamente ajuda baseline 95% / com-skill 96% → assertion não discrimina
💡 Pro tip
Sempre rode o baseline. Pass-rate alto só importa se o baseline for baixo. O número que vale é o delta entre com-skill e sem-skill.
🎲 Variância e flakiness
Uma rodada de eval não basta. O modelo é estocástico: a mesma skill pode passar numa execução e falhar na seguinte. Experts rodam o eval várias vezes e olham a variância — um pass-rate de 90% com alta flakiness é menos confiável que 80% estável.
mesma skill, 5 execuções:
skill A: 90 88 91 89 90 → média 89,6 σ baixo → confiável skill B: 100 60 95 55 90 → média 80,0 σ alto → flaky
✓ Como reduzir flakiness
- ✓Instruções imperativas e inequívocas
- ✓Explicar o porquê (o agente generaliza mais estável)
- ✓Rodar N vezes e reportar média + desvio
✗ Sinais de flakiness
- ✗Resultado muda muito entre execuções
- ✗Instruções ambíguas ou contraditórias
- ✗Avaliar com uma única rodada
💡 Pro tip
Reporte sempre média ± desvio, nunca um número solto. Estabilidade é qualidade: prefira a skill consistente à que às vezes brilha e às vezes despenca.
⚠️ Quando uma skill popular ainda é ruim
Installs altos não são prova. Lembre da lei de potência: as top 100 = 43,7% de todos os installs e só 0,3% (131 skills) passam de 100k — há viés de early-mover e efeito de marca. Uma skill popular pode ser ruim para você.
✗ Popular mas problemática
- ✗100k installs mas sem commit há um ano (abandonada)
- ✗Escopo inchado que dispara no seu fluxo errado
- ✗Para outro stack — popular em React, inútil no seu Vue
- ✗Hype de early-mover, não qualidade sustentada
✓ O que checar além do install
- ✓Último commit recente, issues respondidas
- ✓Fit com o SEU stack e fluxo
- ✓Triggering preciso no seu caso real
- ✓Delta de eval no seu transcript, não no hype
A virada de chave do expert
Iniciante instala pelo número grande. Expert instala pela evidência no próprio fluxo: triggering preciso, custo de contexto baixo, delta de eval real, manutenção viva, fit com o stack. Install count é onde você começa a investigar — nunca onde termina.
✅ Resumo do Módulo
Próximo:
Trilha 3 — 🧬 Anatomia de uma Skill. Você já sabe julgar, criar e enxergar os sinais finos; agora vamos abrir o SKILL.md por dentro: frontmatter, corpo e progressive disclosure.