sandermuller/project-boost-laravel
Project Boost for Laravel helps supercharge your Laravel project with streamlined setup, sensible defaults, and handy development tooling. It reduces boilerplate and speeds up common tasks so you can focus on building and shipping features.
project-boost-laravel is a thin layer over laravel/boost: it takes the AI guidance that Boost generates (guidelines, tool descriptions, skills activation notes) and syncs it into your project's agent instruction files. Install it as a dev dependency alongside laravel/boost:
composer require --dev sander-muller/project-boost-laravel
php artisan project-boost:sync
Look first at two places:
config/project-boost.php — publish it with the standard vendor:publish flow if you need to change defaults. As of 1.6.0 it exposes an mcp key, env-backed via PROJECT_BOOST_MCP (default true).The first use case is onboarding: a new developer (or a new agent session) clones the repo and gets the same Boost guidance the rest of the team has, without anyone hand-copying sections into CLAUDE.md / AGENTS.md / editor rule files.
Sync-on-install. Wire the command into composer.json so guidance never drifts from the installed Boost version:
"scripts": {
"post-update-cmd": ["@php artisan project-boost:sync"]
}
This matters more than usual here: the 1.6.0 fixes are content fixes (Tools, search-docs, record-rule, and the "Skills Activation" section were being dropped), so the value of the package is coupled to the Boost version it reads from.
CI drift check. Commit the generated files, then run sync in CI and fail on a dirty tree:
php artisan project-boost:sync && git diff --exit-code
This catches the case where someone bumps laravel/boost without re-syncing — exactly the class of bug 1.6.0 fixed.
Opting out of MCP guidance. Set PROJECT_BOOST_MCP=false (or 'mcp' => false) for projects that don't run Boost's MCP server — editors with no MCP support, headless CI agents, or teams standardising on a different tool server. Everything else still syncs. Prefer the env var per environment over hardcoding false in the committed config, so a developer who does run the MCP server locally can flip it back.
Pair with Boost, don't replace it. Let laravel/boost own generation and project-boost:sync own propagation. If you find yourself hand-editing the synced output, that edit will be lost on the next run — push the change upstream into Boost's guidance instead.
Onboarding doc. One line in the README ("run php artisan project-boost:sync after composer install") prevents the "why is my agent ignoring our conventions" question entirely.
search-docs/record-rule, and "Skills Activation") now appear. Run sync on a clean branch and review the diff before committing — don't let it ride along in an unrelated PR.mcp defaults to true. If you're not using Boost's MCP server, agents will be told about tools they can't call. That's not harmless: it produces confident hallucinated tool invocations. Turn it off explicitly rather than relying on the agent to notice.mcp casually. Since 1.6.0 the search-docs and record-rule guidance now actually makes it through — those are the two tools that most change agent behaviour (grounded docs lookup, durable rule capture). If you use the MCP server, keep this on.PROJECT_BOOST_MCP in .env, run php artisan config:clear (or config:cache in deploy). A stale cached config is the most common reason a toggle appears to do nothing.composer show laravel/boost. The 1.6.0 fixes were section-selection bugs, so a version-skewed or patched Boost install is a plausible cause.^ invites surprise diffs. Pin minor versions and bump deliberately.mcp toggle is the current knob for controlling content. If you need finer-grained control (drop only record-rule, say), that isn't exposed — open an issue rather than post-processing the generated files in a shell script, which is unmaintainable and breaks the CI drift check.How can I help you explore Laravel packages today?