Laravel Boost gives AI coding agents an MCP server, guidelines and skills that match the exact packages and versions your project uses.
Boost is intended to be used with Laravel projects, not packages. A package can be developed and tested with Orchestra Testbench. To make Boost work with a package, there's only a handful of small changes needed.
When you run a command through Testbench, Laravel boots from a skeleton application that lives inside vendor/orchestra/testbench-core/laravel. That means base_path() and app_path() point into your vendor folder.
Boost uses base_path() for almost everything. It reads your composer.json, loads your custom guidelines from .ai/, writes AGENTS.md and the skills, and stores its own boost.json. Run boost:install as-is and all of that ends up in the workbench skeleton app inside vendor, which gets thrown away on the next composer install.
The MCP server has a second problem. Every agent config Boost generates starts the server with php artisan boost:mcp, and a package doesn't have an artisan file.
Testbench ships with vendor/bin/testbench, which is basically artisan for packages. So the root artisan file only needs to forward to it:
1#!/usr/bin/env php
2<?php
3
4declare(strict_types=1);
5
6require __DIR__.'/vendor/bin/testbench';
Don't forget to make it executable with chmod +x artisan. Now php artisan boost:install and php artisan boost:mcp both work, and the MCP configs Boost generates for Claude Code, Codex and OpenCode work unchanged:
1{
2 "mcpServers": {
3 "laravel-boost": {
4 "command": "php",
5 "args": [
6 "artisan",
7 "boost:mcp"
8 ]
9 }
10 }
11}
Next, Boost needs to see the package instead of the skeleton. Testbench has a package_path() helper that returns the root of your package, so we listen for any console command starting with boost: and swap the paths before it runs. We do this in the WorkbenchServiceProvider:
1use Illuminate\Console\Events\CommandStarting;
2use Illuminate\Support\Facades\Event;
3
4use function Orchestra\Testbench\package_path;
5
6public function boot(): void
7{
8 Event::listen(function (CommandStarting $event): void {
9 if (! str_starts_with($event->command, 'boost:')) {
10 return;
11 }
12
13 app()->setBasePath(package_path());
14 app()->useAppPath(package_path('src'));
15 });
16}
setBasePath() makes Boost read and write everything in the root of the repository. useAppPath() points Boost at src/, so anything that scans "the app", like its enum discovery, looks at our code instead of an empty skeleton folder.
We only change the paths for boost: commands. Your tests, workbench:serve and other Testbench commands keep working against the skeleton like they always have.
This also covers the MCP server's tools. Boost runs each tool call in a separate process with php artisan boost:execute-tool, which starts with boost: too, so it gets the same paths. That process starts from base_path('artisan'), which is now the root artisan file from step one.
Boost's guidelines are written for Laravel apps, and some of them don't make much sense in a package. You can publish a boost.php config file to turn things off. With Testbench, you can place it in workbench/config, as long as config discovery is turned on in your testbench.yaml:
1workbench:
2 discovers:
3 config: true
This is the config we use for Craft:
1<?php
2
3declare(strict_types=1);
4
5return [
6 'agents' => [
7 'claude_code' => [
8 'skills_path' => '.agents/skills',
9 ],
10 ],
11 'browser_logs_watcher' => false,
12 'enforce_tests' => false,
13 'rules' => [
14 'enabled' => true,
15 'scoped_guidelines' => false,
16 ],
17 'guidelines' => [
18 'exclude' => [
19 'deployments',
20 'laravel/core',
21 'pest/core',
22 ],
23 ],
24 'skills' => [
25 'exclude' => [
26 'pest-testing',
27 'testing-best-practices',
28 ],
29 ],
30];
A few things worth pointing out:
laravel/core and deployments guidelines assume a Laravel app that you deploy, so they're excluded. We exclude the Pest guideline and testing skills as well, because we have our own testing guidelines..claude/skills. That meant committing each skill twice. Setting skills_path to .agents/skills and symlinking .claude/skills to it keeps a single copy that every agent reads.Boost's foundation guideline still tells the agent "this application is a Laravel application", and Boost detects craftcms/cms in your dependencies. That's why we added a guideline in .ai/guidelines/craft.md that sets the record straight. Boost merges it into AGENTS.md above its own guidelines:
1# Craft CMS
2
3Craft CMS 6 runs on Laravel 13. This repository is a package that boots through Orchestra Testbench, not a conventional Laravel application.
4
5Boost's `search-docs` covers Laravel ecosystem documentation. Use Craft's source and documentation for Craft-specific APIs; detecting `craftcms/cms` does not mean Boost has indexed its documentation.
That last line saved a lot of useless search-docs calls for Craft APIs.
Our more specific rules live in .ai/rules, with an index.md that maps file globs to rule files, so an agent working in src/Field only reads the rules for fields.
None of this belongs in the package your users install. Add the Boost files to .gitattributes so Composer leaves them out:
1/.agents/ export-ignore
2/.ai/ export-ignore
3/.claude/ export-ignore
4/.codex/ export-ignore
5/.mcp.json export-ignore
6/AGENTS.md export-ignore
7/artisan export-ignore
8/boost.json export-ignore
9/opencode.json export-ignore
10/workbench export-ignore
Boost can update its guidelines and skills automatically, but we run php artisan boost:update by hand once in a while. Many of the guidelines are written for applications, so I read through the diff and exclude anything that doesn't apply to a package before committing it.
Boost also picks up guidelines and skills from other packages. We added pestphp/pest-plugin-agent as a dev dependency and listed it under packages in boost.json, and its skill now ships with the rest.
If you want to see the full setup, take a look at the PR that added Boost to Craft. And if you're developing packages with Testbench, you might also like using Laravel's parallel testing inside your package tests.