Product Decisions This Supports
- Standards-as-a-package vs. internal conventions doc. This release reinforces that the package is an opinionated, shipped artifact for Laravel coding standards rather than a wiki page — it now bundles a Laravel Boost guideline and split "skills", meaning the conventions are consumable by AI coding agents as well as humans. That directly informs the build-vs-buy call: if your team is standardizing Laravel conventions and using Boost/agent-assisted development, adopting a maintained package is cheaper than authoring and versioning your own guideline set.
- Roadmap sequencing for AI-assisted development. Adding a Boost guideline is a signal that the maintainer is tracking the Laravel ecosystem's agent tooling. For a PM, this is a cheap way to get your team's conventions into agent context without owning that integration — worth slotting into a "developer experience / AI tooling" roadmap item rather than a bespoke build.
- Modular adoption via split skills. Splitting skills into separate units reduces the all-or-nothing cost of adoption: you can pilot one skill set in one repository instead of retrofitting every convention at once. This makes a phased rollout (pilot repo → team → org) a legitimate decision rather than a compromise.
- Consistency work tied to stubs and collections. The "fix stubs and collections" changes affect generated scaffolding and collection conventions — the artifacts most likely to drift between teams. If your roadmap includes reducing PR review nitpicks or normalizing generated code, this package addresses that surface directly.
- Namespace/source migration decision. The published upgrade guide explicitly covers moving from
softpulze/laravibe-standards to this package. If any team is still on the predecessor, this release creates a concrete, documented migration task with a decision deadline — treat it as a scheduled dependency migration, not background work.
- Not a product differentiator. Nothing here changes end-user-facing capability. Frame adoption as an engineering-efficiency investment, not a customer feature.
When to Consider This Package
Adopt (or keep adopting) when:
- Your stack is Laravel/PHP and you want enforced, versioned conventions — stubs, collections, and code standards — rather than informal team agreement.
- You are using or trialing Laravel Boost / AI coding agents and want guidelines that keep agent output aligned with house style. This is the strongest new reason to adopt in v0.5.0.
- You can pin the version and absorb periodic breaking changes. This is a v0.x package with a breaking change in this very release — treat it as pre-1.0 and plan accordingly.
- You value a maintainer who ships upgrade guides alongside breaking changes; the presence of a documented upgrade path materially lowers the cost of the disruption.
- You want a pilot-friendly footprint: a single repo can validate the guideline + skills before org-wide rollout.
Look elsewhere or defer when:
- You need API stability, LTS guarantees, or vendor support. Pre-1.0 with breaking changes on a minor bump is disqualifying for a platform-layer dependency.
- Your team does not use Boost or agent tooling and already has Pint/PHPStan/PHP_CodeSniffer rules covering your needs — the incremental value is narrower.
- You require framework-agnostic standards or support for non-Laravel PHP services.
- You cannot commit owner time to a migration: "split skills" and stubs/collections fixes may require updating local overrides, published stubs, and any customized skill files. If nobody owns that, defer until you do.
- You are mid-freeze on a release-critical codebase — schedule the upgrade window rather than adopting reactively.
How to Pitch It (Stakeholders)
For executives (one paragraph): This is a low-cost engineering-consistency dependency for our Laravel services. The v0.5.0 release adds support for AI coding-agent guidelines and modularizes its rule sets, which lets us adopt it incrementally instead of rewriting conventions across every repository. The tradeoff is that the package is pre-1.0 and just shipped a breaking change; the maintainer published an upgrade guide, so we can pin the current version, pilot in one repository, and migrate on a planned schedule. Recommended ask: approve a scoped pilot, not an org-wide mandate.
For engineering leads: v0.5.0 is a breaking release — the "split skills" change plus stubs/collections fixes mean published assets and any locally customized skill or stub files may need re-publishing or path updates. The namespace migration from softpulze/laravibe-standards is documented separately; teams still on the predecessor should migrate now while the guide is fresh. Concrete plan: pin v0.5.0 (or hold at v0.4.0 if a release freeze is active), pilot in one repo, diff generated stubs and collection output before/after, then roll forward. Watch item: pre-1.0 churn — expect another breaking change before 1.0 and budget for it.
For platform/DevEx owners: the Boost guideline and split skills are the durable win here — they let us ship conventions into agent context as a versioned dependency rather than maintaining prompt/guideline docs by hand. Recommend we treat this package as the single source of truth for Laravel conventions and stop maintaining parallel internal docs.