- What is sandermuller/project-boost-laravel and what does it actually do?
- Project Boost for Laravel is a dev-only Composer package that streamlines Laravel project setup and materialises laravel/boost's AI-assistant guidance directly into your repository. It registers a project-boost:sync Artisan command that writes guidance content such as guidelines, Tools, search-docs, record-rule, and Skills Activation so coding agents receive consistent instructions. It lives in require-dev and does not touch request handling, persistence, queues, or deployment, so the blast radius is limited to developer experience and the guidance files you commit.
- How do I install project-boost-laravel in a Laravel 11 or 12 application?
- Add it as a dev dependency with composer require --dev sandermuller/project-boost-laravel, pinning laravel/boost to an explicit version at the same time. Publish the package config, run php artisan project-boost:sync once to create a baseline, and commit the generated diff as its own pull request so reviewers can see exactly what guidance is being introduced. Check the package's PHP and Laravel version constraints before starting, then repeat on a second repository to confirm the output is consistent.
- What files does the project-boost:sync Artisan command generate?
- The command mirrors laravel/boost's AI-assistant guidance into your project, covering guidelines, Tools, search-docs, record-rule, and Skills Activation content. It can also emit an MCP configuration block, which is controlled by the PROJECT_BOOST_MCP setting added in 1.6.0 and defaults to true. Because the output is plain committed files, you can review it in a diff like any other code change.
- Which laravel/boost versions is project-boost-laravel 1.6.0 compatible with?
- The meaningful compatibility axis for this package is the laravel/boost version rather than the Laravel version, since the adapter's job is mirroring upstream guidance content. Pin laravel/boost to a specific version in each repository instead of floating it, and confirm the verified range with the maintainer or the package's composer.json before adopting. Treat every laravel/boost bump as requiring a re-run of project-boost:sync plus a diff review, because the 1.6.0 fixes show that mirroring can lag behind upstream.
- Is project-boost:sync idempotent, and will it overwrite my hand-edited guidance files?
- Running the sync command should produce a repeatable result, but the safest way to confirm idempotency for your setup is to run it twice on a throwaway branch and diff the output. Whether it merges or overwrites hand-edited guidance files is not guaranteed, so avoid editing generated files directly and instead keep customisations in a separate, non-generated location. Treat the generated output as a build artefact that is regenerated from laravel/boost rather than hand-maintained.
- Do I need to re-publish the config file to get the new PROJECT_BOOST_MCP option?
- Existing installations should check whether their published config already contains the mcp key, since a config published under 1.5.x will not have it. Publish the config to a temporary path and diff it against your current file, then merge the new key deliberately instead of letting each developer discover the mismatch. If the package reads the value from the environment with a default of true, the guidance block may appear without any config change at all.
- What should PROJECT_BOOST_MCP be set to, and does the default change behaviour?
- Leave PROJECT_BOOST_MCP at its default of true if your team uses Boost's MCP server tooling, and set it to false to suppress the MCP guidance block if you do not. Because the default was introduced in 1.6.0 as true, teams that published a config under 1.5.x may see the MCP block appear after upgrading even though nobody opted in. That makes it a small behavioural change worth calling out in your upgrade notes.
- Which AI agents and editors does the generated guidance target, such as Claude Code, Cursor, or Copilot?
- The package does not define its own agent format; it mirrors laravel/boost's guidance so that whatever agent consumes that guidance gets consistent instructions. In practice that means Claude Code, Cursor, Copilot, and similar tools that read project-level rule and guideline files. Check the generated files after your first sync to confirm the layout matches the agent your team actually uses.
- Should the generated guidance files be committed, and how do I keep them in sync in CI?
- Yes, commit the baseline output in a dedicated pull request so the introduced content is reviewable and version-pinned alongside the package. Add a CI step that re-runs project-boost:sync and fails when the working tree is dirty, plus a lightweight assertion that the expected sections such as Tools, search-docs, record-rule, and Skills Activation are present. That guard catches the failure mode this package is most exposed to, where sync silently omits sections and the files still look complete.
- Is project-boost-laravel safe to adopt, and what are the alternatives?
- It ships in require-dev with no runtime hooks or service dependencies, so production risk is effectively zero; the real risks are upstream coupling to laravel/boost and the bus factor of a single-maintainer package. Verify the licence and whether committing generated guidance files is acceptable under your organisation's IP and security policy before rollout. If those risks are unacceptable, the alternatives are invoking laravel/boost's own tooling directly or maintaining the guidance files by hand, both of which cost more ongoing effort than a thin adapter that is pinned and diff-reviewed.