Package Boost Laravel Laravel Package

Technical Evaluation

Architecture fit. This package ships text assets, not runtime code. It contributes Laravel-specific agent skills and emits a .mcp.json file. It has no production code path and no service provider that a host application loads. It composes on top of package-boost-php, which supplies the base skill set and the generation engine. The value of the package is therefore the sum of two parts: the upstream engine, and this repository's Laravel skill content plus MCP output. If the upstream project stalls, this package stalls with it.

The skill content targets package authors, not application authors. The guidelines cover Orchestra Testbench, the workbench/ fixture layout, vendor/bin/testbench in place of php artisan, and || version constraints with a prefer-lowest CI matrix. Treat this as a tool for package repositories only. Do not install it into application repositories, where most of the guidance does not apply.

Install it as a require-dev dependency. It must not reach a production build.

Integration feasibility. The install path is short. Add the Composer dependency, then run a sync command. The guidelines reference boost sync and note that it prints a warning and continues when laravel/boost is absent. That behavior is useful: the package degrades to skill-file emission alone. The main prerequisite sits on the consumer side, not the package side — the team needs an MCP-capable agent client to use .mcp.json at all.

Technical risk. The repository has 3 stars and 0 dependents. Assume no field hardening and a bus factor of one. The real risks are mechanical, not architectural:

• The package writes a tracked configuration file (.mcp.json) into the consumer repository. Overwrite versus merge behavior is unconfirmed.
• MCP server entries frequently carry credentials or local paths. A generated file that lands in Git becomes a secret-handling question.
• Generated skill text asserts specific framework behavior. A repository on an older Laravel receives guidance that does not match its code.
• Generated AGENTS.md content can collide with an AGENTS.md the repository already maintains.

Key questions.

1. Which command emits .mcp.json, to which path, and does it merge or overwrite an existing file?
2. Can the skill set be scoped per package, or is it all-or-nothing?
3. What is the supported Laravel and PHP range, and does it track the upstream package-boost-php range?
4. Does the package pin an upstream version, or resolve to latest on every install?
5. Is the emitted .mcp.json generic, or does it assume one specific agent client?
6. Can a team regenerate the assets deterministically in CI to detect drift?
7. Who maintains the package, and what is the release cadence?

Integration Approach

Stack fit. The package fits a Composer 2 / PHP / Laravel package repository that already uses Testbench and a CI matrix. It assumes the team uses AI coding agents with MCP support. It does not fit application repositories, framework-agnostic Composer packages, or teams without an MCP client.

Migration path. There is nothing to migrate. The change is additive and development-only. The decision is adoption, not replacement. Teams that already use laravel/boost should compare outputs before running both, because both write agent configuration into the same repository.

Compatibility. Two boundaries need confirmation. First, the Laravel and PHP version range, which the upstream package inherits. Second, the agent client. .mcp.json is a client convention, not a published standard. A file that works for one agent may be ignored by another. Check the generated skill files against the repository's existing AGENTS.md, CLAUDE.md, or equivalent before committing them.

Sequencing.

1. Pin the package and the upstream package-boost-php to explicit versions in composer.json.
2. Pilot in one package repository on a branch, not on main.
3. Run the sync command, then review the full diff: new skill files, modified files, and the .mcp.json content.
4. Scan the diff for credentials, absolute local paths, and hostnames before any commit.
5. Confirm the team's agent client reads the emitted file.
6. Decide whether generated files are committed or gitignored. Commit them if the team wants reviewable changes; ignore them if CI regenerates them.
7. If the pilot succeeds, standardize the version in a shared Composer template so repositories do not drift.

Operational Impact

Maintenance. Maintenance is content review, not code maintenance. Each upstream release can change the skill text, so a version bump deserves a diff review rather than a blind composer update. The package has one apparent maintainer and no dependents, so treat the upgrade stream as unverified. Assign an internal owner for the pinned version and the review step.

Support. There is no community to escalate to. Internal support means one named engineer who reads the diff on each upgrade and answers agent-behavior questions from the team. Budget a few hours per upgrade cycle, not a standing allocation.

Scaling. Cost is near zero per repository. The scaling problem is consistency, not load. If ten repositories pin ten different versions, agents give different advice in each. Pin one version centrally and bump it in one change across all repositories.

Failure modes.

Ramp-up. A developer needs under an hour to install the package, run the sync, and read the generated files. The longer ramp is cultural: the team must accept that agent guidance is a reviewed artifact with an owner, not a one-time install. Plan a short walkthrough of the generated skill files so reviewers know what to look for in future diffs.

Recommendation. Adopt as a time-boxed pilot in one package repository. The integration cost is low, the content is specific and relevant to package authors, and the exit cost is close to zero. Hold broad rollout until the .mcp.json write behavior and the upstream version-pinning policy are confirmed.