Laravel abrió un directorio de skills para agentes de IA con 96 módulos disponibles al lanzamiento. Una skill empaqueta instrucciones como usar Form Requests, preferir scopes de Eloquent o escribir pruebas con Pest antes de implementar, para que el equipo no repita esas convenciones en cada sesión.
Laravel Boost instala skills según los paquetes presentes en composer.json y funciona con Claude Code, Cursor, Windsurf y Copilot. El formato sigue la especificación abierta de agentskills.io, lo que reduce lock-in. La carga progresiva permite que el agente seleccione material relevante en lugar de poner todas las instrucciones en el prompt.
La novedad completa una dirección más amplia. Boost ya expone contexto del proyecto y el AI SDK integra modelos. El directorio añade conocimiento reutilizable y compartible. Puede ser más operativo que una wiki porque la instrucción aparece durante el trabajo, pero también convierte prosa en influencia ejecutable sobre el código.
Instalar una skill es aceptar una política de código
Una skill es una carpeta con SKILL.md: nombre, descripción e instrucciones que el agente sigue cuando la tarea encaja. Puede traer script, referencia y plantilla. En el formato abierto, el cliente carga solo nombre y descripción al arrancar; el cuerpo entra en el contexto cuando la tarea parece relevante; los archivos extra entran si la ejecución los pide. Eso es política incrustada en el camino del trabajo, no un párrafo en Confluence.
El efecto es el de un linter con opinión. Si la skill dice usar Form Request y el equipo aún valida en el controller, el agente genera código contra el hábito local. Si dice Pest y el repositorio es PHPUnit, la PR nace en el framework equivocado. La comodidad de instalación no resuelve el conflicto. Solo transporta la regla.
Traten cada skill habilitada como dependencia. Quién es el dueño. Qué versión. Qué manda hacer en autenticación, test, Livewire, Inertia, cola. Una skill sin dueño vira regla huérfana: nadie la revisa, el agente sigue obedeciendo y el diff acumula un estilo que el equipo no eligió.
Yo pediría el mismo tipo de lectura que se da a un .editorconfig compartido, con un extra: la skill se ejecuta encima de código nuevo todo el tiempo. Un archivo muerto en la wiki molesta poco. Una instrucción activa en el agente molesta en el review de cada martes.
Boost elige por composer.json; el equipo elige el resto
boost:install con skills detecta paquetes e instala los módulos correspondientes. Livewire, Inertia, Tailwind, Pest y otros del ecosistema entran si el lockfile ya los trae. Las guidelines de Boost, en cambio, suben al contexto de antemano y van versionadas para el paquete instalado. Son dos capas. Las guidelines enseñan el idioma del framework. Las skills detallan un flujo y solo deberían aparecer cuando ese flujo está en juego.
El directorio con decenas de módulos es catálogo, no receta. Habilitar todo porque "es gratis" aumenta la chance de que dos descripciones compitan por la misma tarea. La carga progresiva reduce tokens. No reduce ambigüedad. Si dos skills afirman autoridad sobre validación, el agente elige con base en texto, no en un ADR.
Hagan un inventario corto después del install automático. Anoten lo que Boost colocó. Tachen lo que el equipo no practica. Añadan una skill local solo para lo específico del producto: nombres de bounded context, regla de autorización, paquete interno. El valor del directorio es el paquete oficial. El valor de la operación es el recorte.
La compatibilidad sigue la versión de paquete. Una skill de Livewire 3 en una app en transición, o una orientación de Laravel 11 en un 13, reproduce el bug clásico del modelo desactualizado. Boost ya filtra documentación por versión. La skill del equipo necesita la misma disciplina: indiquen la major que asume, y rechácenla cuando composer.json no coincida.
Conflicto entre skill de paquete y regla local
Los equipos maduros ya tienen convenciones que divergen del default. Quizá Form Request sea obligatorio solo en la API pública. Quizá el dominio viva en actions, no en controllers gordos. Una skill oficial que empuje el default del framework va a "corregir" el código en la dirección opuesta a la arquitectura acordada.
La spec abierta ayuda a la portabilidad entre Claude Code, Cursor y Copilot. No ayuda al conflicto de contenido. La resolución es humana: o se deshabilita la skill oficial en ese tema, o una skill del repositorio declara la excepción con una descripción más específica para ganar el matching. Dejar las dos activas y "verlo en el review" transfiere el costo a cada PR.
La revisión de un cambio en skill debe entrar en el mismo flujo que un cambio de CI. Un diff en SKILL.md altera el comportamiento de todo el que usa el agente en ese repo. Pidan en la plantilla de PR el motivo, el paquete y versión objetivo, y un ejemplo de prompt que deba (y uno que no deba) activar el módulo. Sin eso, la política cambia en silencio.
Versionar y revisar la instrucción como dependencia
Pin, changelog y eliminación forman parte del ciclo. Cuando el paquete oficial actualice la skill, alguien lee el diff antes de --force. Cuando el equipo abandone Filament, la skill sale en el mismo PR que quita el paquete. Cuando una regla local muera, el archivo muere. Una skill huérfana es peor que una wiki huérfana porque sigue siendo leída.
La ganancia frente a la wiki es real: la instrucción aparece en el momento de la tarea. El costo nuevo también es real: ahora tienen un segundo canal de gobernanza de código, paralelo al linter y al code owner. Si ese canal no tiene dueño, el directorio de 96 módulos vira ruido estandarizado. Si lo tiene, el agente deja de improvisar convención en cada sesión, y el review discute la regla una sola vez.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
