Laravel Actions Boost Laravel Package

Getting Started

This is developer tooling, not runtime application code — install it as a dev dependency so it never lands in production:

composer require --dev <vendor>/<package>
php artisan <package>:install   # or: php artisan vendor:publish --tag=<package>-config

Look here first, in this order:

1. The README banner and requirements block — both are new in v1.0.1, so read them before anything else. They state the supported PHP/Laravel range and, critically, the Laravel Boost major version. If your app is still on Boost 1.x, stop: v1.0.1 targets Boost 2.x and you should stay on v1.0.0.
2. config/<package>.php — the generated-artifact path lives here. This is the knob the v1.0.1 patch touched, so confirm it points where you expect before generating anything.
3. The generated planning-guide file — the actual product of the package. Open it and read it end to end once; it defines the contract your AI agent will follow.

First use case: run the generator for a single, well-scoped feature — not your whole backlog. Feed the output to your Boost-enabled agent (or a human) and treat it as a spec to be reviewed and edited, not an authoritative plan. If the guide reads sensibly for one feature, the install is correct. Then commit the guide so the plan is reviewable in a PR like any other design doc.

Implementation Patterns

Regenerate per feature, don't accumulate. The guide is a snapshot of intent for one unit of work. Keeping a single overwritten file forces you to think about the plan deliberately; accumulating one file per feature turns the directory into unread guide-shaped archaeology nobody reads. If you want history, git gives it to you for free.

Treat the guide as a reviewable artifact in the PR. Generate → edit by hand → commit alongside the implementation. The diff between generated and final guide is a genuinely useful record of where the plan diverged from reality, and reviewers can check the code against stated intent.

Wire Boost 2.x in explicitly. v1.0.1's Boost 2.x support means the package's guidelines/context are shaped for the new Boost layout. Point Boost at the generated guide (via your boost.json / guidelines configuration) rather than copy-pasting sections into a prompt — the file is the source of truth, and duplicating it guarantees drift.

Guard the path in CI. The v1.0.1 changelog fixes the generated planning-guide path, which means the path is a moving target across versions. Add a cheap check that the configured path resolves and the file exists after generation:

php artisan <package>:install --no-interaction
test -f "$(php artisan tinker --execute='echo config("<package>.guide_path");')"

This is the assertion that would have caught the bug v1.0.1 fixed.

Keep it out of deploy. No artisan call to this package belongs in your deploy script or post-autoload-dump. It's an authoring-time tool; if it runs on deploy you'll get generated files appearing in environments where nobody can review them.

Gotchas and Tips

Upgrade to v1.0.1 means deleting, not editing, existing guides. The path fix changes where output lands. If you have a guide sitting at the old location, the installer will happily create a second one at the new path and you'll spend an afternoon confused about which file Boost is reading. Remove the old artifact, clear config cache, regenerate.

php artisan config:cache will mask your path change. Any local config edit or upgrade needs php artisan config:clear before you can trust that the generator is writing somewhere new. This is the single most common false alarm with publishable-config packages.

Version-pin deliberately during the Boost transition. v1.0.1 supports Boost 2.x; the implication is that 1.x projects are on an older release. Pin <vendor>/<package> to an explicit version in composer.json rather than floating, so a routine composer update doesn't silently move your tooling ahead of your Boost install. Add a note in the PR description when you bump either one.

Check the new requirements block against CI, not just your laptop. The banner/requirements addition exists because people were installing on unsupported PHP/Laravel combos. If your CI matrix includes an older PHP version, composer require --dev will fail there and not locally — surface it early.

Generated files should never contain absolute paths or machine-specific values. If you see your home directory in the output, that's a bug worth reporting, not something to sed out in a wrapper script; the guide gets committed and shared.

Extension point: publish the stubs/views (vendor:publish --tag=<package>-stubs) if you need house style in the generated guide — section ordering, your testing conventions, links to internal ADRs. Prefer this over post-processing the file with a script, which re-breaks every time the package changes its output format.

Debugging a silent generator: run the install command with -v and confirm the destination directory is writable. A generator that "succeeds" with no file is almost always writing to a path that doesn't exist yet rather than failing outright — the class of bug v1.0.1 addressed.