Laravel lançou um diretório aberto de skills para agentes de IA. Já tem 96 módulos disponíveis.
A ideia é simples: em vez de você explicar pro agente de IA como seu projeto funciona toda vez que abre o editor, você instala um módulo que já traz essas regras. "Use Form Requests." "Prefira Eloquent scopes." "Escreva testes com Pest antes do código." O agente carrega isso sob demanda, sem poluir o contexto inteiro.
Funciona com Claude Code, Cursor, Windsurf, Copilot. A instalação é via Boost: ao rodar boost:install e selecionar skills como recurso, ele lê seu composer.json e instala automaticamente as skills dos pacotes que você já usa. Sem configuração manual. E o formato segue a spec aberta do agentskills.io, então não é lock-in no ecossistema Laravel.
O diretório em si é útil. Mas o que ele representa vai além.
Laravel está tratando agentes de IA como cidadãos de primeira classe do ecossistema. Não como um add-on, não como integração de terceiros. O AI SDK saiu do beta no Laravel 13, o Boost já dá contexto sobre rotas, banco, estrutura do projeto. Agora o Skills fecha o ciclo: conhecimento reutilizável, versionado, compartilhável.
PHP é a linguagem que mais ouviu "vai morrer" nos últimos 15 anos. E enquanto isso, o ecossistema Laravel está montando uma infraestrutura para agentes que muita stack "moderna" ainda não tem.
Tem um detalhe que vale prestar atenção: o carregamento é progressivo. Se você instala 10 skills, o agente não joga tudo no contexto de uma vez. Ele escolhe o mais relevante pro que você pediu. Isso importa porque contexto é o recurso mais caro quando se trabalha com LLMs.
Padronizar convenções de código via skills pode ser mais eficiente do que documentar num wiki que ninguém lê. O agente lê.
Instalar skill é aceitar uma política de código
Uma skill é uma pasta com SKILL.md: nome, descrição e instruções que o agente segue quando a tarefa combina. Pode trazer script, referência e template. No formato aberto, o cliente carrega só nome e descrição na subida; o corpo entra no contexto quando a tarefa parece relevante; arquivos extras entram se a execução pedir. Isso é política embutida no caminho do trabalho, não um parágrafo num Confluence.
O efeito é o mesmo de um linter com opinião. Se a skill diz para usar Form Request e o time ainda valida no controller, o agente vai gerar código contra o hábito local. Se diz Pest e o repositório é PHPUnit, a PR nasce no framework errado. Conveniência de instalação não resolve o conflito. Resolve só o transporte da regra.
Trate cada skill habilitada como dependência. Quem é o dono. Qual versão. O que ela manda fazer em autenticação, teste, Livewire, Inertia, fila. Uma skill sem dono vira regra órfã: ninguém revisa, o agente continua obedecendo, o diff acumula um estilo que o time não escolheu.
Eu exigiria o mesmo tipo de leitura que se dá a um .editorconfig compartilhado, com um extra: a skill executa por cima de código novo o tempo todo. Arquivo morto no wiki incomoda pouco. Instrução ativa no agente incomoda no review de toda terça.
Boost escolhe pelo composer.json, o time escolhe o restante
boost:install com skills detecta pacotes e instala os módulos correspondentes. Livewire, Inertia, Tailwind, Pest e outros do ecossistema entram se o lockfile já os traz. Guidelines do Boost, por outro lado, sobem no contexto de antemão e são versionadas para o pacote instalado. São duas camadas. Guidelines ensinam o idioma do framework. Skills detalham um fluxo e só deveriam aparecer quando o fluxo está em jogo.
O diretório com dezenas de módulos é catálogo, não receita. Habilitar tudo porque "é grátis" aumenta a chance de duas descrições competirem pela mesma tarefa. Progressive disclosure reduz tokens. Não reduz ambiguidade. Se duas skills afirmam autoridade sobre validação, o agente escolhe com base em texto, não em ADR.
Faça um inventário curto depois do install automático. Liste o que o Boost colocou. Risque o que o time não pratica. Adicione uma skill local só para o que é específico do produto: nomenclatura de bounded context, regra de autorização, pacote interno. O valor do diretório é o pacote oficial. O valor da operação é o recorte.
Compatibilidade acompanha versão de pacote. Uma skill de Livewire 3 aplicada num app em transição, ou uma orientação de Laravel 11 num 13, reproduz o bug clássico do modelo desatualizado. Boost filtra documentação por versão. A skill do time precisa da mesma disciplina: aponte a major que ela assume, e recuse-a quando o composer.json não bater.
Conflito entre skill de pacote e regra local
Times maduros já têm convenções que divergem do default. Talvez Form Request seja obrigatório só na API pública. Talvez o domínio viva em actions, não em controllers gordos. Uma skill oficial que empurre o default do framework vai "corrigir" o código na direção oposta à arquitetura acordada.
A spec aberta ajuda na portabilidade entre Claude Code, Cursor e Copilot. Não ajuda no conflito de conteúdo. A resolução é humana: ou a skill oficial é desabilitada naquele tema, ou uma skill do repositório declara a exceção com descrição mais específica, para vencer no matching. Deixar as duas ativas e "ver no review" transfere o custo para cada PR.
Revisão de mudança em skill deve entrar no mesmo fluxo de mudança de CI. Diff em SKILL.md altera o comportamento de todo mundo que usa o agente naquele repo. Peça no template de PR o motivo, o pacote/versão alvo e um exemplo de prompt que deve (e um que não deve) acionar o módulo. Sem isso, a política muda em silêncio.
Versionar e revisar a instrução como dependência
Pin, changelog e remoção fazem parte do ciclo. Quando o pacote oficial atualizar a skill, alguém lê o diff antes de --force. Quando o time abandonar Filament, a skill sai no mesmo PR que remove o pacote. Quando uma regra local morrer, o arquivo morre. Skill órfã é pior que wiki órfã porque continua sendo lida.
O ganho frente ao wiki é real: a instrução aparece na hora da tarefa. O custo novo também é real: você passou a ter um segundo canal de governança de código, paralelo ao linter e ao code owner. Se esse canal não tiver dono, o diretório de 96 módulos vira ruído padronizado. Se tiver, o agente para de improvisar convenção a cada sessão, e o review discute a regra uma vez só.
