Boost Core Laravel Package

Product Decisions This Supports

• AI tooling standardization (build vs. buy). The core question this package answers is "do we build our own prompt/skill sync layer, or adopt one?" If your team maintains AI guidance in per-agent files (.cursor/rules, CLAUDE.md, Copilot instructions, etc.), this is a ready-made argument for consolidating to a single .ai/ source of truth and generating the rest. That is a real, recurring maintenance cost — and a real source of drift, where an instruction gets updated in one agent's config and silently rots in the other nine.
• Agent-portfolio strategy. Because agent support is declarative (withAgents()), it makes "which AI assistants do we officially support?" a cheap, reversible product decision rather than an integration project. Adding or dropping an agent becomes a config line, not a quarter of engineering work. This directly de-risks the most likely scenario in any 2026 roadmap: your team's primary assistant changes.
• Curation and noise control for shared AI guidance. As of 1.13.0, ~/.boost/user-scope.php lets you declare which skills each globally installed package publishes at user scope, rather than publishing everything. That turns "how much third-party AI guidance lands on every engineer's machine?" into a reviewable policy file instead of an all-or-nothing install decision — a governance lever that previously didn't exist. Treat this file as a reviewed artifact, not a local preference.
• Distribution and DX roadmap for your own package. If you ship a PHP/Laravel package, AI-agent readiness (structured llms.txt, install guides, published skills) is increasingly part of the adoption funnel. This package is a useful reference implementation for how to expose that surface, and the Laravel Boost badge signals alignment with the official ecosystem direction. 1.13.0 is also a decent worked example of a hard problem in that surface: namespacing published artifacts (<skill>-user) so a globally installed package can't shadow a project-local one, and resolving cross-package name collisions deterministically.
• Governance and compliance of AI instructions. Versioning skills and guidelines in-repo, reviewed through PRs, gives you an auditable record of what your agents were told to do — useful for security review, onboarding, and incident retrospectives ("what did the agent know on that date?"). The new write guards (a sync refuses to overwrite a file it doesn't own, or to write through a symlink at a target path) reduce the blast radius of pointing this at a home directory, which is where a security reviewer will look first.
• Where it does not help: this is developer-experience infrastructure. It has no bearing on runtime behavior, performance, user-facing features, or revenue. Do not let it into a roadmap conversation as a product capability; it belongs in engineering enablement.

When to Consider This Package

Consider it when:

• Your team uses, or expects to use, two or more AI coding agents — or a single agent whose vendor you don't want to bet on. The value scales with agent count; at one agent it is close to zero.
• You want AI guidance reviewed and versioned like code, not copy-pasted between machines — and, now, curated at the user-scope level via a checked-in policy rather than trusting every globally installed package.
• You're in the PHP ecosystem, including non-Laravel projects — the explicit "no framework dependency" is the differentiator versus laravel/boost. This matters for agencies and polyglot shops running PHP services alongside other stacks.
• You're willing to pin a version and own a fork if needed. The package is small and MIT-licensed, so the exit cost is low — but see below.

Look elsewhere — or wait — when:

• You need production-grade assurance. Three stars, zero dependents, and a single maintainer is a hard stop for anything load-bearing. Treat this as a pilot or a reference architecture, not a dependency you can't remove in an afternoon.
• laravel/boost already covers you. Validate the overlap first. If the official package is on your roadmap and does most of this, adopting a community satellite creates a migration you'll pay for later. The maintainer's own framing (badge, "Laravel Boost" positioning) suggests this is complementary rather than competing — confirm that with a spike, not a README.
• You run exactly one agent. Native config files are simpler, have first-party support, and won't break on someone else's release cadence.
• Your projects aren't PHP. The output targets are universal, but the tooling and install path are PHP-centric.
• You require vendor support, SLAs, or a security provenance trail. None of that exists here.
• You can't absorb path-level breaking changes on a minor version. 1.13.0 is a 1.x release that renames every user-scope skill path and requires reading UPGRADING.md before the next --scope=user sync; the prior layout had a real defect (nested user-scope skills were invisible to Claude Code). That's the right fix, but it tells you the user-scope surface is still moving. If your team can't tolerate a "read the upgrade notes before syncing" step, wait for the layout to settle or stay project-scope-only.

How to Pitch It (Stakeholders)

For executives: We currently duplicate our AI coding instructions across multiple assistant-specific files, which means they drift and we re-do the work every time we evaluate a new tool. This is a small, MIT-licensed, framework-agnostic utility that lets us write those instructions once and publish them to ten assistants automatically. The strategic value is optionality: it makes switching or adding an AI assistant a config change instead of an engineering project. Cost is negligible; the catch is that it's early-stage — one maintainer, minimal adoption, and the most recent release renamed user-scope skill paths in a way that requires a documented upgrade step, so it is not yet "set and forget." Recommendation stays a contained pilot in one or two repos, not a platform commitment. If it doesn't pan out, the code is small and permissively licensed, so we keep the work.

For engineering: It's a thin CLI over a config file. You keep .ai/ as the source of truth in the repo; withAgents() declares targets; sync writes the agent-specific files. No framework coupling, so it works in our Symfony and plain-PHP services too. Four asks before we commit: (1) a half-day spike confirming it doesn't collide with laravel/boost if that lands on our roadmap; (2) we pin the exact version and read UPGRADING.md before any user-scope sync — 1.13.0 flattens user-scope skills to ~/.{agent}/skills/<skill>-user/SKILL.md and the first sync reaps the old nested copies (edited nested files are left in place, and pre-0.4 leftovers are no longer migrated, so budget a cleanup pass); (3) if we enable --scope=user, we commit ~/.boost/user-scope.php to dotfiles and review it, since it now controls which skills every globally installed package publishes — and note the collision rule is "first package alphabetically wins," so skill names are effectively a namespace we should own; (4) generated files stay out of the source-of-truth path so removal is trivial. Upside worth knowing: the write guards (no clobbering unowned files, no symlink targets) make a home-directory sync much safer to trial than it was last version. If adoption stalls, we fork or reimplement the sync step — it's a weekend, not a quarter.

Headline risk to state plainly: bus factor of one, three stars, zero dependents, and a user-scope layout that just changed incompatibly in a minor release. Mitigate by treating it as an internal utility we happen to source externally, not as infrastructure we depend on.