Agent Skills
(addyosmani.com)- Agent Skills é um scaffolding que força agentes de IA para código a seguir workflows para que não pulem processos de engenharia sênior como especificações, testes, PRs revisáveis e revisão de limites de confiança
- Uma skill é um arquivo Markdown com frontmatter que se parece mais com um workflow do que com um documento de referência, com sequência de etapas, evidências em checkpoints e critérios de término
- As 20 skills do repositório são organizadas em 6 etapas do ciclo de vida — Define, Plan, Build, Verify, Review e Ship — e 7 slash commands:
/spec,/plan,/build,/test,/review,/shipe/code-simplify - Os princípios centrais são processo em vez de prosa, tabelas anti-racionalização, verificação como critério de término, divulgação progressiva e disciplina de escopo;
using-agent-skillsativa apenas as skills adequadas à tarefa - Pode ser usado via instalação pelo marketplace do Claude Code, colocando os arquivos Markdown em
.cursor/rules/no Cursor, ou em ferramentas como Gemini CLI, Codex, Aider, Windsurf e OpenCode; está disponível sob licença MIT
Objetivo e problema
- Agent Skills é um scaffolding para forçar agentes de IA para código a seguir processos de engenharia sênior que eles normalmente pulam por padrão
- Quando recebem uma solicitação de funcionalidade, agentes de IA para código normalmente implementam pelo caminho mais curto e não executam por padrão etapas como escrever especificações, testar primeiro, revisar limites de confiança ou montar PRs que possam ser revisados
- O trabalho de um engenheiro sênior inclui muitas coisas que não aparecem no diff
- Explicitar suposições
- Escrever especificações
- Dividir o trabalho em unidades revisáveis
- Escolher soluções tediosas, mas seguras
- Deixar evidências de que o resultado está correto
- Limitar mudanças a um tamanho que humanos realmente consigam revisar
- A razão de agentes pularem essas etapas é semelhante à de engenheiros juniores: o sinal de recompensa está ajustado para “tarefa concluída”, e não para “tarefa concluída com documento de especificação incluso”
- O repositório Agent Skills já passou de 26K stars e vai além do README, cobrindo por que certas decisões de design foram tomadas, como elas se relacionam ao SDLC padrão e às práticas públicas de engenharia do Google, além de padrões que podem ser reaproveitados mesmo sem instalação
O que uma skill realmente significa
- Uma skill é um arquivo Markdown com frontmatter injetado no contexto do agente conforme a situação, em um formato intermediário entre um trecho de system prompt e um runbook
- Skills não são documentos de referência, nem coleções de conhecimento do tipo “tudo o que você precisa saber sobre testes”
- Uma skill útil é um workflow que o agente realmente segue
- Tem uma sequência de etapas
- Gera evidências em checkpoints
- Termina com critérios de encerramento claros
- Se você colocar no contexto um ensaio de 2.000 palavras sobre boas práticas de teste, o agente pode gerar frases plausíveis e ainda assim pular os testes de verdade
- Em contraste, se você der um workflow que manda escrever primeiro um teste que falha, executá-lo e confirmar a falha, implementar o mínimo necessário para passar, confirmar que passou e então refatorar, o agente passa a ter ações concretas a realizar e um humano consegue verificar o processo
- A distinção central é processo em vez de prosa, workflow em vez de referência, etapas com critério de término em vez de ensaios sem critério de encerramento
- Muitos repositórios de “AI rules” não produzem efeito real justamente porque as regras ficam no nível de ensaio, e não de workflow
Estrutura de SDLC e slash commands
- As 20 skills do repositório são organizadas em 6 etapas do ciclo de vida, sobre as quais ficam 7 slash commands
-
Etapas e comandos
/spec: etapa Define, para decidir o que será construído/plan: etapa Plan, para decompor o trabalho/build: etapa Build, para implementar em slices verticais/test: etapa Verify, para provar o funcionamento/review: etapa Review, para encontrar problemas que escaparam/ship: etapa Ship, para entregar com segurança aos usuários/code-simplify: comando de simplificação aplicado ao longo de todo o fluxo- Essa estrutura segue o mesmo fluxo do SDLC de organizações de engenharia que funcionam bem; o que muda entre empresas é mais o vocabulário
- No Google isso aparece como design doc → review → implementation → readability review → launch checklist; na Amazon, em formas como working-backwards memo e bar raiser
- O novo problema com agentes de IA para código é que a maioria deles pula por padrão a maior parte dessas etapas
- Você pede uma funcionalidade e recebe implementação, mas não especificação, plano, testes, revisão ou checklist de lançamento
- As skills fazem o agente passar pelas mesmas etapas que engenheiros seniores impõem a si mesmos; colocar código em produção sem esses processos leva a incidentes
- Uma funcionalidade complexa pode ativar 11 skills em sequência, enquanto uma correção pequena pode usar apenas 3
- O roteador
using-agent-skillsdecide quais skills se aplicam à tarefa atual, e o workflow se expande de acordo com o escopo real, não com um escopo presumido
Princípios que sustentam o funcionamento
-
1. Processo em vez de prosa
- Workflows podem ser transformados em ação pelo agente; ensaios, não
- O mesmo princípio vale para equipes humanas
- Se o handbook do time tiver 200 páginas, ele não será lido sob pressão; se houver um workflow curto com checkpoints, a chance de execução real é muito maior
-
2. Tabelas anti-racionalização
- A escolha de design mais distinta do Agent Skills — e que outros times deveriam reaproveitar — são as tabelas anti-racionalização
- Cada skill inclui desculpas comuns que um agente ou um engenheiro cansado provavelmente usaria para pular o workflow, junto com respostas pré-escritas para rebater isso
- Exemplos
- “Esta tarefa é simples demais para precisar de especificação” → critérios de aceitação ainda se aplicam. 5 linhas tudo bem; 0 linhas, não
- “Escrevo os testes depois” → “depois” é exatamente o problema. Não existe depois. O teste que falha deve vir primeiro
- “Os testes passaram, então vamos fazer deploy” → testes passando são evidência, não prova. É preciso verificar runtime, comportamento visível ao usuário e se um humano leu o diff
- LLMs são muito boas em racionalizar e conseguem escrever parágrafos plausíveis para justificar que certa tarefa não precisa de especificação ou que certa mudança pode ser mesclada sem revisão
- As tabelas anti-racionalização são refutações pré-escritas para mentiras que o agente ainda nem disse
- Esse padrão também funciona para equipes humanas
- A queda de qualidade em engenharia geralmente não acontece porque alguém decidiu fazer algo ruim, mas porque uma justificativa plausível foi aceita para pular um processo incômodo
-
3. Verificação é inegociável
- Toda skill termina com evidências concretas
- Testes passando, saída limpa de build, trace de runtime mostrando o comportamento esperado ou aprovação de revisor servem como critério de encerramento
- “Parece plausível” não é suficiente
- Esse é o mesmo princípio pelo qual o harness da Anthropic se recupera de falhas, a separação planner/worker/judge do Cursor realmente encontra bugs, e long-running agent se torna recuperável
- Como agentes são geradores, eles precisam de um sinal separado para determinar quando o trabalho está concluído, e as skills embutem esse sinal em cada workflow
-
4. Divulgação progressiva
- As 20 skills não são todas colocadas no contexto no início da sessão
- Só as skills necessárias para a etapa atual são ativadas
- Uma pequena meta-skill,
using-agent-skills, atua como roteador para decidir quais skills se encaixam na tarefa atual - Isso aplica as lições de harness engineering no nível das skills
- Todo token carregado no contexto prejudica desempenho em algum lugar, então só o que for relevante deve ser carregado; o resto deve ficar em disco
- Divulgação progressiva é a maneira de colocar uma biblioteca de 20 skills em um espaço de 5K tokens sem contaminar o contexto inteiro
-
5. Disciplina de escopo
- A meta-skill codifica como princípio inegociável “mexa apenas no que foi pedido”
- Não se deve refatorar sistemas adjacentes, remover código que não foi totalmente entendido nem decidir reescrever o arquivo inteiro só porque viu um TODO
- Um agente pode tentar consertar um único bug e, no processo, “modernizar” 3 arquivos não relacionados
- Disciplina de escopo é o maior fator para determinar se o PR do agente é mesclável ou se precisará ser revertido
- Isso também combina bem com as normas de code review do Google, nas quais revisores podem bloquear um PR que tenta fazer mais de uma coisa
Conexão com práticas de engenharia do Google
- Agent Skills incorpora muitas práticas de Software Engineering at Google e da cultura pública de engenharia do Google
- Muitas das coisas que fazem software em escala Google funcionar foram documentadas publicamente, e são justamente as partes que agentes mais costumam pular
-
Correspondência entre skills e práticas
api-and-interface-design: reflete a Hyrum’s Law. Todo comportamento observável de uma API acaba tendo alguém dependente dele, então isso precisa entrar no designtest-driven-development: reflete a pirâmide de testes~80/15/5e a Beyoncé Rule. O princípio é “se gostou, deveria ter colocado um teste”; quem captura bugs são os testes, não mudanças de infraestrutura- DAMP over DRY em testes: a filosofia de testes do Google entende que código de teste deve ser legível como especificação, mesmo aceitando alguma duplicação. Testes abstraídos demais são um antipadrão conhecido
code-review-and-quality: reflete tamanho de PR em torno de~100-line PRe rótulos de severidade Critical / Nit / Optional / FYI. PRs grandes tendem a não ser realmente revisados e a receber aprovação quase automáticacode-simplification: reflete a Chesterton’s Fence. Não se deve remover algo antes de entender por que aquilo foi colocado aligit-workflow-and-versioning: reflete trunk-based development e atomic commitsci-cd-and-automation: reflete Shift Left e feature flags. Problemas devem ser detectados o mais cedo possível, e deploy deve ser separado de releasedeprecation-and-migration: reflete code-as-liability. Toda linha mantida terá de ser gerenciada para sempre, então superfícies menores são preferíveis- Esses conceitos não são novos, mas não vêm embarcados por padrão nos agentes
- Mesmo que um frontier model tenha lido a expressão “Hyrum’s Law” nos dados de treino, ele não vai aplicá-la automaticamente ao projetar uma API às 3 da manhã
- As skills fazem essas práticas entrarem no trabalho real do agente
Como usar na prática
-
Modo 1: instalar via marketplace
- Se você usa Claude Code, instale com os comandos abaixo
/plugin marketplace add addyosmani/agent-skills /plugin install agent-skills@addy-agent-skills- Após a instalação, é possível usar os slash commands
/spec,/plan,/build,/test,/review,/shipe/code-simplify - O agente ativa automaticamente as skills relevantes conforme o contexto
- Para a maioria das pessoas, esse é o modo recomendado para começar
-
Modo 2: colocar o Markdown na ferramenta que preferir
- As skills são arquivos Markdown comuns com frontmatter
- Usuários do Cursor podem colocá-las em
.cursor/rules/ - O Gemini CLI tem seu próprio caminho de instalação
- Codex, Aider, Windsurf, OpenCode e outras ferramentas que aceitam system prompts também conseguem lê-las
- Mais importante que a ferramenta em si é o workflow que está por baixo
-
Modo 3: ler como especificação
- Mesmo sem instalar nada, as skills funcionam como uma descrição documentada de como fazer boa engenharia com agentes de IA
- Você pode ler
code-review-and-quality.mde aplicar a estrutura de 5 eixos ao processo de review do seu time - Pode ler
test-driven-development.mde usá-lo em discussões como “devemos escrever testes primeiro?” - Pode ler as meta-skills e levar os 5 princípios inegociáveis para o seu próprio
AGENTS.md - Um bom ponto de partida pode ser escolher 4 ou 5 skills mais próximas do problema que mais dói hoje, definir o workflow que você quer impor e então instalar ou construir um runtime que faça essa imposição
Padrões que dá para reaproveitar sem instalar
-
Transformar anti-racionalização em prática de equipe
- O time deve escrever as mentiras que conta para si mesmo
- Exemplos: “arrumamos os testes depois do lançamento”, “essa mudança é pequena demais para precisar de design doc”, “tem monitoramento, então está tudo bem”
- Anexar uma refutação a cada frase e colocá-las no
AGENTS.mdou na wiki de engenharia reduz discussões e ajuda a conter atalhos cansados de sexta-feira à tarde
-
Escrever documentação interna como processo, não como prosa
- Se você está escrevendo um documento de 2.000 palavras chamado “como abordamos X”, então está criando material de referência
- Se isso for convertido em um workflow com checkpoints, o documento pode cair para 400 palavras e ainda assim ter muito mais chance de ser executado na prática
- Esse princípio vale para guias de onboarding, runbooks e agent skills
-
Tratar verificação como critério sólido de encerramento
- A última etapa de todo trabalho deve ser “gerar evidência”
- Isso vale para agentes, engenheiros e trabalho individual
- A evidência pode ser uma suíte de testes verde, screenshot, logs ou aprovação de review — qualquer coisa que comprove que o trabalho terminou
- Sem evidência, o trabalho não terminou; “parece plausível” não fecha o ciclo
-
Aplicar divulgação progressiva a qualquer conjunto de regras
- Em vez de escrever um handbook de 50 páginas, escreva um pequeno roteador que leve a pequenos capítulos adequados ao contexto
- Isso vale para
AGENTS.md, runbooks, playbooks de incidentes e qualquer documento que precise ser lido sob pressão
-
Cinco princípios inegociáveis para colocar no
AGENTS.md- Suposições precisam ser explicitadas antes de construir. Suposições erradas mantidas em silêncio são um dos modos de falha mais comuns
- Se requisitos entrarem em conflito, é preciso parar e perguntar. Não se deve adivinhar
- Quando necessário, deve-se discordar. Agentes e engenheiros não são yes-men
- Soluções tediosas e claras devem ser preferidas. Esperteza custa caro
- Só se deve mexer no que foi pedido
Lugar dentro do harness
- Skills são uma camada dentro da visão mais ampla de agent harness engineering
- O harness inclui tudo o que foi construído ao redor do modelo, e skills são pedaços reutilizáveis de workflow divulgados progressivamente dentro do system prompt
- Skills ficam ao lado de
AGENTS.md, hooks, tools e session logAGENTS.md: funciona como um conjunto de regras em constante atualização- hooks: camada determinística de imposição
- tools: ações que o agente pode executar
- session log: memória persistente
- skills: responsáveis pelos processos de engenharia sênior
- Skills são ainda mais importantes para long-running agents do que para agentes de chat
- Execuções longas amplificam todos os atalhos
- Em uma sessão de 10 minutos, um agente que pulou testes pode criar um bug
- Em uma sessão de 30 horas, um agente que pulou testes pode produzir no fim uma arqueologia de depuração em que ninguém mais lembra a intenção original
- Quanto maior o tempo de execução, mais esse scaffolding de engenharia sênior precisa ser imposto, e não apenas sugerido
- A portabilidade do formato de skill também importa
- O mesmo arquivo
SKILL.mdpode ser usado no Claude Code, no Cursor com rules, no Gemini CLI, no Codex e em outros harnesses que aceitam conteúdo de system prompt - Você escreve o workflow uma vez e o runtime pode impô-lo, e essa é a vantagem do formato Markdown com frontmatter em comparação com prompt engineering sob medida
Conclusão
- Agentes de IA para código se comportam como engenheiros juniores extremamente capazes, mas sem instinto para o trabalho que não aparece no diff
- Tarefas de engenharia sênior como explicitar suposições, controlar o tamanho da mudança, escrever especificações, deixar evidências e recusar a fusão de mudanças irrevisáveis provavelmente serão puladas, a menos que o agente seja impedido de fazê-lo
- O trabalho cada vez mais importante é codificar essa disciplina de uma forma da qual o agente não consiga escapar com retórica
- Skills são uma dessas formas, e o núcleo está em tabelas anti-racionalização, divulgação progressiva, processo em vez de prosa, verificação como critério de término e uma estrutura portátil para práticas do Google que já funcionam
- O repositório Agent Skills está disponível sob licença MIT, e a visão mais ampla de scaffolding continua em Agent Harness Engineering e Long-running Agents
1 comentários
Comentários do Hacker News
É quase um óleo de cobra. Vale a leitura e parece plausível, mas no fim continua sendo óleo de cobra
O motivo é que um modelo caça-níquel pode deixar passar a qualquer momento requisitos obrigatórios escritos em
AGENTS.md,memory.mde dezenas de arquivos Markdown de skills, e isso é praticamente garantidoEsse tipo de abordagem com harness finge que LLMs seguem regras de forma rígida e perfeita, e que o problema é só não termos escrito regras suficientes e com clareza suficiente. Isso é um erro fundamental de compreensão sobre como LLMs funcionam
No fim, a única alternativa confiável, embora apenas relativamente mais confiável, continua sendo revisão e supervisão humanas, de preferência duas vezes seguidas
Todo o resto é óleo de cobra, e quando se chega a esse ponto dá para perceber que o ganho de produtividade prometido também é. Porque ler código e construir um modelo mental é muito mais difícil do que transformar em código algo para o qual você já tem um modelo mental
Leitura de código depende do tipo de código, mas como qualquer habilidade fica mais fácil com prática. Isso já era comum em situações em que você precisa lidar com codebases grandes e complexos que existem há muito tempo, onde se lê muito mais código do que se escreve
Fica ainda mais fácil quando você já tem um modelo mental do código por meio de documentação, experiência anterior, perguntar a colegas etc.
Isso também é possível com agentes. Normalmente você já conhece bem a estrutura do código antes de escrever um prompt para a IA, e se dividir o trabalho com cuidado a revisão do código gerado fica muito fácil. É como reler um livro que você já leu; raramente algo está errado, e quando está, salta aos olhos e você pega quase tudo logo no começo. De qualquer forma, o ganho de velocidade é grande
Mas nos últimos meses usei spec-kit, ou seja, esse tipo de uso de IA, e na prática foi surpreendentemente bom. Estou construindo coisas excelentes e ainda não vivi os problemas levantados como hipótese. Podem acontecer um dia, e por isso sigo com cautela
Mesmo assim, depois de usar isso diretamente por um tempo razoável, não dá para simplesmente descartar como óleo de cobra. Trabalho como programador há mais de 30 anos e sinto que tenho um bom faro para o que funciona e o que não funciona de verdade
No futuro quero ver harnesses que exijam, não apenas peçam. Se foi mandado ficar em modo de planejamento e seguir um procedimento específico, um agente que não siga isso deveria ser morto. Mesmo sem ser perfeito, isso teria de ser melhor do que o modo atual com humano no circuito
Dizem que “skills são arquivos Markdown com frontmatter injetados no contexto do agente quando apropriado”, mas quem decide se é apropriado é a própria LLM
Dizem também que “é uma série de passos que o agente segue, terminando com checkpoints que produzem evidências e critérios claros de encerramento”, mas quem pode decidir seguir ou não esses passos também é a LLM
$my-skill, e aí essa skill de fato é injetada no contexto. Depois disso, a LLM a segue tanto quanto segue o prompt, as instruções e outras partes do contextoMal posso esperar pelo dia em que todo mundo perceber que passou mais de um ano fuçando em agentes e só experimentou uma sensação de produtividade falsa
Isso não bate em nada com a minha experiência real. Gostaria de saber que experiência levou alguém a ter tanta certeza de um colapso inevitável da programação com IA. É uma crença filosófica de que IA é moralmente ruim, ou a pessoa realmente tentou construir algo com IA, explorou o suficiente e chegou a uma conclusão forte?
Escrevo código todos os dias há mais de 30 anos, e profissionalmente há mais de 20. Já vi modas irem e virem, e também vi vários avanços reais que mudaram a forma de trabalhar. Quanto mais projetos construo com IA, mais convencido fico de que isso é uma mudança duradoura e fundamental na forma de criar software e usar computadores
Também vejo a IA melhorar, e me vejo ficando mais habilidoso em realmente concluir trabalho com ela. Esse trabalho já foi testado com carga de produção no mundo real. Você pode não gostar do que está acontecendo e não gostar da sensação de trabalhar com IA, mas isso não significa que ela não esteja entregando valor real para as pessoas e fazendo trabalho real
Nós entramos de cabeça no Claude Code por volta de setembro e conseguimos acompanhar melhorias com sucesso. Estamos entregando funcionalidades usadas em produção de verdade. Isso vale para infraestrutura, implementação de lógica de negócio, frontend e backend
Não vejo as pessoas desperdiçando tanto tempo assim. Concordo, porém, que a maioria desses posts é besteira, inclusive este. Ainda assim, desenvolvimento com IA já está acontecendo em muitas empresas pelo mundo
Não acho que workflows no estilo agente tenham chegado lá ainda, mas implementações de skills usadas manualmente para trabalhar lado a lado com a IA com certeza são boas. Na nossa empresa temos focado bastante em sandboxing e skills seguras ultimamente
Não acho que acertamos ainda no desenvolvimento de funcionalidades, mas a skill de review e a skill de Grafana que escrevemos ficaram bem sólidas
Já usei no passado um conjunto maior de agent skills e achei perda de tempo porque tentavam fazer coisa demais. Como no Vim, muitas vezes é melhor escolher na comunidade do que instalar um conjunto inteiro de skills como se fosse uma IDE
Skills variam tanto entre desenvolvedores e equipes que acabam sendo pessoais demais. Em vez de instalar em massa a configuração dos outros, é melhor tratá-las como material de referência para montar a sua
Do ponto de vista de otimização para busca ou para LLMs, parece que a descoberta dessas skills vai ser difícil se não mudarem o nome: https://agentskills.io/
Se o Addy vir isso, queria saber como ele explicaria isso em comparação com Superpowers: https://github.com/obra/superpowers
Estou em desenvolvimento com agentes desde antes de superpowers, e me preocupa que mais de 50% do processo que construí por conta própria agora pareça coberto por superpowers
Não confio mais em estrelas do GitHub. Alguém me diga: superpowers foi realmente adotado agora? Se vale tanto assim, por que Boris ainda não integrou o conceito?
“Se você acha que existe 1% de chance de uma skill se aplicar ao que está fazendo, então você deve obrigatoriamente chamá-la”
Não entendo por que todo mundo parece tão animado para eliminar o próprio emprego
Essas coisas ou qualquer “skill” provavelmente não vão realmente fazer isso, mas em princípio, sim. Isso parece uma alienação do trabalho acontecendo em escala
Desde sempre, até onde se pode rastrear, a humanidade vem reduzindo o trabalho necessário para produzir uma determinada quantidade de resultado, e isso é a civilização. Devemos voltar à enxada e ao cultivo manual para maximizar o trabalho gasto? Devemos voltar aos tempos em que se acendiam postes de luz um por um?
Uma sociedade que fica para trás em automação empobrece e acaba morrendo. Até as pessoas nascidas ali vão embora para lugares mais produtivos. Isso aconteceu no Leste Europeu, com os Amish, e em qualquer sociedade pobre da qual as pessoas emigram. Fazer mais com menos sempre foi algo empolgante
Fico curioso se a pessoa se sente assim em relação a toda automação que constrói. Havia administradores de sistemas da velha guarda que viam a evolução da automação de infraestrutura dessa forma e não gostavam de ver scripts e sistemas fazendo o que antes era feito à mão
Em um emprego, nossa equipe criou um sistema automático de patching que rodava patches em 30 mil servidores e tirava e recolocava sistemas em produção automaticamente. Todo o processo passou a ser hands-off, e antes havia uma equipe dedicada só a tocar isso manualmente. Nós roubamos o trabalho deles com automação?
Em certo sentido, sim, mas havia outras coisas a serem feitas e agora eles podiam fazê-las
É exatamente por isso que gosto de programação, computadores e tecnologia: eles fazem o trabalho por nós. Minha utopia é um mundo em que robôs fazem todo o trabalho duro para que humanos possam fazer o que quiserem. A IA está nos levando mais um passo nessa direção. Em vez de tentar preservar trabalho suficiente para manter as pessoas ocupadas fazendo tarefas que nem querem fazer, eu preferiria focar em como garantir que os benefícios de robôs tomarem empregos sejam sentidos pelo mundo todo, e não só por proprietários ricos
No momento, ainda não está claro para que direção tudo isso vai evoluir, então as pessoas estão entregando seus dados a agentes aleatórios, tentando descobrir como salvar e acessar contexto, reutilizar prompts e encontrar várias formas de lidar com essa tecnologia
A maior parte disso talvez se torne inútil em um ano, quando estiver profundamente integrada à próxima geração de modelos. Ainda assim, acompanhar a evolução sempre foi parte da diversão de trabalhar nessa área
Acho que tanto os favoráveis quanto os contrários ficariam um pouco surpresos se os dados de longo prazo mostrassem que, em média, os ganhos de produtividade foram limitados e que, mesmo com ajuda dos modelos mais avançados, ainda é preciso muito cuidado e atenção humana para produzir software de qualidade
É o mesmo trabalho, só que agora com furadeira elétrica em vez de chave de fenda. Algumas pessoas constroem casas que duram séculos; outras não
Tenho ouvido muito essa comparação ultimamente. Coisas que são boas para gerenciar equipes de desenvolvedores também são boas para gerenciar LLMs
Bons casos de teste, documentação clara e concisa, CI/CD, boas práticas e documentação de onboarding
Gerenciar LLMs está ficando cada vez mais parecido com gerenciar uma equipe humana
Queria entender o que isso faz melhor ou diferente de spec-kit. A filosofia parece muito parecida, e queria saber se dá para usar junto. Ou será que é só redundante?
https://github.com/github/spec-kit
Fiquei surpreso com o tamanho de algumas skills. Elas têm várias páginas, com tabelas, listas de checkbox, exemplos de código etc.
Queria saber quão comum isso é. Só algumas dessas já parecem preencher bastante contexto
Existe um experimento interessante. Basta pedir a uma LLM para usar algo vagamente familiar. Por exemplo, se você pedir “write a fib”, quase toda LLM vai responder com o algoritmo da sequência de Fibonacci, porque foi ajustada em código, embora para quem não programa isso pudesse significar “escreva uma mentirinha”
Ou seja, acontece compressão. Sem explicar em detalhes o que é a sequência de Fibonacci, só três tokens ambíguos já conseguem representar o resultado
Então dá para ver que o comprimento do prompt não é o mais importante. O que importa são as palavras corretas, a frequência e a ordem. Um prompt de duas páginas e um prompt de duas frases podem gerar o mesmo resultado
Até agora tenho tido sucesso com skills curtas e focadas. Eu as trato como fragmentos reutilizáveis de contexto, mas mantenho pequenas. Por exemplo, alguns parágrafos sobre como usar Python no meu projeto e como rodar testes unitários
Também tenho várias skills curtas de “info” que não dão instruções ao agente, apenas trazem informações úteis de contexto que ele pode puxar se precisar
Skills demais também podem virar problema. Afinal, a lista com nomes e descrições das skills acaba entrando no contexto em algum momento
Mesmo num contexto pequeno de 128k em uma LLM isso é algo como 10%, e numa janela de contexto de 1M em modelos grandes quase nem aparece
Talvez eu esteja sendo conservador demais aqui. Ainda há muito o que explorar
“A maior parte do trabalho de um engenheiro sênior não aparece no diff”
Agent Skills é a tentativa do Addy de automatizar até essa parte. Saúde, Addy :P