Laravibe Standards Laravel Package

Product Decisions This Supports

• Standardizing conventions across Laravel repos. This package ships stubs, collections, and guideline/skill files that new and existing projects inherit — the product decision is whether consistency is enforced by tooling (scaffolding) or by review discipline (docs + Pint/PHPStan). Adoption bets on tooling.
• AI-assisted development policy. v0.5.0 adds a Laravel Boost guideline, which means AI coding agents get repo-aware context that matches house style. This supports a concrete decision: do we ship a standard AI-context/guideline file to every repo, or let each team curate its own?
• Modularization strategy. The breaking "split skills" change signals the package is moving from a monolithic bundle to composable pieces. That informs whether we consume it wholesale or adopt only the subsets (stubs, collections, guidelines) we actually want.
• Build vs buy for internal standards tooling. The alternative is an internal repo of Blade stubs, a style guide, and copy-pasted AI rules. Buying (adopting OSS) is cheaper up front; building gives control and no upstream churn.
• Package rename / dependency inventory. The upgrade guide is documented as coming from softpulze/laravibe-standards, indicating a vendor/namespace move to thesoftpulze/*. This is a concrete tracking task: which repos, CI configs, and composer constraints still reference the old name.
• Version pinning policy. At 0.x with breaking changes between minor versions, this feeds the broader decision on whether internal tooling dependencies are pinned exactly or allowed to float.

When to Consider This Package

Consider it when:

• You run more than one Laravel codebase and want conventions to propagate without re-litigating them per repo.
• You have (or are introducing) AI coding assistants and want a standard, maintainable guideline file rather than ad-hoc prompt snippets.
• Your team is comfortable pinning exact versions and reading release notes before bumping internal tooling.
• You already have linting/static analysis in CI — this complements it rather than replacing it.
• You can absorb a breaking change at 0.x without a support contract.

Look elsewhere when:

• You have a single application — the coordination benefit largely disappears; a handful of local stubs is simpler.
• You need an LTS, SLA, or security-response commitment; this is a small, single-maintainer, pre-1.0 package.
• Your organization cannot tolerate breaking changes on minor bumps, or requires semantic-versioning guarantees before adoption.
• You already have a mature internal standard (Pint config, PHPStan/Larastan baseline, published stubs) — the marginal gain is small and you inherit upstream churn.
• You need broad framework-version coverage; verify compatibility against your Laravel versions before committing.

How to Pitch It (Stakeholders)

To executives: This is a low-cost way to make our Laravel codebases look and behave the same, and — increasingly relevant — to make AI coding assistants follow our conventions instead of inventing their own. Cost is near zero and it is OSS. The trade-off is maturity: it's pre-1.0, maintained by a very small team, and just shipped a breaking change. Recommendation: pilot on one non-critical repo, pin the version, and revisit once it reaches 1.0 or proves stable across two or three releases.

To engineering: v0.5.0 adds a Laravel Boost guideline and splits "skills" into separate pieces — that's a breaking change — plus fixes to stubs and collections. Practical impact: re-publishing stubs can overwrite local edits, and any repo consuming the combined skills bundle needs rework. Pin to v0.5.0 exactly, diff published files before re-publishing, and follow the new upgrade guide if you're migrating from the older softpulze/laravibe-standards namespace. Treat this as a scaffold-and-review dependency, not a runtime one, so blast radius stays contained.