Laravel Comments Laravel Package

Getting Started

Install the package with Composer, then publish its configuration/provider assets if it ships any (php artisan vendor:publish). After that, the fastest orientation is the package source itself: read the service provider and the config file first — those tell you what is bound into the container, what is publishable, and which defaults you can override.

If your app uses Laravel Boost, run:

php artisan boost:install

This is the new entry point added in v1.1.0. Boost reads the package's resources/boost/guidelines/core.blade.php and offers those guidelines to your app, so AI coding agents working in your repository generate code that follows the package's intended patterns rather than guessing at its API.

First use case: on a fresh install, run boost:install before you ask an agent (Copilot, Cursor, Claude, etc.) to scaffold anything that touches this package. That single step is the difference between agents inventing method names and agents wiring up the package the way its maintainers expect.

Implementation Patterns

Bootstrap-then-build workflow. Treat the guidelines as project setup, not an afterthought:

1. Install/upgrade the package.
2. Run php artisan boost:install and accept the guidelines when prompted.
3. Only then start generating or refactoring code that depends on the package.

Upgrade checklist for v1.1.0. Existing apps should re-run boost:install after composer update — the guidelines are shipped inside the package and are only surfaced to Boost when the install command runs. A plain composer update will not retroactively register them.

Team consistency. Guidelines land in your app's Boost configuration, which is typically committed. That means every developer and every agent session in the repo works from the same description of the package's API. Commit those artifacts alongside your composer.lock bump so the guideline version and package version move together.

Layering. Package guidelines describe the package in isolation. Add your own project-level Boost guidelines on top for conventions the package can't know about — naming, service boundaries, where you want the package's abstractions used versus where you prefer something hand-rolled.

Verify by example. After installing guidelines, ask an agent to implement one small, well-understood integration with the package. If the output looks idiomatic, the guidelines took. If it looks like generic Laravel with guesses bolted on, they didn't — check boost:install actually offered them.

Gotchas and Tips

• boost:install is a no-op if you don't use Laravel Boost. The guidelines are additive developer tooling, not a runtime dependency. Apps without Boost are unaffected by v1.1.0 — no config changes, no behavior changes.
• The file is a Blade template (core.blade.php). Rendering happens at install time, so re-running the command is the supported way to refresh content after a package upgrade. Don't hand-copy the file into your Boost config.
• Don't hand-edit generated guideline output. If you need different wording, the correct lever is project-level guidelines layered on top, or an override published from the package (if supported). Editing generated files silently forks you from upstream and the divergence compounds with every release.
• Guidelines reduce hallucination; they don't eliminate it. Agents still confabulate method signatures. For anything non-trivial, cross-check against the package's actual src/ or its test suite — the tests are usually the most accurate documentation of intended usage.
• When an agent's output fails, the diagnostic order is: (1) were the guidelines installed at all, (2) is the generated artifact stale relative to the installed package version, (3) is a project-level guideline contradicting the package guideline. Most "the agent doesn't understand this package" reports resolve at step 2.
• Debugging the install itself: look for the source at vendor/<vendor>/<package>/resources/boost/guidelines/core.blade.php to confirm the release actually contains it (useful when a stale composer.lock or an opcache/cache issue makes you doubt the upgrade landed).
• Extension point worth noting: because guidelines are template files rendered at install, they are the maintainer's intended surface for steering agent behavior. If your team has strong opinions about how this package should be used, contributing improvements upstream there scales better than maintaining a local override.