Laravel opened a directory of skills for AI agents with 96 modules available at launch. A skill packages instructions such as using Form Requests, preferring Eloquent scopes, or writing Pest tests before implementation, so teams do not repeat those conventions in every session.
Laravel Boost installs skills based on the packages found in composer.json and supports Claude Code, Cursor, Windsurf, and Copilot. The format follows the open agentskills.io specification, which reduces lock-in. Progressive loading means the agent selects relevant material rather than placing every installed instruction in the prompt.
The release is part of a broader direction. Boost already exposes project context, and Laravel's AI SDK provides model integration. The directory adds reusable, shareable knowledge. This can be more operational than a wiki because the instruction sits in the path of the work, but it also turns prose into executable influence over code changes.
Installing a skill accepts a code policy
A skill is a folder with SKILL.md: a name, a description, and instructions the agent follows when the task matches. It may include scripts, references, and templates. In the open format, the client loads only name and description at startup; the body enters context when the task looks relevant; extra files enter if execution needs them. That is policy embedded in the path of work, not a paragraph in Confluence.
The effect matches an opinionated linter. If the skill says to use Form Requests and the team still validates in the controller, the agent generates code against local habit. If it says Pest and the repository is PHPUnit, the PR arrives in the wrong test framework. Installation convenience does not resolve the conflict. It only transports the rule.
Treat each enabled skill as a dependency. Who owns it. Which version. What it mandates for authentication, tests, Livewire, Inertia, queues. A skill without an owner becomes an orphan rule: nobody reviews it, the agent keeps obeying, and every diff accumulates a style the team did not choose.
I would demand the same reading we give a shared .editorconfig, with an extra: the skill executes on top of new code all the time. A dead wiki file barely hurts. An active instruction in the agent hurts in every Tuesday review.
Boost chooses from composer.json; the team chooses the rest
boost:install with skills detects packages and installs the matching modules. Livewire, Inertia, Tailwind, Pest, and others in the ecosystem arrive if the lockfile already has them. Boost guidelines, by contrast, load up front and are versioned for the installed package. Those are two layers. Guidelines teach the framework dialect. Skills detail a flow and should appear only when that flow is in play.
A directory of dozens of modules is a catalog, not a recipe. Enabling everything because "it is free" raises the chance that two descriptions compete for the same task. Progressive disclosure reduces tokens. It does not reduce ambiguity. If two skills claim authority over validation, the agent chooses from text, not from an ADR.
Run a short inventory after the automatic install. List what Boost placed. Drop what the team does not practice. Add a local skill only for product-specific rules: bounded-context names, authorization, an internal package. The directory's value is the official package. The operation's value is the cut.
Compatibility follows package version. A Livewire 3 skill on an app in transition, or Laravel 11 guidance on 13, reproduces the classic stale-model bug. Boost already filters docs by version. A team skill needs the same discipline: state the major it assumes, and refuse it when composer.json does not match.
Conflict between a package skill and a local rule
Mature teams already hold conventions that diverge from the default. Form Requests may be mandatory only on the public API. Domain logic may live in actions, not fat controllers. An official skill that pushes the framework default will "correct" code in the opposite direction from the agreed architecture.
The open spec helps portability across Claude Code, Cursor, and Copilot. It does not help with content conflict. Resolution is human: either the official skill is disabled on that topic, or a repository skill states the exception with a more specific description so it wins matching. Leaving both active and "catching it in review" moves the cost onto every PR.
A change to a skill should travel the same path as a CI change. A diff in SKILL.md alters behavior for everyone using the agent in that repo. Ask the PR template for the reason, the target package and version, and one example prompt that should (and one that should not) trigger the module. Without that, policy changes in silence.
Version and review the instruction as a dependency
Pins, changelogs, and removal belong in the cycle. When the official package updates a skill, someone reads the diff before --force. When the team drops Filament, the skill leaves in the same PR that removes the package. When a local rule dies, the file dies. An orphan skill is worse than an orphan wiki because it is still being read.
The gain over a wiki is real: the instruction appears at task time. The new cost is real too: you now have a second channel of code governance, next to the linter and the code owner. If that channel has no owner, a catalog of 96 modules becomes standardized noise. If it has one, the agent stops improvising convention every session, and review discusses the rule once.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
